In-depth Analysis and Solutions for Visual Studio 2013 External Build Error MSB4019

Problem Background and Phenomenon Analysis

After upgrading Visual Studio projects from version 2012 to 2013, many developers encounter a typical build error during command-line builds. The specific error message shows: error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. This error indicates that the build system is attempting to reference build target files from Visual Studio 2012 (v11.0), but these files do not exist in an environment with only VS2013 installed.

Root Cause Investigation

Through in-depth analysis of project files, we found that the core issue lies in residual VisualStudioVersion property configurations in the project file. During the upgrade process, VS2012 adds the following property group to the project file:

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

This configuration sets a default VisualStudioVersion value of 10.0 (corresponding to VS2010). When building from the command line without explicitly specifying the VisualStudioVersion property, the system uses this default value, causing VSToolsPath to point to the non-existent v11.0 directory.

Solution One: Modify Project File

The most direct solution is to remove the conflicting property group configuration from the project file. Specific steps include:

1. Open the project file (.csproj) with a text editor
2. Find and delete the PropertyGroup containing VisualStudioVersion and VSToolsPath definitions
3. Ensure the project file's ToolsVersion attribute is updated to 12.0: <Project ToolsVersion="12.0"
4. Save the file and rebuild

This method is simple and effective, but it should be noted that if the project needs to be used in multiple Visual Studio environments, the configuration might be re-added when opened later.

Solution Two: Specify Property During Build

For scenarios requiring project file compatibility or when using build servers, it is recommended to explicitly specify the VisualStudioVersion property during build:

msbuild myproject.csproj /p:VisualStudioVersion=12.0

In build tools (such as Visual Build Professional), you can add to MSBuild arguments: /p:VisualStudioVersion=12.0. This method does not modify the project file, maintaining project portability.

Technical Details Deep Dive

Understanding the MSBuild property resolution mechanism is crucial for completely resolving such issues. When the build system processes Import statements:

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

The system first resolves the VSToolsPath variable. The default definition of this variable depends on the VisualStudioVersion property. When not explicitly specified, the system uses the default value set in the project file, which causes version mismatch issues.

Best Practices Recommendations

To avoid similar problems, it is recommended after project upgrades to:

• Thoroughly check version-related configurations in project files
• Explicitly set all necessary MSBuild properties on build servers
• Regularly verify consistency between command-line and IDE builds
• Establish standard project upgrade checklists

By adopting these best practices, build issues caused by version upgrades can be significantly reduced, improving development efficiency.