views:

872

answers:

3

Hi,

I am building an Class Library application which contains some reference dlls like Skype4COM which is obviously not native object so I just wanna learn how to embed this dll into my dll showing up after building the solution.

I just don't wanna see people which dll I used when developing this application and also I don't want them struggle with skype4com.dll to import it into their projects.

P.s : to use skype4com.dll, it needs to be registered on windows by using cmd window : regsvr32.exe dllpath

So does it cause an error or is there any work-around for something.

Thanks in advance.

Sincerely.

A: 

You can't embed an in-proc COM server (a DLL that is to be registered with regsvr32) into a class library assembly without the COM server becoming infunctional.

Registering with regsvr32 exposes the COM classes implemented in the COM server to the registry. Later consumers of that server would look up the registry to find where the COM server resides and try to load it and call the DllGetClassObject() function. If they don't manage to do that they will be unable to use the COM server. I'm sure you can't do the embedding and preserve functioning of this mechanism.

sharptooth
+4  A: 

Trying to hide your dependencies is a bad reason to do this, IMO. Aside from anything else, unless you obfuscate the code it'll still be visible to anyone who decompiles it with a tool such as Reflector.

Trying to make deployment easier is a good reason, however. The bad news is that for COM objects in .NET 3.5, there's no easy way round installation, as far as I'm aware.

The great news is that in C# 4.0 and .NET 4.0, there's an alternative approach which makes deployment of libraries using COM much easier. You can link the PIA instead of referencing it, which makes the compiler embed in your assembly just enough information to get at the real COM library and the types/members you use. You then don't need to ship or install the PIA.

If you can wait for .NET 4.0, that's the approach I'd take for COM PIAs, but for anything else I would just ship the library separately. Aside from anything else, the developers using your library may already be using the same class libraries you depend on: introducing two separate copies would be very confusing. If you can't wait for .NET 4.0 (or don't want to force your users to deploy it) then I'm afraid you'll have to install the COM PIA in the normal way.

Jon Skeet
A: 

This link may help... IL Merge

However the ILMerge won't work for unmanaged types.

S M Kamran
note that this is not for non-managed assemblies
jeroenh