Introduction

This MSBuild error usually looks stranger than it really is. The project file may appear to reference v10.0, but the final import path is often built from MSBuild properties such as VisualStudioVersion or VSToolsPath, so the build ends up searching for v11.0 anyway.

In other words, the important question is not just what literal string appears in the .csproj file. The real question is which property values MSBuild resolved at build time.

Why The Error Mentions v11.0

Older web application projects often import Microsoft.WebApplication.targets through a property-driven path. A typical project contains something like this:

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

$(VSToolsPath) is frequently derived from $(VisualStudioVersion). If the build environment sets VisualStudioVersion to 11.0, MSBuild may expand the path to a v11.0 tools directory even when parts of the project still look like they belong to Visual Studio 2010.

That is why the message can mention v11.0 even though the file you inspected seemed to reference v10.0.

Inspect The Effective MSBuild Properties

The first step is to inspect which values MSBuild is actually using. In many cases, the problem is not the import statement itself but the environment or build host.

Look for properties such as:

• 'VisualStudioVersion'
• 'VSToolsPath'
• 'MSBuildExtensionsPath32'

If one of those points to a version that is not installed, the web application targets import fails.

Common Fix: Set VisualStudioVersion

If the project truly targets older web build tools and those tools exist on the machine, explicitly setting the version can fix the path resolution.

msbuild MyWebApp.csproj /p:VisualStudioVersion=10.0

That tells MSBuild to resolve version-sensitive tool paths as though it were building with Visual Studio 2010.

This is a common fix on CI servers where the default MSBuild environment chooses a newer version than the project expects.

Another Fix: Install The Missing Web Build Targets

Sometimes the project is fine, but the machine simply does not have the web application targets for the version being requested. In that case, installing the appropriate Visual Studio or Web Build Tools workload resolves the issue.

This often happens when a build agent has MSBuild but not the web application tooling that classic ASP.NET web application projects require.

Override VSToolsPath Carefully

If you know exactly where the targets file lives, you can override the tools path explicitly:

msbuild MyWebApp.csproj /p:VSToolsPath="C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0"

That can unblock a build, but it is better to understand why the default property resolution was wrong before hard-coding paths. Otherwise the fix becomes brittle across machines.

Why This Happens On CI More Often

CI servers frequently build old web projects with a newer MSBuild version than the original developer machine used. That mismatch exposes property-based import logic that never caused trouble locally.

A developer opening the project in an older Visual Studio installation may never see the problem, while a build server with a newer toolchain reports a missing v11.0 targets path immediately.

Common Pitfalls

• Trusting the visible import string without checking the MSBuild properties that compose the final path.
• Installing MSBuild but not the web application build targets.
• Letting the build host choose a default VisualStudioVersion that does not match the project.
• Hard-coding a path before confirming which version the project is supposed to use.
• Assuming the error message is wrong when it is actually reflecting a property expansion you did not inspect.

Summary

• The missing v11.0 path usually comes from MSBuild property resolution, not necessarily a literal v11.0 string in the project file.
• Check VisualStudioVersion, VSToolsPath, and related build properties.
• Setting /p:VisualStudioVersion=10.0 often fixes projects that expect older web tools.
• Installing the correct web application build targets may also be necessary.
• CI environments expose this issue frequently because their MSBuild defaults differ from the original developer setup.