Dll Merge
-
I'm writing a class library which contains a couple dlls. Is it possible to have one combined dll of my class libary and the other dlls i'm using. I just want to make a single redistributable dll. Is it possible? Note: I don't have the code for the dlls i'm using in the class library. Only have the dll itself Thanks in advance
-
I'm writing a class library which contains a couple dlls. Is it possible to have one combined dll of my class libary and the other dlls i'm using. I just want to make a single redistributable dll. Is it possible? Note: I don't have the code for the dlls i'm using in the class library. Only have the dll itself Thanks in advance
Yes, but call them what they are: assemblies. An assembly contains a manifest at the very least. It can also contained 0 or more embedded resources, assembly attributes, and modules. Those modules are what contains your IL (intermediate language) that the compiler generates. Unfortunately, VS.NET won't help. You can only compile to modules using the command-line compilers. For the C# compiler, this uses the /t:module switch. When you compile the last project, you use an assembly switch (everything else but /t:module, like /t:library for a class library) and then use /addmodule:<path> to add the other modules. This will create an assembly with multiple modules. By why are you worried about sending out multiple DLLs? You should install them into the GAC anyway, which takes care of versioning problems. By distributing the Types, this also gives you more flexible control over independently versioning assemblies. You can redirect assembly bindings using a publisher policy - a specify type of assembly that gets installed into the GAC. So, if class library A depends on B, but you had to change B and don't need to change A, then you must tell assembly A to look at the new version of B. This is assembly version redirection. When you start having larger projects (I managed a product with over 60 possible assemblies, depending on the edition someone buys), this is a must since you don't always need to recompile everything (especially a problem when you're doing touchless-deployment over the Internet like we are). Just something to consider.
Microsoft MVP, Visual C# My Articles
-
Yes, but call them what they are: assemblies. An assembly contains a manifest at the very least. It can also contained 0 or more embedded resources, assembly attributes, and modules. Those modules are what contains your IL (intermediate language) that the compiler generates. Unfortunately, VS.NET won't help. You can only compile to modules using the command-line compilers. For the C# compiler, this uses the /t:module switch. When you compile the last project, you use an assembly switch (everything else but /t:module, like /t:library for a class library) and then use /addmodule:<path> to add the other modules. This will create an assembly with multiple modules. By why are you worried about sending out multiple DLLs? You should install them into the GAC anyway, which takes care of versioning problems. By distributing the Types, this also gives you more flexible control over independently versioning assemblies. You can redirect assembly bindings using a publisher policy - a specify type of assembly that gets installed into the GAC. So, if class library A depends on B, but you had to change B and don't need to change A, then you must tell assembly A to look at the new version of B. This is assembly version redirection. When you start having larger projects (I managed a product with over 60 possible assemblies, depending on the edition someone buys), this is a must since you don't always need to recompile everything (especially a problem when you're doing touchless-deployment over the Internet like we are). Just something to consider.
Microsoft MVP, Visual C# My Articles
I problem with modules is that one module cant access another module in the same assembly :| top secret xacc-ide 0.0.1
-
I problem with modules is that one module cant access another module in the same assembly :| top secret xacc-ide 0.0.1
They can, but modules and assemblies have to be compiled with a single command. csc.exe can produce multiple output files at the same time, but the first /out: has to contain the manifest. If you do it that way (or use pre-proc defs and a two-stage build, which is what I did a while back), modules can even access
internaltypes in other modules within that assembly.Microsoft MVP, Visual C# My Articles