I have to create a COM library from a C# project, but I'm pretty stuck with referencing the external libraries.
I have set "Make assembly COM-Visible" in the project's properties and when I build it creates the dll and it puts all required dll's in the bin/Release directory.
Libraries used
All libraries are .NET imported with NuGet or System libraries.
Creating the .tlb file
When I run a command to create a .tlb file, it is created, but it also shows a warning:
tlbexp.exe "MyLib.dll"
TlbExp : warning TX00131175 : When cross-compiling, all type library references should be included on the command line to ensure the correct bit-specific type libraries are loaded.
Assembly exported to 'C:\Workspace\MyProject\bin\MyLib.tlb'
It looks like this library is ready to be shipped, but I'm wondering if I can just ignore the warning.
And, what is the best way to ship this COM-Visible library?
Can I just ship the entire bin/Release directory, or should I use another method?
Well the .tlb is needed just to reference your library from a development tool ( for example Visual C++ ), referencing correctly does not mean that program, after compiling correctly, will work. This because you need to proper install the dll on the target machine, typically you need to xcopy the dll with all dependencies, and then use regasm.exe ( specifying the /CODEBASE flag I suggest, so you can point surely the dll you want on your file system ). Of course even proper Framework has to be installed too.
Related
I created a test project from .net as a class library, I checked the register for com interop option and it works from visual foxpro.
then I tried to put a reference to a .net dll that I need on this project, it is not strong typed to put it directly on GAC).
I have comvisible class with a method on the test project that calls a method on the .net referenced dll and when I call this method from visualfoxpro I get the error that
"Could not load file or assembly or one of its dependencies ..."
I tested to have the referenced dll on debug folder (that I compile and then test) and from the client app's folder that I'm testing to consume the com dll in foxpro and in none of them the com dll found the referenced dll.
I have another posible folder to put the dll to be found? some code that I need?
When I recompiled the project, it start to work, seems that for some reason the auto publish to COM registry not occurs automatically.
if someone have this problem,
test to use
regasm nameOfLibrary.dll /tlb:nameOfLibrary.tlb /codebase on the .net dll
it loads on the COM registry the dll without put it on the GAC (some warnings about versions, search for that)...
also another option is to make a "registration free activation" that free of the need of registering the COM with regasm to consume the dll later.
I have an app that references a .dll that was built with Costura/Fody i.e The dll has all its references embedded. When I run the console app, the references from the dll are not unpacked so the console app throws an exception saying missing .dll etc. as it needs those resources to run.
i.e. AssemblyA.dll embeds MyAssembly.dll when built with Costura/Fody. ConsoleAppC references and embeds AssemblyA.dll but also needs MyAssembly.dll to run. I do have a reference to MyAssembly.dll in ConsoleAppC so that it will compile (but CopyLocal is set to false). I was thinking that MyAssembly.dll would be made available to ConsoleAppC when AssemblyA.dll's embedded resources are unpacked?
This is not working but is my scenario valid in any way or can you only utilise embedded resources from ConsoleAppC and not the ones that were embedded in AssemblyA.dll?
Thanks in advance for any help
Mike
What you're trying to do isn't possible with Costura.Fody. What Costura does is embed libraries directly into the main assembly. This means that if you embed the built assembly into another project, it can't see the sub assemblies.
For example, consider the following project structure:
AssemblyA
Foo.cs
References:
SubAssembly1.dll
SubAssembly2.dll
SubAssembly3.dll
AssemblyB
Assume that Costura.Fody is used to embed the sub assemblies in AssemblyA, creating a single DLL file, AssemblyA.dll
If you embed AssemblyA.dll in AssemblyB, then you will not be able to access classes in SubAssembly1.dll. You will only be able to see any of the classes that are directly in AssemblyA.dll, such as those contained in Foo.cs - you will not be able to see any of the libraries referenced by/embedded in AssemblyA.dll.
See this answer to a similar question, where the answerer suggests using ILMerge instead.
I make use of the Belgium Identity Card SDK for reading data from a idcard.
The SDK exists of 2 components: interface dll and a wrapper dll.
In VS2010, i can make a reference to the interface dll, but not to the wrapper dll, so I put it manually in the bin folder. When I migrate my application to another pc on the localhost, it is not able to find the wrapper dll.
Not even when I (on the 2nd pc):
-installed the sdk.
-put the wrapper dll into the bin folder and system32 folder
In visual studio, properties of the interface dll, I've set "Copy Local" to true.
What can I do?
This could just be a difference in path names between machines.
I would create a folder at the top level of your solution and place these DLLs in there. Call it something obvious like "Solution dependencies". Then you can reference them as needed and set them copy to local as required. You wont always be able to reference a DLL, especially if it isn't .NET compatible.
I'm curious about your statement of interface and wrapper dlls. Is the wrapper dll not meant to be a .NET wrapper for a C++ style dll?
I have a C# project which references a DLL (call it external DLL) which comes with another application. When I build my project, due to the reference, the external DLL gets automatically added to my project output. And when I run my project it loads the external DLL from my project folder.
The other application, which the external DLL belongs to, is developed by another team and the DLL is regularly updated. I don't want to package their DLL with my project. Instead I would like to have my project load their DLL when executed -- rather than pick the DLL copy from my project's folder.
Now I know that this is possible through reflection. I know that I can do an "Assembly.Load" and pick the DLL. But because I use the types from the external DLL all through my code, I would like the code to be statically type checked.
Here's what I would like:
Be able to compile my project by referencing the external DLL and thus get static type checking.
When the project is run, the external DLL is picked up from the other application's folder and not the copy of the DLL which is in my project's output folder.
Is there any way to solve this problem? Is there some middle ground between adding a reference and using reflection?
The most immediete solution to your problem is to change the properties of the reference. There is a setting called Copy Local. Set that to false and it'll stop copying the DLL to your project's output. You can access the properties of the reference by expanding the references folder in your solution, right-clicking on the reference in question, and clicking properties to open the properties pane.
The fact that Visual Studio copies the DLL to your project's output folder at build time doesn't really matter to the .Net Framework at runtime. All that matters is that the assemblies you reference are available to the framework either in the paths it searches or in the global assembly cache.
I'm trying to add a generated COM interop assembly project to my solution, and the only solution I could come up with feels really nasty.
I created a .net dll project, removed all .cs files from it and then created the following post-build event:
call "$(DevEnvDir)..\tools\vsvars32.bat"
midl.exe $(ProjectDir)relative-path-to-my-idl\MyComName.idl /tlb MyComName.tlb
tlbimp.exe /keyfile:path-to-my-key\k.snk MyComName.tlb
Essentially, I first create an empty DLL, then overwrite it with a real interop DLL. And there's no dependency management here - it's created every time.
Is there a better way to do this?
The MIDL compilation can be handled by making the COM interop project a managed C++ project (instead of a C# project) then adding the idl and h to the project as regular source files.
You can overcome the dependency problem by using MSBuild tasks directly instead of a PostBuild batch file, which line up nicely with the MSBuild dependency system.
However, why are you generating the file manually from an idl? When I need COM interop, I just import it and put the generated assembly (*.Interop.dll) into version control. This way, you always have the version you need and it's already ready to use, and Visual Studio can find the interop DLL before the first build, i.e. Intellisense is there right from the beginning.
Now some people won't like to check in a binary file, which I typically agree with, but well, if it works... :)
Of course, my method won't work if building the COM server is part of building the solution. In this case, just try to put the generation into the MSBuild script to get rid of the dependency thing, unless Visual Studio accepts a reference to a solution-internal non-.NET-COM project.