GrantRi's WebLog [MS]

Yes, somewhat. ILMerge was more of a back-door hack. This allows linking of pure IL images with non-pure code. And most importantly it is supported!

I'm personally torn on the notion of statically linking in the runtime. Most people don't want to statically link in gdi32.dll, they perfer to dynamically link it in from the OS. The CLR should be thought of as part of the OS (it already ships with Server 2003).

You have to be really careful with the distinction between modules and assemblies. Nobody should ever ship modules because they are not directly referencable, nor do they have any versioning capabilities. Assemblies do, but because of that you run into identity issues.

Specifically if such a linker existed, the runtime would see each definition of System.Windows.Forms.Form that was statically linked into different applications as totally different types. This can really burn people when they try and interoperate with anything else (any other assembly, remoting, Web services, etc.).

Quote:
"The main reason there's little to no IDE support is that the powers that be claim that the majority of C# users don't want or need to do this kind of stuff (they even have some data to back that up). So if this a useful feature, just make sure you're not the silent majority..."

What??? Not useful??? I pass all of my code through ILMerge (or more correctly: through a wrapper that merges the exe with all DLLs in the build directory, with an option to exclude any DLLs that must not be merged).

Let me provide some background: most applications I write are console applications for converting, filtering, processing data. I work in a research institute and the group I work for does lots of signal processing jobs. I end up writing lots of tools for converting data collected by custom data acquisition hardware into something that can be used by standard signal analysis/processing tools, such as Matlab or SPSS. The tasks tend to have many parts in common, so I have built up a collection of libraries for doing things like commandline argument parsing, reading the file formats we commonly use, writing those formats, and various processing and filtering steps. Most of these libraries are written in C#, with one or two in C++.
So, when VS builds those applications they appear as a smallish executable and a big collection of DLLs. When 'deploying' those tools (that is: put them in a shared network drive where the people using the tools can copy them from) I dont want all those DLLs there. I want 'COPY' deployment, not 'XCOPY' deployment... Apart from the libraries written in C++, ILMerge allows me to achieve this goal: I simply ILMerge the executable with the DLLs it was built and tested with (as a post-build step). This saves me lots of deployment headaches. Having an 'improved' version of ILMerge built right into VS would be highly appreciated...

Note that I am not referring to linking in any parts of the system or the .Net framework. I only want to link in my own homebrew libraries. In other words: what I really want is static libraries in .NET...

I think this is a great feature. IDE integration would be very helpful, of course :)

If the compilers had dead code removal, this could be used to reduce the size of the deployment, especially with large projects using many libraries. This could also reduce app startup times.

Statically linking the whole framework (dead code removal would be critical here) would be great. With the ongoing longhorn delays, the size of the framework is the biggest barrier to desktop deployment of a .NET app... lifting this would be very helpful.

It's been quite a while that I wondered why the hell this feature isn't built into the IDE.
I'd love to be able to link a few projects into one assembly using the IDE.