TFS Hosted Build Controller and .NET 4.7

If you want the TFS hosted build controller to run .NET 4.7 builds, make sure to change the default agent queue to the "Hosted VS2017" version. You can do this by editing the build definition and in the Tasks Process landing page, it is the second option, as shown below.

Config Transforms for Elements

I would have thought this was obvious, but it took me a bit to figure it out.  The config file transforms that are available for web.config files and for all other files can be used to replace sections of a config file, based on a project configuration.  Most of the examples show changing attributes.  I wanted to change the entire element, in this instance, connectionStrings.  To do this, you simply put the Replace value in the Transform attribute on the element:

Assembly Implicit References, Installations, and the MSBuild Impact

I spent quite a bit of time trying to figure out why two of our Silverlight XAP files did not include the System.Windows.Controls.Toolkit.Internals.dll file when packaged on a build server.  Of course, when I built these locally, the XAP files were packaged correctly with this assembly being included in the XAP package.  I finally ran the exact same MSBuild command on both servers and then compared the output to determine why it was not being included.  When the Silverlight Toolkit is installed, it puts the reference assemblies under C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Toolkit\Apr10\Bin.  We have not installed the toolkit on the build server; we have just added the assemblies to source control under a shared path.  What I found is that if the assemblies are not in their “default” location, when MSBuild compiles the code, it won’t copy implied assemblies to the bin directory of the project, which will then prevent these from being included in the XAP file.  In this example, System.Windows.Controls.Toolkit.dll references System.Windows.Controls.Toolkit.Internals.dll, but the latter is not referenced in the project.  If I compile on a machine that has the Toolkit installed, the latter assembly will be copied to the bin.  On a machine that does not have the toolkit installed, the Internals assembly will not be copied to the bin.

Interesting compile behavior.  Lesson learned: make your references explicit, especially for Silverlight projects.

Build Projects and Solutions from Windows Explorer with MSBuild 4.0

Copy the following into a .reg file and run. This will give you the ability to Build, Clean, and Rebuild from the Windows Explorer Context menu.

Windows Registry Editor Version 5.00 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.sln] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.sln\shell] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.sln\shell\Build] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.sln\shell\Build\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:build\"" 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.sln\shell\Clean] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.sln\shell\Clean\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:clean\""

[HKEY_CLASSES_ROOT\SystemFileAssociations\.sln\shell\Rebuild] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.sln\shell\Rebuild\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:rebuild\""

[HKEY_CLASSES_ROOT\SystemFileAssociations\.csproj] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.csproj\shell] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.csproj\shell\Build] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.csproj\shell\Build\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:build\""

[HKEY_CLASSES_ROOT\SystemFileAssociations\.csproj\shell\Clean] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.csproj\shell\Clean\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:clean\""

[HKEY_CLASSES_ROOT\SystemFileAssociations\.csproj\shell\Rebuild] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.csproj\shell\Rebuild\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:rebuild\""

[HKEY_CLASSES_ROOT\SystemFileAssociations\.vbproj] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.vbproj\shell] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.vbproj\shell\Build] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.vbproj\shell\Build\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:build\""

[HKEY_CLASSES_ROOT\SystemFileAssociations\.vbproj\shell\Clean] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.vbproj\shell\Clean\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:clean\""
[HKEY_CLASSES_ROOT\SystemFileAssociations\.vbproj\shell\Rebuild] 

[HKEY_CLASSES_ROOT\SystemFileAssociations\.vbproj\shell\Rebuild\command] 
@="cmd.exe /K \"\"%%windir%%\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe\" \"%1\" /t:rebuild\""

For more advanced control, try the MSBuild Launch Pad on Codeplex.

Removing Source Control Provider in Visual Studio

I wanted to remove a source control provider from the list of providers that are listed in Visual Studio under Tools > Options without uninstalling the provider (because I needed the client for the history).  After poking around and reading the documentation on MSDN, on Windows 7 x64, the key is found under the location listed below.  Simply delete the provider under that registry key and it will no longer appear in Visual Studio.  This article helped me find this key.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SourceCodeControlProvider\InstalledSCCProviders

If it is a non x64 machine, remove the Wow6432Node\ from the path.