We Keep Coding

How to publish a COM-Visible library created with C#

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.

Visual Studio and installer project (c#), won't copy a "third party" dll (vb)

I'm on a C# project, and since it uses Sharepoint I'm working on a MS Server 2008.
The project compiles and runs fine on server, so I thought it was time for deployment, and created a Installer Project, provided by Visual Studio itself.
When I run the installer then the program on server, it works flawlessly. But when I do that on my local machine, it says a COM reference is missing or something.
The fact is that this project indeed references a Visual Basic DLL provided by my company, and I just don't understand why the installer won't copy/register it by itself. It managed to get some other needed DLL well and copied it to the installation folder (like Microsoft.IdentityModel.dll, Microsoft.SharePoint.Client.dll...).
Any hint on what I should do to have it working? I do not have access to the "copy local" property of the referenced DLL (it's greyed).
Edit: some pictures, maybe it'll help:
http://hpics.li/2f6acc4
http://hpics.li/86e8b11
http://hpics.li/6697314
Edit 2: So it's a bit more complicated that I thought. In fact, when I simply reference the original DLL (which is GestionClevb6.dll), I end up getting the "unregistered class" error in my program.
But if I reference the generated Interop.GestionClevb6.dll, I notice another DLL being added to the deployment project (a dependency I guess). Oh yeah. So I have two DLL in the end, GestionClevb6.dll and the new one, DLL_Licence.dll, and a brand new bug: "Exception de HRESULT : 0x800AC352."

The error about a COM reference missing means that your project references a COM class, but on the system you're trying to run the program that COM class is not registered.
You need to make the setup register the COM-DLL in the course of the setup process. It will not be done automatically! Otherwise, if the COM-DLL has not been registered, you'll get this error. I suppose that on the server where it works, the DLL has been registered before.
don't understand why the installer won't copy/register it by itself.
How should the installer know that it is a COM DLL that must be registered?
It managed to get some other needed DLL well and copied it to the installation folder (like Microsoft.IdentityModel.dll, Microsoft.SharePoint.Client.dll...
These are managed DLLs directly referenced by your project. They don't have to be registered. Also, as these are managed referenced DLLs they will be copied as part of the "Project Output" if the "Copy Local" property for the reference is configured accordingly.
This, however, does not work for COM-DLLs. There's no "Copy Local" property for COM-references as it wouldn't help anyway - DLLs containing COM classes need to be registered. Copying alone doesn't register them.

CoCreateInstance C# COM component from native app does not find reference

I have a question concerning a COM C# component being created from a native C++ application.
The C# component is referencing an assembly which contains the COM interface.
So project A(.dll) contains the COM interface, project B(.dll) contains the COM class that implements this interface.
This C# COM component is then registered using regasm from some folder on my system, say for example:
C:\TestComponent which contains A.dll & B.dll, B being the one registered using regasm.
When my native C++ application (COM server), which is installed in another path, is trying to create an instance of the C# COM class from project B this fails complaining that A.dll can not be found.
If I copy (only) A.dll to the installation directory of my native C++ app, everything works perfectly.
Any ideas on how to tell my native C++ app that it needs to find the A.dll in a specified directory or in the directory where B.dll resides?
Kind regards,
Dwight

Having dependencies in a COM server is always a problem, whether it is an unmanaged server or one written in C#. Just like Windows, the CLR will only look in a few select places for a DLL. Which are the GAC and the directory where the EXE resides. With an option to also look in subdirectories of the EXE directory by using a app.exe.config file.
Knocking off the candidates here: you'll want to avoid giving the client EXE a .config file, you don't control its location nor configuration, it is somebody else's program. Same problem with the EXE directory.
Which leaves the GAC.
Also the location that Regasm.exe prefers, just omit the /codebase option when you register after you put the assemblies in the GAC. And a very good way to solve the DLL Hell problem that's so strongly associated with COM, the GAC can store different versions of your DLLs.

As far as I understand, you only registered B.dll. That is the reason, the COM System has no knowledge, where A.dll reside. I do not know a way to tell the application where it can found a, except of changing the workingdirectory or add the path to the A.dll to the system path variable or last but not least copy the A.dll into the system32 directory (but I hate that).
By the way, having a DLL proxy, like A.dll is, reside in the same directory as your application seems totally fine to me.
Ah one more thing. You can, if you now the path of the A.dll but did not want any of the above solutions, you can have a look into Loadlibrary.

Referencing an external .NET DLL provided by another application in C#

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.

Where to put my dll files using F#

I have a library with both managed and unmanaged C#, C++ dll files. I want to reference it from F#. Where can I place the C#, C++ dll files? I can not place them in the application folder (I must have copy local = false) and it will be only me who will use the program. I have tried windows/system32, GAC using setup and adding PATH variable pointing to a folder with all the dll files but none of it seems to work.
Thanks for any hint

When building your application in Visual Studio, it looks for the references in all the default folders (depending on your OS, .NET Framework version and other things) but also in locations you specified in the project configuration. Right click on the project in Solution Explorer, click Properties and go to the Reference Paths tab. Add C:\MyDllFolder or anything.
If you do this in all your applications which are using that dll, you could just have it sitting there once.

You can specify dll locations MSDN : Specifying an Assembly's Location or maybe use something like
Assembly.LoadFrom
if you want dynamics.