Microsoft.AppxPackage.Targets causes build failures

[Sarabeth-Jaffe-Microsoft]

Customer reported the following issue:

Description: When attempting to run a build using MSBuild in a batch file, projects are failing due to the following exception:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(283,22): error MSB4086: A numeric comparison was attempted on "10.0.11000.0" that evaluates to "10.0.11000.0" instead of a number, in condition "'$(TargetPlatformVersion)' >= '10.0.11000.0'". [MyProject.csproj] 

This appears to be caused by the following segment within Microsoft.AppXPackage.Targets:

 <PropertyGroup> 
 <SdkIsRS1OrLater>False</SdkIsRS1OrLater> 
 <SdkIsRS1OrLater Condition="'$(TargetPlatformVersion)' &gt;= '10.0.11000.0'">True</SdkIsRS1OrLater> 
 </PropertyGroup> 

Switching the VisualStudioVersion flag in the batch file from 14.0 to 12.0 causes this batch file to build successfully. Additionally, it was running fine with 14.0 prior to the upgrade to Update 3.

Strangely, this appears to build fine when running directly inside Visual Studio.

Visual Studio Version: 14.0.25421.03

Repro Steps:Create a batch file with the following script. When running the build, the error will surface.

 @echo off 
 set CLRHome=%SystemRoot%\Microsoft.NET\Framework\v4.0.30319 
 set MSTestDir=%vs140comnTools%..\IDE 
 Set VisualStudioVersion=14.0 
 set Path=%Path%;%CLRHome%;%MSTestDir% 

 MSBuild ./LocalBuild.proj /v:m /clp:Summary; /m:%multiCore% /nr:False /nologo 

Impact: Builds are unable to run with ToolsVersion 14.0. Any developer running exclusively 2015 updating to Update 3 will be unable to build the solutions from the batch files.

[Sarabeth-Jaffe-Microsoft]

Starting point: investigate changes on Property functions before/after Dev14 Update 3.

[ObsidianPhoenix]

I have attached a sample application that is seeing this issue. With VS2015 Update 3 installed, execute RunLocalBuild.cmd within the solution folder.

Commenting the line in the .targets file (noted above) stops this issue occurring.

DemoApp1.zip

[vchelaru]

I have also encountered this with the following simple repro steps:

1. Create a UWP app in Visual Studio
2. Load the unmodified .csproj file using the constructor for Microsoft.Build.Evaluation.Project which takes a string for file name
3. Observe the exception

[rainersigwald]

@vchelaru How are you referencing MSBuild in the project that builds the code in which you do the project load? Do the references point to version 14.0, or 4.0?

There are two copies of MSBuild on most machines--one (4.0) installed with the .NET Framework (removing it would be a breaking change in the framework, so we leave it there, stale), and one (14.0) installed with Visual Studio or the Build Tools installer. New functionality is available only in the up-to-date assembly, and version-number comparisons were added in the 12.0 timeframe (I think).

[vchelaru]

@rainersigwald thanks so much for taking the time to respond.

I am referencing the following assembly:

Assembly Microsoft.Build, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6\Microsoft.Build.dll

So you're saying that I could reference the .dll that comes with Visual Studio to work around this issue? If so, does that mean I will have to distribute the .dll with my app? I can't count on users of my app to have VS installed, so I can't use the VS-installed version in its install location.

[rainersigwald]

@vchelaru That is a stale version of MSBuild. To understand UWP projects within your app, you'll have to use the newer binaries. To get MSBuild 14.0 installed, you can use the Build Tools 2015 Update 3 installer--you don't have to have all of VS installed.

Right now, that installer is the only way to get MSBuild installed. For the next release, we should have official NuGet packages that you could consume.

[ObsidianPhoenix]

Just to confirm, this does appear to be an MSBuild version issue. If I replace the top of the batch file from

@echo off 
set CLRHome=%SystemRoot%\Microsoft.NET\Framework\v4.0.30319 
set MSTestDir=%vs140comnTools%..\IDE 
Set VisualStudioVersion=14.0 
set Path=%Path%;%CLRHome%;%MSTestDir% 

MSBuild ./LocalBuild.proj /v:m /clp:Summary; /m:%multiCore% /nr:False /nologo 

to

@echo off
call "%vs140comnTools%\VsDevCmd.bat"

MSBuild ./LocalBuild.proj /v:m /clp:Summary; /m:%multiCore% /nr:False /nologo 

This problem resolves.

[aolszowka]

Hello,

We're also repo'ing this in our area; to work around it we've commented out Line 283 in Microsoft.AppxPackage.Targets:

<!--<SdkIsRS1OrLater Condition="'$(TargetPlatformVersion)' &gt;= '10.0.11000.0'">True</SdkIsRS1OrLater>-->

Thank you

[kzu]

I fixed this by specifying ToolsVersion="14.0" in the .csproj, rather than some old 4.0 or 12.0 I had on some projects.

[StacyHenwood]

Are there any updates to this? we are currently dealing with a broken TFS 2012 build server due to this.

We have a Xamarin PCL project with UWP, WinPhone (8.0, Silverlight) & Android projects.

If I don't set the tools version, I get this error in the UWP project.

C:\Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v14.0\Microsoft.Windows.UI.Xaml.Common.targets (6): A numeric comparison was attempted on "$(TargetPlatformMinVersion)" that evaluates to "10.0.10240.0" instead of a number, in condition "'$(TargetPlatformIdentifier)' == 'UAP' And '$(TargetPlatformMinVersion)' != '' And '$(TargetPlatformMinVersion)' > '10.0.10587.0'".

If I set the tools version (/tv:14.0) I get the following (x4) as well as the one above.

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets (283): A numeric comparison was attempted on "10.0.11000.0" that evaluates to "10.0.11000.0" instead of a number, in condition "'$(TargetPlatformVersion)' >= '10.0.11000.0'".

Has anyone actually got this working on a build server?

We have actually ended up trying to install VS2015 on the build server, but this still doesn't work, as well as installing the MSBuild tools update 3 from the link above.

[Nyami]

@StacyHenwood If you are using v14 of the tools you must use MSBuild v14 (ie the one from the Visual Studio 14.0 tools folder) to build your solution.

I suspect your TFS Build server will either be using MSBuild v12 from Visual Studio 12.0 tools folder or v4.x from the .net framework. I don't recall how this is controlled for your build but it might the the ToolPath property.

[StacyHenwood]

@Nyami Thanks for the information. That's what I thought I was doing, by setting the /tv:14.0 and /p:VisualStudioVersion=14 settings in the MSBuild parameters in the build template (TfvsTemplate.12.xaml). Note that this template does not have a ToolsPath option, so I cant just update it there.

When I look in the logs I see some very strange things.

Near the start I see the following: Run optional script before MSBuild MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.

But further on, where the errors are, I see this (note: wrong tools version): Run MSBuild C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe /nologo /noconsolelogger "C:\Builds\2[SNIP]

My google-fu must be weak today, because I cannot find out how to make the build server use the correct version of the tools with that template.

[Nyami]

I think the path for MSBuild will be set on the "Run MSBuild" activity within TfvsTemplate.12.xaml, if this is the case you should update the template.

edit: My google-fu appears to be strong today.. http://stackoverflow.com/a/32262541/802228

[StacyHenwood]

@Nyami I have previously looked at that stackoverflow article, and discovered that it is not using the TfvcTemplate.12.xaml template - it is using an older one, and the parameters have changed significantly.

The TfvcTemplate.12.xaml template does not have the ToolPath parameter within the Run MSBuild parameter.

I appreciate your continued help.

[StacyHenwood]

Ok, so I have managed to get the correct version of MSBuild to run in my builds.

Its definitely a hack, but its the only way I could get this to work properly.

I have changed the following Registry keys:

HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild\12.0\MSBuildOverrideTasksPath
HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\12.0\MSBuildToolsPath

from: C:\Program Files (x86)\MSBuild\12.0\bin\

to: C:\Program Files (x86)\MSBuild\14.0\bin\

I realise that this is most definitely not going to be the recommended way of doing this, but there seems to be no way of forcing TFSBuild to use the correct version any other way.

[develohpanda]

What is the status of this - is it still work in progress? Still experiencing this issue with VS15 Update 3, and have managed to resolve by commenting out line 283 in Microsoft.AppxPackage.Targets as per a previous recommendation.

[rainersigwald]

Closing this as there's nothing more we can do from our side. The entry-point MSBuild must be a new enough MSBuild.