The death of multi-file assemblies (hopefully)

  • Article

Now that Whidbey features can be freely talked about, I can mention my personal not-directly-C# feature: netmodule linking.  Basically due to some hard work by the C/C++ compiler and linker team, any tool that can produce managed netmodules(/target:module in C# abd VB land) can be linked into a single-file assembly by the linker!  You can now have a single file assembly witc, VB, C#, C++, and even native code all in one file!  Theoretically you can even link classic static .LIBs into your brand new C# assembly (although I've never tried that specifically).

The big down side is that there is no way to do most of this inside the C# project system inside the IDE. The XMake team (is that's what it's still called? they change names faster than a chameleon changes colors), tells me that their extensible make files and builds rules should allow this, but I'm not sure how that would interact with the IDE's projects.  I have heard that the C/C++ project system works decently when only small amounts of code are written in another language.

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...

--Grant

Comments

  • Anonymous
    June 01, 2004
    Is this similar to ILMerge? Or have I totally missed the point?
  • Anonymous
    June 01, 2004
    The comment has been removed
  • Anonymous
    June 01, 2004
    Excellent - the lack of a linker has always been one of the big gripes of C++ coders...now I wonder if it'll allow the merging in of Framework modules to build single file Exes for non-.NET-installed machines, now THAT would be cool!
  • Anonymous
    June 01, 2004
    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.).
  • Anonymous
    June 01, 2004
    True, and the ideal is that the .NET framework is installed as part of the OS - however that is just not the case at the moment - and it's a major limiting factor in deploying .NET applications to run on the desktop - since you can't be certain they'll have it installed and the runtime is 20MB+ - which pretty much rules it out for any dial-up only user. So as i say, the ideal is not linking, but the option would help uptake in the short-medium term.
  • Anonymous
    June 01, 2004
    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...
  • Anonymous
    June 01, 2004
    It looks like this is something like thinstall
    (http://www.thinstall.com/)
  • Anonymous
    June 01, 2004
    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.
  • Anonymous
    June 02, 2004
    The comment has been removed
  • Anonymous
    June 03, 2004
    The comment has been removed