VC# Express experience and some stuff on assemblies
I’ve just submitted my first Visual C# Express Beta 1 bug! It has to do with automatic formatting, for which there are luckily lots of options in this new version. I barely customized anything though, because I’m very much used to the way VS.NET 2002 and 2003 do it by default. Today was the first day that I’ve actually been playing with the VC# Express Beta for a bit, something that I’m very happy with is the ability to reference executables (instead of just dlls as was the case in the previous versions).
I was actually wondering why referencing executables is not allowed in the earlier versions and I suppose it’s because it’s better to have shared functionality seperated from regular application logic that resides in the executable. However, I found this to be pretty uncomfortable because besides an interface library that’s in a different assembly, there are often some additional classes that are versioned along with the main application but that are used in related applications. For instance a bunch of base classes used in plug-ins. You can include them in the interface library but personally I’d rather not have code in there with the interfaces, forcing me to make multiple class libraries to distribute an application, some common classes and an interface library.
In the meantime I’m still at TechEd Europe and during this morning’s .NET Versioning session by Juval Lowy, there was mention of a new attribute, InternalsVisibleTo, that allows assemblies to reference classes marked internal in other assemblies. I think this is a pretty cool addition since besides default internal behaviour, classes can now be made internal on an application or even vendor-wide basis (although that last will be a hassle to accomplish).
Something else that I found to be pretty cool was that during Peter Sollich’s CLR - Under The Hood session, he showed some IL code that was originally compiled from C# that had some pretty strange instructions around the end of a method: popping a value from the stack, branching to the next instruction and then pushing the value back on the stack again. He called this “C# compiler stupidity” which was quite a relief for me since I’ve been wondering about code like that for a while. I actually noticed code like that in examples in both Inside Microsoft .NET IL Assembler and Shared Source CLI Essentials which both didn’t really explain where this code came from.
In the meantime it’s about time for the TechEd party, so I’d better go and see what’s happening!