The Old Joel on Software Forum: Part 4 (of 5)

MSIL

According to this article the next version of Visual Studio (after 2003) should support MSIL Linking:

http://www.developer.com/net/article.php/3099811

I don't know if this is the same thing as what Joel's asking for, anyone familiar with this?

Li-fan Chen
Friday, January 30, 2004

It's not what Joel wants, but it's still interesting.

So far, the .NET linker (al.exe) can combine various "netmodules" (code modules that can be written in different languages) into a single assembly.

However, this process was (a) not supported by Visual Studio, and (b) did not actually combine the various modules into a single file -- it just created an assembly stub that referred to the modules, which had to be deployed as separate files.

As I read the article, Whidbey (or at least C++ in Whidbey) will be able to link netmodules into a single assembly. That's cool, but you'll still need the (separate) Framework assemblies to execute your program -- the new linker only links netmodules, not assemblies.

Chris Nahr
Friday, January 30, 2004

Does anyone have a good use case for this?

The netmodules must be totally independent prior to linking, so this just provides a mechanism for grouping things together.

Sure, it tidys things up but unless I've missed something (very likely...) doesn't add any new power.

I would like to be able to write a mixed language assembly where my C# code can use types defined in managed C++ code in the _same_ assembly.

Rob Walker
Friday, January 30, 2004

[Sure, it tidys things up but unless I've missed something (very likely...) doesn't add any new power.]

Exactly. The al.exe tool simply allows you to package multiple assemblies into one assembly for distribution.

I have not seen a tool that allows what you request. The compiler would have to recognize multiple languages and distringuish where each one is used. I bet it could be done but it would require one MSIL compliant compiler for these mutiple languages. You might be able to use the existing compilers but I'm not sure of the level of effort involved. I think MS just didn't consider this a prority. Would it be a nicety or would it really add considerable value? I'm not sure.

trollbooth
Friday, January 30, 2004

[distringuish]

Distinguish also. My lack of QA must scream software developer.

trollbooth
Friday, January 30, 2004

"I would like to be able to write a mixed language assembly where my C# code can use types defined in managed C++ code in the _same_ assembly."

I don't understand this comment. Of course one netmodule can use types defined in another netmodule, even with the current linker.

Chris Nahr
Friday, January 30, 2004

"Exactly. The al.exe tool simply allows you to package multiple assemblies into one assembly for distribution."

Wrong, al.exe packs multiple _netmodules_ int one assembly. You can't pack assemblies, ever.

Chris Nahr
Friday, January 30, 2004

[I don't understand this comment. Of course one netmodule can use types defined in another netmodule, even with the current linker. ]

I think he means starting from scratch you cannot create one assembly using source files written in mutiple languages. You'd have to write one in c++, compile it, then reference it using the c# compiler or vice versa. No one compiler can compile multiple languges all at once.

Is this what you mean?

trollbooth
Friday, January 30, 2004

[Wrong, al.exe packs multiple _netmodules_ int one assembly. You can't pack assemblies, ever. ]

True, sorry for the mistake. A module is essentially the same thing without an assembly manifest. I should have been clear about this. Never the less the end result is the same.

trollbooth
Friday, January 30, 2004

Having the ability to write an assembly mixing and matching languages as required would really just be a nicety.

My current project has a lot of code in managed C++. Only a fairly small fraction of this _has_ to be managed C++ because it does stuff that just can't be done from C#.

I would be nice to be able to write the bulk of the code in C# to take advantage of using (...) and foreach (...). I could split it into multiple assemblies, but that adds complexity and without the concept of a 'friend' assembly requires changes to the visibilty of certain types.

It was simply easier to use managed C++ everywhere and put up with the odd syntax. In fact, after a while it blends into the background.

Given the lack of benefits compared to the amount of work required on the compiler front ends it's not a feature I'd expect to see developed.

Rob Walker
Friday, January 30, 2004

The only real advantage to a multi-module assembly is that the loader only needs to bring in the modules that are actually used. So if you've got an assembly with some types that a big, and only used occasionally, you could split them out into a separate module so you don't pay the cost if they're not used.

In the download scenario, the other modules might not even need to be downloaded until they're referred to, but I'm not sure on that one.

Fairly marginal gain, really.

Chris Tavares
Friday, January 30, 2004

"My current project has a lot of code in managed C++. Only a fairly small fraction of this _has_ to be managed C++ because it does stuff that just can't be done from C#."

Rob, you can do all this in a single assembly _right now_. You just have to put up with deployment in multiple netmodules, and with the unpleasantness of a build script outside of Visual Studio.

Whidbey will remedy this -- then you should be able to build a single assembly, containing both MC++ and C#, right from within Visual Studio.

Chris Nahr
Friday, January 30, 2004

> Rob, you can do all this in a single assembly _right now_.
> You just have to put up with deployment in multiple
> netmodules, and with the unpleasantness of a build
> script outside of Visual Studio.

Thanks, I did a bit more reading and found the /addmodule switch for the C# compiler that was the bit I was missing.

Rob Walker
Friday, January 30, 2004