In previous posts, I have hinted at the fact that there is more than one C# compiler on a machine with Visual Studio and .NET Framework installed. Sometimes there are several.
Simply put, when we release Visual Studio we release a compiler referred to as the in-process compiler, or in-proc compiler. We generally also release a new version of the .NET Framework at the same time. In the .NET Framework we also ship a separate compiler: the framework compiler, CSC.EXE. The in-proc compiler is tucked away in a Visual Studio DLL containing a bunch of other code as well. The presence of multiple compilers can result in an awkward servicing story and general confusion.
Why two compilers? Well, that wasn't the original plan, but late in the Visual Studio 2005 cycle, the plan changed. The reason that Visual Studio doesn't just use the framework compiler is for performance. Using the in-proc compiler avoids the cost of spinning up another process, and it also reuses a database of interned strings. These issues may not seem significant today, but at one time they had a real performance impact.
The downside of using the in-proc compiler is that it limits scalability. The Visual Studio address space is pretty crowded, and compiling large projects takes up a lot of address space. This wouldn't be a concern if Visual Studio spawned CSC.EXE for the build. So if you run into build scalability issues with a Visual Studio full build, you can often work around them by invoking MSBUILD.EXE from the command line supplying the .SLN file.
I hear you saying, "But my Visual Studio is spawning CSC.EXE. I see a message saying so in the output window." When the output window of Visual Studio tells you the command-line it is invoking CSC.EXE with, don't believe it. Visual Studio is calling the in-proc compiler with the equivalent switches, not the framework compiler. This may change for future versions of Visual Studio, but in Orcas, you're getting the in-proc compiler.
The presence of two compilers per release can pose a problem for servicing. Visual Studio and .NET Framework generally have two different servicing schedules. This means that sometimes users may see a fix in Visual Studio but not in CSC.EXE or vice versa. For service packs to Visual Studio 2005 and .NET Framework 2.0 this is definitely the case. Several more bugs were fixed in CSC.EXE in .NET Framework 2.0 SP1 (and SP2) than were in Visual Studio 2005 SP1. Thankfully, servicing of .NET Framework 3.5 and Visual Studio 2008 is happening at almost the same time. Right now we're working on .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 and all fixes made so far have been made to both compilers.
Read more: I'm just sayin'
Posts
0 comments:
Post a Comment