Today, while doing some .Net development I noticed something about MSBuild that is really annoying. I’ve seen his before but didn’t know the reason behind it. Now I do and it is a little frustrating.
If you have assembly A that depends on assembly B that depends on assembly C and assembly C exists in the GAC (Global Assembly Cache). When assembly B is copied into assembly A’s “bin” directory during build, assembly C is not copied, even if you specify that assembly C is a “private” (copy local) dependency of assembly B.
The problem is that by default MSBuild’s ResolveAssemblyReference task will not copy referenced assemblies that are in the GAC to the build output directory unless the referenced assembly is specifically tagged as “private” by the build project being built.
So even though assembly A doesn’t directly reference assembly C in its code, it only uses C through the intermediate dependency B, you still need to add C to A’s referenced assemblies set for C to be copied into the build output of A.
There is a discussion of this issue here, on Microsoft’s developer forums.
Sometimes Microsoft’s C++ compiler just produces bad binaries.
At the moment I’m working on code that compiles just fine using the Microsoft C++ Win32 & Xbox 360 compilers. However it does not run. It crashes during static initialization deep inside the C runtime library. It crashes hard well before the debugger can even load the debug symbols so I don’t even know in where it might be dying. It crashed the Xbox 360 so hard it crashed the IDE.
This is no fun to debug.
GCC on the other hand won’t even compile my code. I’ve been a very bad boy in many spots without even thinking about it and the Microsoft C++ compiler hasn’t complained. At all. Not one little bit. I’ve even got warnings cranked all the way up.
Now after running GCC over my code until it is satisfied that I’ve been a good boy, I compile my code again with Visual C++. This produces a working executable and I can get on with my job.