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.
Related
I'm not new to C# programming, but I suppose I'm new to programing "the right way" in C#. I've worked in C on embedded devices for years and have written desktop apps to support them. First in VB6, then in C#.
I recently started making better use of classes for reusing code (and for instantiating more than one instance of the class in a program). For example, I "wrapped" a UART interface with some additional functionality so I can use the same code for multiple ports by creating an instance of the class for each one.
It is in a separate file, but still in the same program namespace, so when I want to reuse it, I have to copy the file and change the namespace to the new project.
I'm sure there's a way to create it such that I can just reference it like everything else with either a "using..." reference at the top of the program or with a "Project | References..." checkbox. But for the life of me I can't find a good learning journey for this.
Any direction would help.
You want to create your reuseable class in an assembly - this is the equivalent of a dll from your C experience.
To create an assembly, have a separate project of type assembly (instead of exe) . You can reference the assembly from other projects. If your project is in the same solution you can reference the project, otherwise you can reference the compiled assembly.
C# uses a packaging system called Nuget, so you can package your assemblies into "Nugets" which you host in a Nuget Server. You can then use tooling to discover and import these.
Please create a Class Library project and include your class into that project. Make sure your class is public. Once you build this project you'll get an assembly which can be referenced from other projects. See Tutorial: Create a .NET class library using Visual Studio
There are different ways of referencing it.
You can have the class library project in the same solution as the main project. In this case you should add a project reference.
You can copy the compiled *.dll file to some folder in your solution (e.g. Lib) and add an assembly reference.
If this assembly is to be used in multiple projects please consider creating a NuGet package with this library and pushing it to some repository. Then other projects can add a package reference to this package.
Details:
How to: Add or remove references by using the Reference Manager
Install and manage packages in Visual Studio using the NuGet Package Manager
It is in a separate file, but still in the same program namespace, so when I want to reuse it, I have to copy the file and change the namespace to the new project.
Well, it isn't the best practice but (unfortunatly) still a common behavior. So don't worry to much about it.
What you could do to improve it place the file (and other reusable parts) in a seperated csproj.
For example name the project of the type class library and name it VinDag.Tools. Within the project create a folder UART and place the wrapper there. The namespace of the wrapper would then be VinDag.Tools.UART.
From know on you can just reference the class library instead of renaming the file. It's not necessarily required to be the same namespace as the project.
From there you can start considering (private) nugets. This would prevent you from copying files/csproj around.
I have some problems with dll. When I make dll without using of lib files (which I need), everything is fine. But when I'm trying to use some functions in dll that uses functions in lib then some exception appears:
System.DllNotFoundException, cant load a dll module (exception from HRESULT:0x8007007E).
dll file is in correct place.
P.S. using Visual Studio 2010.
What could be wrong?
More detail in the question will get you better answers. But with current information, the most likely cause is that the lib file you are referencing or one of its dependencies is unavailable. This could be because it is not in your GAC or your runtime location, a file format conflict, or a number of other things.
I'm assuming that everything compiles without errors, of course. Again, please add detail if this is not what you need.
if you are making a new class you should reference the default dlls.
in example when you make a new class library and want to use a messagebox in your code ,
you should first reference that required dll in your program(i dont mean your dll,i mean dot net default dll like system.windows.forms) and then add using something; in the top of your class.
example : we want use messagebox in a class library then :
1. first from solution explorer right click the project > add reference ,now reference manager opens now from left tabs click assemblies then framework and then find and select system.windows.forms
2. now its time to use it in our program first add this line in very top of your class file
using System.Windows.Forms; //add this line in top of your class
after that we can use messagebox without any compiler errors.
keep in mind any other dll files should be referenced this way but in windows form applications default lib files are referenced by default
I have a C# console application in Visual Studio 2010. It has a Main() method as well as a bunch of utility classes. I'd like those utility classes to be available to other solutions. From reading online it seems that I need to compile it as a Class Library (DLL). So here's what I did:
Went in Visual Studio to "Project > [ProjectName] Properties > Application" and changed "Output type" from "Console Application" to "Class Library"
Rebuilt; ProjectName.dll was created in bin/Debug.
Created a new Console Application
Solution Explorer > Add Reference > browse to ProjectName.DLL, select it.
However, neither IntelliSense nor the Object Browser could find the classes inside that DLL.
I tried recompiling several different Console Applications as Class Libraries and got the same result. I also noticed that it works if I initially create the solution as a Class Library, but not if I convert it to one later.
Any tips?
You do not need to build it as a dll. VS 2010 (and IIRC 2008) allow referencing exe assemblies. All you need is for they relevant types to be declared public - top-level classes defualt to internal if you don't add a specifier.
You can switch output type to Class library in project properties as well - then you will have an output as dll instead exe file
What I've always done (since this is what you do with C++ static libraries, which is what I normally use - though I think it has some advantages for C# too) is add the class library's project to the solution, then add a reference to it in the project (or projects) that uses it.
When you go to add a reference, the list of potential references includes items from the solution, so it should be fairly obvious what to do. You should then get intellisense for your library.
One advantage of doing things this way is that if you need to edit files in the library project, it's very straightforward because they are close to hand, and the project then gets rebuilt automatically when you compile the solution.
Make sure that the classes in your dll project are public.
At first, from the point of view of managed libraries it does not matter what kind of Output type is your managed library. I mean that you can successfully reference ConsoleApplication1.exe from ConsoleApplication2.exe project (so you have no reason to convert ConsoleApplication1.exe to ConsoleApplication1.dll).
At second, I've tried to reproduce your situation, but... without effect. My VS displays types/methods from ConsoleApplication1.dll. One reason I can suppose is that you have forgotten to set visibility modifier (public keyword) for your utility classes.
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.
My UserControl references a C++/CLI wrapper to an unmanaged C++ dll. When I try to add the UserControl to a form, I get a Visual Studio error, which says "Failed to create component 'userControl'", giving a System.IO.FileNotFoundException as the cause.
From what I've been able to determine, the problem stems from visual studio not copying the C++/CLI wrapper assembly's unmanaged dependencies. If I put the unmanaged dependencies on the system PATH, everything works fine.
Is there a better way of doing this?
The easiest thing to do would be to include the actual .dll in your project, mark its build action as "Content", then set the Copy to Output Directory to "Always". This should get the .dll into your output directory so that your application can run, and just including the file in the project should put it in the project directory so that the designer can find it.
Be sure that your setup project includes a project output for the Content files from that project as well.
Edit
If those don't work, you can also edit the reference paths of the project itself (in the project properties), though I am not certain that this will affect the designer. If that doesn't then your only real option is to have the .dll in one of the system path directories.
Old thread, but submitting my solution since I just encountered the issue and found this question during the process.
Basically I just made the native DLLs to be delay loaded in my wrapper C++/CLI library. Since the C++/CLI part of the wrapper contains the interface specs used by Visual Studio and the framework, the native DLL is never needed or loaded. I answered it with a little more details in this question too:
https://stackoverflow.com/a/15481687/34440