I have never created a component before, but now have a few which are basically .cs files. They are of type System.Windows.Forms.Control.
But they are only available on the control palette when I am using the solution they are part of. It makes use of a few images which are in the /Resources folder.
Is there a way to make the component into a DLL, so that I can use it in any project by simply referencing it? Or else, make it into a component that always appears in my palette?
You need to create a Control Library project, which is a Class Library (DLL) that contains public classes that inherit Control.
You can then add a reference to the compiled DLL (or to the project if it's in the same solution) and the controls will appear in your toolbox.
Related
Is it possible to use the TreeView Class in a class library.
I want to make a method where I pass a Treeview from windows form , I tried to import System.Windows.Forms but it is not found and I cannot find any nuget package to install.
I want to do something like this:
public void MyMethod(TreeView tree){tree.Nodes.Add("Something");}
Thanks.
In Solution Explorer:
Right click on the class library project, select Add > Reference. On the left sidebar choose Assemblies > Framework. Check System.Windows.Forms and click Ok.
I would caution against adding this reference in your existing class library unless you want it to be specifically only for WinForms. Perhaps a cleaner approach would be to create a new class library, say .WinForms, and add a project reference to the original project and a Framework reference to System.Windows.Forms as I described above. This would keep the rest of your code separated out from the WinForms code in the base project, and then it could be used in other contexts without WinForms.
My Current Situation:
I have a main project, Project_A,
a dll project Project_Parent_dll
and another dll project Project_Child_dll.
Project_Child_dll contains a wpf user control.
Project_Parent_dll contains a wpf user control, that uses the user control contained in Project_Child_dll.
This Project contains a reference to Project_Child_dll.
Project_A uses the user control from Project_Parent_dll.
Right now, I have to reference both Project_Parent_dll and Project_Child_dll, and that works fine, but when I delete the reference to Project_Child_dll I get an XamlParseException.
Question:
Is there a way I could avoid the reference to Project_Child_dll in my Project_A?
I frequently load dll file and import namespace for instance
xmlns:UI="clr-namespace:Microsoft.Advertising.Mobile.UI;assembly=Microsoft.Advertising.Mobile.UI"
and then create XAML element using it
<UI:AdControl .../>
Can anyone share a post where is described how to create such a useful dll?
You create this like any other DLL in .NET:
Create a "Library" project. There is a "User Control Library" in some versions of WPF, so you might as well use it, but I believe a standard "Class Library" will work just as well
Add a "UserControl" to your library. Make sure it is marked public!
From the project that will use this DLL, add a reference to the new library project
Create a xmlns line like the one you have, but mapped to your assembly and namespace
Use the UserControl, again just like you already have.
Nothing special really, it really is just like any other DLL project.
I need to implement a wrapper to expose some native C++ code to C#, and have followed this tutorial:
http://www.silverlightshow.net/items/Windows-Phone-8-Native-Code-Support.aspx
So far in my C# test project, I don't have problems instantiating a class written in C++/CX from the Runtime Component project and using methods from that class, so long as I reference the entire project (.sln).
Visual Studio doesn't allow me to reference the Runtime Component DLL alone, but does allow me to reference the .winmd file in the project. C# then recognizes the namespace correctly, however at runtime I get a TypeLoadException when trying to create the same object.
This doesn't appear to be a namespace problem (as mentioned here: Changing namespace name of C++ component in Windows Phone causes exception), since everything is alright so long as I create a project reference (or does referencing a project vs a .winmd affect the namespace somehow?).
Is it possible to bundle the Runtime Component in some form that an end user can reference it without needing to provide the entire project?
You need to add following the to WMAppManifest.xml
<ActivatableClasses>
<InProcessServer>
<Path>YourComponent.dll</Path>
<ActivatableClass ThreadingModel="both" ActivatableClassId="YourComponentNamespace.YourComponent"/>
</InProcessServer>
</ActivatableClasses>
With YourComponent being the name of your WinMD.
I think what you are seeing is a manifestation of the problem described here.
In short, when creating a WinRT component using C++, just referencing the output DLL or the output winmd is not sufficient. You need both.
I had this same problem, and (eventually) figured out that the .dll and .winmd file needed to have the same name (which was the same as the namespace they defined) and be in the same directory.
For example, if your classes are in the X::Y namespace, the files must be X.Y.dll and X.Y.winmd.
Then all I needed to do was add a reference to the .winmd file in my project (by right-clicking on the References folder for that project in the Solution Explorer, choosing "Add Reference...", then choosing "Browse" from the dialog that comes up). I didn't need to add anything to the manifest file.
I've two Visual Basic 2008 projects - one is a class library project and another is a Windows Forms project. In the class library project, I've defined some strings in the project resources (project properties > Resources tab).
I build that class library project and get the DLL file from the debug folder and added up as a reference in my Windows Forms project.
How do I read those strings from the referenced DLL file?
While you can dynamically load the DLL as ho suggests, it's fine to use a reference as you have done. In fact I would recommend using a reference unless you had a particular requirement to dynamically load the resource assembly.
As to accessing the resources there are a few things you need to do.
In the resource assembly you will need to ensure the resources are public. By default resources are set to internal which means you will not see the resources in the winforms app. Double click on Properties\Resources.resx to open the resources view. In the top toolbar you will see a label "Access Modifier" next to a combo box drop down. Change the selection to public.
You will need to reference the assembly from the forms app. You have stated you have already done this. Just a note that a better way to do this is to create a solution that contains both projects. Then in the forms app choose add reference. Click on the Projects tab up the top. Double click on the resource DLL project name. This works better than referencing the debug DLL directly since it means if you change between a release build and debug build in your forms app, it will automatically build a matching release/debug version of your resource assembly.
Once you have added the reference you can simply reference the type out of the resources DLL, e.g.
ResourceDLLNamespace.Properties.Resource.ResourceName
Just a note, you need to be aware of type name clashes if you are using the same namespace for your forms app and resource DLL. In this situation both your forms app will have access to it's own Properties.Resources class as well as that of the resource DLL. You can do two things to avoid this:
Use a different namespace between the two assemblies
In the resource assembly don't include a default Properties\Resources.resx resource dictionary. Delete it and manually add a new resource, i.e. Add New Item and select "Resources File". You should find that you will not be able to add the new resource dictionary to the Properties folder - add it to the root or some other folder as you require. This will automatically give it a different type name by virtue of being in a different folder. You still may want to avoid using the resource file name of "Resources" however, as if you have all the relevant namespaces in scope via using statements you will get the same issue that the compiler won't know which version of Resources to use.
-Donovan
I think you just use System.Reflection.Assembly.Load to load the other assembly then use the constructor of System.Resources.ResourceManager that takes an assembly.
Note, I don't think it needs to a reference for this to work.