The target "VerifyTargetVersion" does not exist in the project.

Ever since upgrading https://github.com/github/VisualStudio to use new the SDK project files (for all projects except VSSDK projects) we’re getting the following error when building in Visual Studio:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(841,7): error MSB4057: The target "VerifyTargetVersion" does not exist in the project.

Everything works fine when building from the command line. The error goes away after multiple builds in Visual Studio, but comes back on a git clean -xdf.

I’m not even sure if this is an SDK issue, but posting here first because it arose after the conversion to SDK project files.

Repro:

• git clone https://github.com/github/VisualStudio
• cd VisualStudio
• git submodule init
• git submodule deinit script
• git submodule update
• Open GitHubVS.sln in Visual Studio 15.8.4
• Build solution

Sometimes the VerifyTargetVersion error doesn’t show up in the Error List, but it’s present in the msbuild logs.

[jcansdale]

It appears that updating from Microsoft.VSSDK.BuildTools.15.0.26201 to 15.8.3252 has resolved the issue. The following PR branch seems to build consistently: https://github.com/github/VisualStudio/pull/1929.

[AArnott]

I don’t know if packages.config is ignored automatically given the presence of a PackageReference in your project.

I observe that you’re using packages.config style references for your VS SDK projects. And in particular, you’re getting your VS SDK itself via that reference:

  <Import Project="..\..\packages\Microsoft.VSSDK.BuildTools.14.3.25407\build\Microsoft.VSSDK.BuildTools.props" Condition="Exists('..\..\packages\Microsoft.VSSDK.BuildTools.14.3.25407\build\Microsoft.VSSDK.BuildTools.props')" />

So you’ll be missing targets until you do a package restore that restores packages.config packages. If you had a reference from a .NET SDK style project to one of these VS SDK projects, you may end up failing if the packages.config packages haven’t restored by the time the .NET SDK style project’s restore build had called into its P2Ps. I don’t know if that happens. I don’t ever have .NET SDK style projects reference older style ones – I’m not sure whether that’s supported. You may need to script a restore step that explicitly runs (in effect) nuget restore **\packages.config before allowing the regular restore to take care of everything else.