MSBuild fails on UWP project - msbuild

I have in my solution two project, MyProject.Core and MyProject.UnitTests, both of them UWP. From VS I can build and run them with no problem, but when I try to build the UnitTests project from the command line, using MSBUILD.exe I get this error:
C:\Program File x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets(140,5): error : Your project.json doesn't list 'win10' as a targeted runtime. You should add '"win10": { }' inside your "runtimes" section in your project.json, an
d then re-run NuGet restore
The error is totally misleading. I've noticed that when I remove the reference to the Core project, it does work. I think it has something to do with the references of the Core project. I've tried adding them manually, but no luck.
Here is the full console output:
GetInstalledSDKLocations:
Searching for SDKs targeting "UAP, 10.0.14393.0".
Searching for SDKs targeting "Windows, 8.1".
ResolveSDKReferences:
Reading SDK manifest file "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\MSTestFramework.Universal\14.0\SDKManifest.xml".
Targeted configuration and architecture "Retail|x86"
No FrameworkIdentity attributes were found in the SDK manifest, treating this SDK as a non-framework SDK.
No "APPX" attributes indicating app package locations were found in the SDK manifest. If an app package is required at runtime the project may not run.
Reading SDK manifest file "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\TestPlatform.Universal\14.0\SDKManifest.xml".
Targeted configuration and architecture "Retail|x86"
No FrameworkIdentity attributes were found in the SDK manifest, treating this SDK as a non-framework SDK.
No "APPX" attributes indicating app package locations were found in the SDK manifest. If an app package is required at runtime the project may not run.
ExpandSDKReferences:
Enumerating SDK Reference "MSTestFramework.Universal, Version=14.0" from "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\MSTestFramework.Universal\14.0\".
Adding reference "References\CommonConfiguration\neutral\Microsoft.VisualStudio.TestPlatform.UnitTestFramework.AppContainer.dll".
Adding reference "References\CommonConfiguration\neutral\Microsoft.VisualStudio.TestPlatform.UnitTestFramework.dll".
Adding file "Redist\CommonConfiguration\neutral\Microsoft.VisualStudio.TestPlatform.Extensions.MSAppContainerAdapter.dll" from redist folder with target path "Microsoft.VisualStudio.TestPlatform.Extensions.MSAppContainerAdapter.dll".
Enumerating SDK Reference "TestPlatform.Universal, Version=14.0" from "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\TestPlatform.Universal\14.0\".
Adding reference "References\CommonConfiguration\neutral\Microsoft.VisualStudio.TestPlatform.TestExecutor.Core.dll".
Adding file "Redist\CommonConfiguration\x86\vstest.executionengine.WindowsPhone.dll" from redist folder with target path "vstest.executionengine.WindowsPhone.dll".
Adding file "Redist\CommonConfiguration\x86\vstest_executionengine_platformbridge.dll" from redist folder with target path "vstest_executionengine_platformbridge.dll".
Adding file "Redist\CommonConfiguration\neutral\Microsoft.VisualStudio.TestPlatform.Common.dll" from redist folder with target path "Microsoft.VisualStudio.TestPlatform.Common.dll".
Adding file "Redist\CommonConfiguration\neutral\Microsoft.VisualStudio.TestPlatform.Core.dll" from redist folder with target path "Microsoft.VisualStudio.TestPlatform.Core.dll".
Adding file "Redist\CommonConfiguration\neutral\Microsoft.VisualStudio.TestPlatform.ObjectModel.dll" from redist folder with target path "Microsoft.VisualStudio.TestPlatform.ObjectModel.dll".
Adding file "Redist\CommonConfiguration\neutral\vstest_executionengine_platformbridge.winmd" from redist folder with target path "vstest_executionengine_platformbridge.winmd".
C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets(140,5): error : Your project.json doesn't list 'win10' as a targeted runtime. You should add '"win10": { }' inside your "runtimes" section in your project.json, and
then re-run NuGet restore.
Here it is the project.json of the projects (both of them are identical at the moment, since I've added all the dependancies of the Core to the Unit Tests project)
{
"dependencies": {
"CommonServiceLocator": "1.3.0",
"HockeySDK.UWP": "4.1.6",
"Microsoft.NETCore.UniversalWindowsPlatform": "5.2.2",
"Microsoft.Xaml.Behaviors.Uwp.Managed": "2.0.0",
"MvvmLight": "5.3.0",
"MvvmLightLibs": "5.3.0",
"Newtonsoft.Json": "9.0.1",
"System.Reactive": "3.1.1"
}, "frameworks": {
"uap10.0": {}
},
"runtimes": {
"win10-arm": {},
"win10-arm-aot": {},
"win10-x86": {},
"win10-x86-aot": {},
"win10-x64": {},
"win10-x64-aot": {}
}
}

To recreate at the command line, a build that Visual Studio can do successfully, see the instructions at https://msdn.microsoft.com/en-us/library/jj651643.aspx to see the commands that VS uses.
Quick summary: Set Build output verbosity to 'Diagnostic'

Related

How do I get the Microsoft.Data.SqlClient.SNI native binaries copied to the bin directory of a web application that targets .NET Framework 4.7.2?

How can I <Import> a .targets file that is included in <PackageReference>d NuGet package in a non-SDK-style web application project that targets .NET 4.7.2?
Background
The web application project is not an SDK-style project. It references a class library project in the same solution. This class library project is an SDK-style project. It has a package reference to Microsoft.Data.SqlClient version 4.1.0, which depends on Microsoft.Data.SqlClient.SNI.runtime 4.0.0. The latter contains native binaries which are automatically copied to the bin directory of the project.
The native binaries are not copied to the bin directory of the web application project. This is probably because of this:
SNI is the native C++ library that SqlClient depends on for various network operations when running on Windows. In .NET Framework applications that are built with the MSBuild Project SDK, native DLLs aren't managed with restore commands. So a ".targets" file is included in the "Microsoft.Data.SqlClient.SNI" NuGet package that defines the necessary "Copy" operations.
The included ".targets" file is auto-referenced when a direct dependency is made to the "Microsoft.Data.SqlClient" library. In scenarios where a transitive (indirect) reference is made, this ".targets" file should be manually referenced to ensure "Copy" operations can execute when necessary.
Recommended Solution: Make sure the ".targets" file is referenced in the application's ".csproj" file to ensure "Copy" operations are executed.
Source
Not sure what "built with the MSBuild Project SDK" means exactly, but I think my scenario qualifies.
Now I'm trying to implement the recommended solution, but I cannot get it to work.
What I did
Step 1: add package reference to Microsoft.Data.SqlClient.SNI version 4.0.0:
<PackageReference Include="Microsoft.Data.SqlClient.SNI">
<GeneratePathProperty>true</GeneratePathProperty>
<Version>4.0.0</Version>
</PackageReference>
I added <GeneratePathProperty> because of step 2 below. According to the documentation this should make a property available that can be used to refer to files in the package:
Sometimes it is desirable to reference files in a package from an MSBuild target. In packages.config based projects, the packages are installed in a folder relative to the project file. However in PackageReference, the packages are consumed from the global-packages folder, which can vary from machine to machine.
To bridge that gap, NuGet introduced a property that points to the location from which the package will be consumed.
Step 2: import the targets file:
<Import Project="$(PkgMicrosoft_Data_SqlClient_SNI)\build\net46\Microsoft.Data.SqlClient.SNI.targets" Condition="Exists('$(PkgMicrosoft_Data_SqlClient_SNI)\build\net46\Microsoft.Data.SqlClient.SNI.targets')" />
You can see that the package contains this targets file using the NuGet package explorer (link). The PkgMicrosoft_Data_SqlClient_SNI property is named according to the documentation (linked above) and based on their example:
MSBuild properties and package identities do not have the same restrictions so the package identity needs to be changed to an MSBuild friendly name, prefixed by the word Pkg.
Step 3: verify the tool versions on our agent:
MSBuild 16.11.2.50704 (installed on the agent C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\bin)
NuGet 6.1.0.106 (installed via a pipeline task)
According to the documentation linked above, these fulfil the minimum requirements (MSBuild 16 and NuGet 5).
Step 4: run nuget restore on our build agent and then build the project using the Azure DevOps MSBuild#1 task with msbuildArguments: '/t:Build'.
Step 4: collect output and publish as an artifact.
Outcome:
The SNI files are not present in the output. When building locally with MSBuild 17.0.0.52104 (installed in 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\bin') I do see the SNI files.

Your project is not referencing the ".NETPortable,Version=v4.5,Profile=Profile78"

When i build my PCL project i received the following error:
Microsoft.NuGet.targets(186, 5): [null] Your project is not referencing the ".NETPortable,Version=v4.5,Profile=Profile78" framework. Add a reference to ".NETPortable,Version=v4.5,Profile=Profile78" in the "frameworks" section of your project.json, and then re-run NuGet restore.
Following error appears when you have .netstandard project in same directory and build it once.
It leaves .json files in Obj directory and it breaks PCL project build.
Move .netstandard .csproj out of this directory and remove Bin and Obj directories.

MSBuild.Community.Tasks issue with vs2017

Folks I've a set of services first created in 2012, which - down the years - have seamlessly built with Vs2010, Vs2013 & Vs2015.
When I try to build with Vs2017 I get
The MSBuild.Community.Tasks.Attrib task could not be loaded from the assembly
The assembly lives under the C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks folder, however there is no MSBuildCommunityTasks folder under the \2017\Professional\MSBuild folder.
Here's the full error
C:\working\MySolution\build\Build.proj" (default target) (1) ->
(SetAssemblyVersion target) ->
C:\working\MySolution\build\Build.proj(100,5): error MSB4062: The "MSBuild.Community.Tasks.Attrib" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.dll.
Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.dll' or one of its dependencies.
The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What changed between Vs2015 and Vs2017?
What do I need to do to fix this?
Explicitly setting the MSBuildCommunityTasksPath property gets past the problem.
I do this at the top of my build.proj file.
(For historic reasons we keep the community build tasks in our repo, which is why it's set to a location under trunk)
<MSBuildCommunityTasksPath>$(trunk)\Ref\Build\MSBuildCommunityTasks</MSBuildCommunityTasksPath>
The extensions are most likely installed in 'C:\Program Files (x86)\MSBuild'. So I currently set the variable explicitly in my proj as a workaround.
<MSBuildExtensionsPath>C:\Program Files (x86)\MSBuild</MSBuildExtensionsPath>
Installing .Net Framework 3.5 development tools in VS2017 individual components section fixed my build.

How do I embed StyleCop in the solution?

I try to integrate StyleCop in a Visual Studio solution. Installing StyleCop on each machine of each developer is something I would prefer to avoid. The suggestion I've seen several times (example) is to include the binaries of StyleCop within the project, storing them in version control.
I did that. It works on my machine, but fails on a different machine where StyleCop is not installed. After uninstalling StyleCop on my machine, it doesn't work there either.
The error message is the following:
Severity Code Description Project File Line
Error The "StyleCopTask" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild..\StyleCop 4.7\StyleCop.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\StyleCop 4.7\StyleCop.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. Demo
This is what I included in every .csproj file:
<Import Project="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.targets" />
The directory C:\demo\externs\Microsoft.StyleCop contains:
The copy of all the files from C:\Program Files (x86)\StyleCop 4.7,
The copy of C:\Program Files (x86)\MSBuild\StyleCop\v4.7\StyleCop.Targets.
What's wrong?
It appears that StyleCop.Targets contains an absolute path:
<UsingTask
AssemblyFile="$(MSBuildExtensionsPath)\..\StyleCop 4.7\StyleCop.dll"
TaskName="StyleCopTask"/>
In order to be able to use StyleCop on machines where the application is not installed, change this path to something similar to:
<UsingTask
AssemblyFile="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.dll"
TaskName="StyleCopTask"/>

Database msbuild publish not working from command line

I am trying to Publish a .sqlproj from command line with MSBuild with the command:
msbuild /t:Publish [MySqlProjPath] but i get the following error:
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
What i find weird is that from Visual Studio 2012 i can Publish the same project successfully. Does Visual Studio set any magical msbuild property before publishing to get the .targets file from another directory?
You should pass the following argument to MSBuild:
/p:VisualStudioVersion=11.0 /t:Rebuild;Publish
This tells msbuild to use VS2012 targets.
Passing VisualStudioVersion is required hence VS2010 and Vs2012 can share the same project file: i.e. project file does not store target VS version inside itself