Building UWP app in command line (using MSBUILD) - jenkins

I am trying to build UWP app (targeting 16299) from command line from Jenkins setup.
The system has only VS build tools 2017.
used this command to build
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild.exe" /t:Rebuild /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms="x86\x64\ARM" /p:BuildAppxUploadPackageForUap=true SOLUTION_FILE.sln
error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\WindowsXaml\v15.0\Microsoft.Windows.UI.Xaml.CSharp.targets" was not found. Also, tried to find "Microsoft\WindowsXaml\v15.0\Microsoft.Windows.UI.Xaml.CSharp.targets" in the fallback search path(s) for $(MSBuildExtensionsPath) - "C:\Program Files (x86)\MSBuild" . These search paths are defined in "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe.Config". Confirm that the path in the declaration is correct, and that the file exists on disk in one of the search paths.
Another issue found is nuget is not restoring any package, so updated nuget to 4.4.1 then I got the error
MSBuild auto-detection: using msbuild version '15.5.180.51428' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin'.
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
same issue with nuget 4.6.0 also
I tried by adding following in project file
<PropertyGroup>
<RestoreProjectStyle>PackageReference</RestoreProjectStyle> </PropertyGroup>
same issue with msbuild and nuget, anyone succeed in building UWP in Jenkins?
Update 05-01-2015
Followed instruction according to answer.
Copied NuGet folder
Copied the "WindowsXaml" folder.
Used MSbuild restore instead of Nuget restore to fix msbuild trying to find packages in "C:\WINDOWS\system32\config\systemprofile.nuget\packages\"
With all these changes no more issues in build,
But the appx bundle is not present. may be individual appx for x86/x64/ARM has to be created and then some kind of merging i s required.
so need further investigations

From the directory path that you have for MSBuild, I see that you may have installed MSBuildTools installer instead of the community, professional,... editions.
I tried that before and found that it's incomplete and doesn't have all dependencies for building Uwp tools, take a look at some of the comments here about the issues.
First Workaround: You can install Uwp Workload from VS Community or Professional as it has all dependencies, till Microsoft fix the issues in BuildTools installer.
Bonus: if you want to run the installer from command line, you can compose command line like that:
vs_installer.exe --installPath "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools" ^
--add Microsoft.VisualStudio.Workload.Universal ^
--add Microsoft.VisualStudio.Component.Windows10SDK.14393 ^
--add Microsoft.Component.MSBuild ^
--passive --wait --norestart
The longer workaround, I managed to install other dependencies but I believe it's kind of hassle if you are automating this installation, snippets from this article
Copy the Sdks folder from a machine that has VS2017 installed at:
c:\Program Files(x86)\Visual Studio\2017\Professional\Build MSBuild\Sdks
to your build machine at:
c:\Program Files(x86)\Visual Studio\2017\Build Tools\MSBuild\Sdks
And for the nuggets issue:
Copying the NuGet import files will do the tr Again, from a machine
with VS2017, copy the following folder: C:\Program Files
(x86)\Microsoft Visual
Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\NuGet
to your build machine at: C:\Program Files (x86)\Microsoft Visual
Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet
Note: If you come by this later and found that Microsoft fixed the issues related to Uwp in MSBuildTools installer, please leave a comment about it in this answer to update it.

Related

Location of nmake in VS2019 is not generic. Or am I missing something?

I am creating a generic script to deploy on the build server to build our project using VS 2019. The location of nmake in VS 2019 is at: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30133\bin. The inclusion of numbers like 14.29.30133 doesn't allow the script to be very generic.
In the earlier generations of VS, nmake paths were like: C:\Program Files\Microsoft Visual Studio 10.0\Vc\bin or C:\Program Files (x86)\Microsoft Visual Studio 11.0\Vc\bin
Maybe I installed MSVC incorrectly? Any help is appreciated. TIA.
You installed MSVC correctly, and yes, this can cause some headaches, because the version number in the folder name changes with every new minor release of VS 2019.
To resolve this, use this command line snippet for getting the path to the latest installed nmake.exe into the variable %NMAKE%:
set VSPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional
for /f %%i in ('dir "%VSPATH%\VC\Tools\MSVC" /b') do set VCTOOLSVERSION=%%i
set NMAKE="%VSPATH%\VC\Tools\MSVC\%VCTOOLSVERSION%\bin\HostX86\x86\nmake.exe"
This works for all intermediate versions of Visual Studio 2019 I tested it with.

F# broken in VS build tools 2019 16.6.0

After installing this version, nothing that touches F# will build, everything throws the same exception:
error FS0193: Could not load file or assembly System.Buffers, Version=4.0.3.0, blablabla..
Apparently it's nothing to do with what I'm building. Even trying to execute let x = 3 in fsi.exe has the same problem.
Anyone else had this problem?
Yes, this is a known problem, see https://github.com/dotnet/fsharp/issues/9295.
While the next fix isn't out yet, you can resolve it by manually copying the missing assemblies. The exact list of missing assemblies is mentioned in this comment. The cause was explained by Kevin Ransom to be that the Setup for MSBuild didn't get the new dependencies for fsc.exe.
Note that FSI from within Visual Studio shouldn't have this issue, nor should building from within Visual Studio 2019. The way I understand it, only the MSBuild Tools are affected.
For posterity, in case the links go dead, the workaround in the Github issue is to just copy the dlls over:
copy "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\PublicAssemblies\*.dll" "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\FSharp"
Edit: the source path given above may not always be correct, depending on what versions of VS you've installed. Alternatively, try:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\PublicAssemblies
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\PublicAssemblies
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\PublicAssemblies
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\PublicAssemblies
If you only want to copy the minimal set that's needed, just copy only these files, that's the diff set:
System.Buffers.dll
System.Memory.dll
System.Numerics.Vectors.dll
System.Reflection.Metadata.dll
System.Resources.Extensions.dll
System.Runtime.CompilerServices.Unsafe.dll
System.Threading.Tasks.Dataflow.dll

.Net-Core Proj - MSBuild failing to copy to output folder

Trying to build to .NET-Core Project from TFS, the build is failing because the following command`s not working, failing to copy built files to output folder. The command is working fine for a .Net Framework project, not working only for .Net Core Project. Kindly check.
It works fine with basic command:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin>MSBuild.exe "C:\TFSFolder\Builds\GUID\DotnetCoreProject.sln" /p:OutDir="C:\TFSFolder\Builds\39\b\DotnetCoreProject\\"
Non-working Command:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin>MSBuild.exe "C:\TFSFolder\Builds\GUID\DotnetCoreProject.sln" /nologo /nr:false /t:"Clean" /dl:CentralLogger,"C:\TFSFolder\Builds\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=2c81e6a8-374d-4a65-91ba-418b04505e77|SolutionDir=C:\TFSFolder\Builds\GUID\"*ForwardingLogger,"C:\TFSFolder\Builds\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:OutDir="C:\TFSFolder\Builds\39\b\DotnetCoreProject\\" /t:Restore /p:platform="any cpu" /p:configuration="release" /p:VisualStudioVersion="15.0" /p:_MSDeployUserAgent="TFS_fa1cf861-541e-47b2-b0f3-8c684de5500a_build_22138_1486294"
It just need to copy built files to the output folder path mentioned. I could only guess that the dll mentioned isnt supported, kindly check and help.
It looks like you are only restoring and cleaning the project because you specify /t:Clean and /t:Restore.
Use -restore -t:Rebuild instead.
Also note that you normally don't want the output directory contents of a .NET Core project for deployment but rather its publish output. For this use the Publish target on the project instead:
-restore -t:Publish theproject.csproj -p:PublishDir=artifact\location

Running vs2017 DevEnv from command line with VS2017 Installer Projects

I have inherited a bunch of VS2010 (argh!) installer projects (.vdproj) that install some Win Services
Ofcourse in VS2017 those don't exist anymore but the extension 'VS2017 Installer Projects' works great. I can just open them fine and build, which produces the msi files.
However this needs to be done on the Jenkins machine (running Windows 7) as well. So I installed VS2017 on the Jenkins machine with the Project Installer extension and tried to first run the project from the IDE. Works great. Produces the .msi without problem.
Then I tried to run it from a command line:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.exe"
D:\ServiceInstaller\xxxServiceInstaller.vdproj /build
And it does NOT produce anything. Am I trying to do something that is not possible?
There are all kinds of long term solutions of course such as TopShelf, AdvancedInstaller, WIX etc with nice Jenkins plugins but for now it would be nice if I could make this work.
I've made following batch file to call with solution file parameter:
CALL "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Tools\VsDevCmd.bat"
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\VSI\DisableOutOfProcBuild\DisableOutOfProcBuild.exe"
devenv /rebuild "Release|Win32" %1
Also make sure that in Visual Studio Configuration Manager Setup build is enabled.

Jenkins not finding a nuget package

I'm setting a Jenkins CI server. I got the first step to run properly:
nuget restore -NonInteractive -ConfigFile Nuget.config -Verbosity Detailed -NoCache
That works properly, but when I want to compile the app with:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe
and ${WorkSpace}\src\Weather.App.csproj
It throws this error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(178,5): error : The package HockeySDK.Core with version 4.1.6 could not be found in C:\WINDOWS\system32\config\systemprofile\.nuget\packages\. Run a NuGet package restore to download the package. [C:\Program Files (x86)\Jenkins\workspace\MyApp\Weather\Weather.App.csproj]
The weird thing is that it the Hockey package clearly exists in the path:
If I run the same command IN my VS2017 local project, everything runs smoothly. But the jenkins server (which is in my same machine) does not build it properly.
Any ideas? Thanks
Here's the trick.
Put nuget.exe somewhere on he build server.
Ensure nuget.exe is in the PATH environment variable.
Restart Jenkins so that it picks up the updated PATH environment variable
Upgrade NuGet to the latest version
nuget.exe update --self
In the Jenkins job calling rebuild against MSBUILD won't successfully restore the nuget packages
Add a Windows Batch step after the MSBUILD Clean and before the MSBUILD Rebuild like so:
nuget restore <your_solution_file>.sln
Path to solution file is workspace relative.
This will create the packages directory as you would expect.

Resources