Those of you who've been using the 3.0 Framework may have noticed a folder under Program Files called "Reference Assemblies".  This folder contains those assemblies that ship with the 3.0 Framework which are useful for referencing during the design and build of new components.  Those of you who haven't yet used the 3.0 Framework, but plan on using the 3.5 Framework when it's released to the wild, will notice this change has continued.

This change is largely about disentangling design time and runtime scenarios.  At runtime, these components will still be loaded from the GAC in most cases.  At design time, going forward there will be a single location where users can find assemblies available for reference.  This location for the 3.5 Framework is:

     "%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.5"

For MSBuild, we've placed the 3.5 versions of the assemblies Microsoft.Build.Engine.dll, Microsoft.Build.Framework.dll, Microsoft.Build.Conversion.v3.5.dll and Microsoft.Build.Utilities.v3.5.dll (explanation of the "v3.5" in the filenames coming in a subsequent blog post!) at this location, and as mentioned earlier they will continue installing to the GAC for runtime use.  Notice I didn't list Microsoft.Build.Tasks.v3.5.dll here - because this assembly is essentially for runtime use only, we didn't decide to install it under the Reference Assemblies location.

The tools themselves that ship with the .NET Framework v3.5 (csc.exe, msbuild.exe, vbc.exe) will continue installing to their expected locations.

At build time, we actually had little work to do to accommodate this change.  For the version of MSBuild that shipped with the .NET Framework 2.0, we used a single location under the WINDOWS folder in different ways for different parts of the build.  For example, the compiler tasks looked in this location to find the executable they called, and the reference resolution task (ResolveAssemblyReference) would look in this location to resolve certain system assemblies.  Now, the reference resolution task has a location set aside expressly for this purpose, so it no longer needs to inspect the location under WINDOWS (for 3.0 and 3.5, anyways).

[ Author: Jeffery Callahan ]