What's the story with installing ""MSBuild"" assemblies into the GAC?

""Pre Beta 1""

""The story is this. Pre Beta 1, the MSBuild assemblies were not installed into the GAC. The reasons for this were numerous, but the main reason had to do with the fear of applications taking a dependency on MSBuild assemblies, and the MSBuild team not being prepared to lock down the API to ensure backwards compatibility for all applications moving forward.""

""Furthermore, when using Pre Beta 1, customers should not attempt to manually place the MSBuild assemblies into the GAC. This will almost certainly result in problems since the code relies on the location of Microsoft.Build.Engine.dll for many things, including deciding how to evaluate $(MSBuildBinPath). If you manually GAC the MSBuild assemblies, then the Fusion loader will start picking them up from the GAC, and MSBuild will issue failures when it discovers that certain other files (Microsoft.BuildTasks, CSharp.targets, Framework.targets, etc.) cannot be found in the same directory as that from which Microsoft.Build.Engine.dll was loaded.""

Beta 1 and Beyond

""Not having MSBuild assemblies in the GAC caused numerous problems, particularly for IDE scenarios. So starting with the Beta 1 release, the following MSBuild assemblies are installed to the GAC as part of the installation of the .NET Framework redist:""
* Microsoft.Build.Engine.dll
* Microsoft.Build.Framework.dll
* Microsoft.Build.Utilities.dll
* Microsoft.Build.Tasks.dll

""In conjunction with this, we changed the way $(MSBuildBinPath) is computed so that the host of MSBuild (e.g., msbuild.exe, Visual Studio, etc.) is responsible for "telling" MSBuild how to evaluate this property."" See MsbuildbinpathInTheCommandLine and MsbuildbinpathInTheIde for more details.