I'm migrating an on-prem build onto Azure Devops. I am using a default Azure build agent with nothing specified over the default agent config.
Here is the part of the build pipeline YAML that is throwing an error:
- task: NuGetCommand#2
displayName: 'Build Assemblies: Restore'
inputs:
command: 'restore'
restoreSolution: '$(FooSolutionSolution)'
feedsToUse: 'config'
- task: VSBuild#1
displayName: 'Build Assemblies: Run'
inputs:
solution: '$(FooSolutionSolution)'
platform: '$(FooSolutionBuildPlatform)'
configuration: '$(buildConfiguration)'
msbuildArgs: '-t:rebuild'
It is using the standard Microsoft.Common.CurrentVersion.targets file but is failing to find al.exe.
CoreCompile:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Roslyn\vbc.exe /noconfig /imports: {..imports..} /optioncompare:Binary /optionexplicit+ /optionstrict+ /optioninfer+ /nostdlib /platform:AnyCPU /rootnamespace:FooCorp.Central /sdkpath:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1" /highentropyva+ /define:"CONFIG=\"Release\",TRACE=-1,_MyType=\"Windows\",PLATFORM=\"x64\"" /reference: {..references ..} /main:"FooCorp.Central.(None)" /debug- /keyfile:d:\a\1\s\Builds\FooCorpKey\FooCorpKey.snk /optimize+ /out:.\obj\x64\Release\FooSolution\FooCorp.Central.dll /ruleset:"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Team Tools\Static Analysis Tools\\Rule Sets\MinimumRecommendedRules.ruleset" /subsystemversion:6.00 /resource:.{..resources..} /target:library /warnaserror+ /utf8output /langversion:14 AssemblyInfo.vb {..all other vb files..} "C:\Users\VssAdministrator\AppData\Local\Temp\.NETFramework,Version=v4.5.1.AssemblyAttributes.vb"
Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Roslyn
GenerateSatelliteAssemblies:
Creating directory ".\obj\x64\Release\FooSolution\es".
Creating directory ".\obj\x64\Release\FooSolution\ru".
Creating directory ".\obj\x64\Release\FooSolution\zh-CN".
Creating directory ".\obj\x64\Release\FooSolution\lb-LU".
##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(3639,5):
Error MSB6004: The specified task executable location "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\al.exe" is invalid.
This is something that I don't think I can control.
For comparison when I run the build locally from the command line the output from the same part of the build is:
GenerateSatelliteAssemblies:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\al.exe /culture:zh-CN /keyfile:C:\s-gl\Builds\FooCorpKey\FooCorpKey.snk /out:.\obj\x64\Release\FooSolution\zh-CN\FooCorp.Central.Lic.resources.dll /platform:AnyCPU /template:.\obj\x64\Release\FooSolution\FooCorp.Central.Lic.dll /embed:.\obj\x64\Release\FooSolution\FooCorp.Central.Lic.a1.zh-CN.resources /embed:.\obj\x64\Release\FooSolution\FooCorp.Central.Lic.a2.zh-CN.resources /embed:.\obj\x64\Release\FooSolution\FooCorp.Central.Lic.a3.zh-CN.resources
As the build agent is supplied by Azure is there a way I can determine where the SDK tools are located?
Although https://stackoverflow.com/a/42140667 was reported for TeamCity not Azure Devops the solution there was to specify a different path to al.exe . Do I need to do something similar here?
Thanks
According to the logs, it appears that you are using the hosted windows-2019 agent.
By default the NETFX 4.6.1 Tools are not installed on the windows-2019 agent. So it cannot find the al.exe file under "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\al.exe". See Hosted Windows 2019 for details.
However the NETFX 4.6.1 Tools are installed on vs2017-win2016 agent. So, please try using vs2017-win2016 agent instead of the windows-2019 agent.
You can run the following commands in pipeline to check the installed versions
of NETFX tools on each of the agents:
cd 'C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin'
dir
So, to use the latest windows-2019 agent, you can try to specify the path to the SDK editing directly in the [projectname].csproj file, add:
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools</TargetFrameworkSDKToolsDirectory>
Related
I can't build a vs2017 solution from the command line, but I can build from the IDE. Once I've built from the IDE the command line build will work. So the ide is doing something different - what am I missing? Here is what I do for the command line build:
nuget.exe restore mysoln.sln
"E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" /m /t:Rebuild /clp:Summary /p:Configuration=Debug /p:Platform="Any CPU" mysoln.sln
The output I get:
"Forms.csproj" (Clean target) (14:3) ->
E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.TargetFrameworkInference.targets(126,5): error : The current .NET SDK does not support targeting .NET Standard 2.0. Either target .NET Standard 1.6 or lower, or use a version of the .NET SDK that supports .NET Standard 2.0. [E:\wp\Forms.csproj]
Any ideas how I can make the command line build work?
==============
Update
I tried "E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" /m /t:Restore GpsConsole.sln from the command line and it works. But when jenkins runs the exact same command i get the same error
==============
Update 2
The way we got the solution building was :
nuget.exe restore mysoln.sln
"E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" /m /t:Restore mysoln.sln
"E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" /m /t:Rebuild /clp:Summary /p:Configuration=Debug /p:Platform="Any CPU" mysoln.sln
I suggest you rethink you command-line approach.
You can make your build script independent of Visual Studio installation, make it using MSBuild version you want, and reusable on a build server.
Short plan
Install Visual Studio Build Tools 2017
Find proper MSBuild
Clean solution
Restore packages
Build solution
Details
Using Build Tools will give you independence from Visual Studio installation.
Download Build Tools for Visual Studio 2017 from Visual Studio Downloads page (direct link)
Command-line arguments documented here: Use command-line parameters to install Visual Studio 2017
All workloads and components are listed here: Visual Studio Build Tools 2017 component directory
You can use PowerShell module VSSetup. Download it or install from here: Github: Microsoft/Visual Studio Setup PowerShell Module
Just run MSBulid with clean target
Help nuget.exe to use proper MSBuild
Run MSBuild with build target (you can add additional required parameters)
# 1. Find MS Build
Import-Module $PSScriptRoot\VSSetup\VSSetup.psd1
$msBuildPath = (Get-VSSetupInstance | Select-VSSetupInstance -Version 15.0 -Product Microsoft.VisualStudio.Product.BuildTools).InstallationPath
if ([System.IntPtr]::Size -eq 8)
{
$global:msbuildPath = Join-Path $msBuildPath 'MSBuild\15.0\Bin\amd64'
}
else
{
$global:msbuildPath = Join-Path $msBuildPath 'MSBuild\15.0\Bin'
}
Write-Output "Using MSBuild from $global:msbuildPath"
Write-Output "MSBuild /version"
$msbuild = Join-Path $global:msbuildPath msbuild
& $msbuild /version
# 2. Clean
& $msbuild "$sln_file" /t:Clean /v:q /nologo
# 3. Restore
$nuget = Join-Path $PSScriptRoot "\.nuget\nuget.exe"
& $nuget restore -MSBuildPath $global:msbuildPath
# 4. Build
& $msbuild "$sln_file" /t:Build /v:q /nologo
I believe your visual studio does have the .net core 2.0 SDK installed, since it is able to build your .net standard 2.0 solution.
But, nuget restore is pointing to an sdk inside the visual studio directory (one of a few that visual studio can use, but not where .net core 2.0 sdk installs to by default).
Your .net core 2.0 sdk is likely located in C:\...\dotnet\...
You'll want to have nuget restore use the msbuild located inside that directory, rather than the one within the visual studio directory.
How do I target MSBuild 15.0 on my server? I have 15.0 installed on the server but my project is still building with 14.0. I know that Microsoft has made some changes to the directory locations and no longer uses the registry values with 15.0.
I found 15.0 installed in the following locations:
C:\Program Files (x86)\MSBuild\15.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild
And I have the .Net framework 4.6.2 installed here:
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319"
Thanks!
Product: BuildMaster
Version: 5.7.2
Update 1:
Responding to #emiel-koning, I tried to specify $MSBuildToolsPath in the build step using:
set $MSBuildToolsPath = C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin;
But I get this error:
error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" was not found. Also, tried to find "WebApplications\Microsoft.WebApplication.targets" in the fallback search path(s) for $(VSToolsPath) - "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0" . 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.
Update 2:
Could I be missing something installed on my build server? I installed Visual Studio Build Tools which gave me the MSBuild 15.0 but not the WebApplication.targets file from the error above
SOLUTION
I fix my issues by also installing "Web development build tools" component. I also set the $MSBuildToolsPath at the server level until I can roll out the new MSBuild globally.
In general, this is handled by the ToolsVersion attribute of the project file. This should be what is used if the below configuration is not specified.
In BuildMaster specifically, you can override this value per-server on the Administration > BuildMaster Extensions > Windows SDK > Configuration tab. Click on $MSBuildToolsPath (and optionally override at a specific scope) with a value of C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin
Response to Updates #1 & #2:
First, don't set that variable in the plan itself (otherwise you'd have to set it in every plan). Set it in the manner I described above. Personally, I always specify its value at the server level since each server may have it installed in a different location.
As for Microsoft.WebApplication.targets, I think the only supported method of building web application projects is to have Visual Studio installed on the build server; though in the past I've just copied the targets from my local installation (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications) into the path that MSBuild is expecting them to be.
Can you use $MSBuildToolsPath to specify the correct path to MSBuild?
i installed the VS2017 build tools with vs_buildtools.exe --add Microsoft.VisualStudio.Workload.MSBuildTools --quiet
but now when I build with the installed MSbuild, passing the /p:DeployOnBuild=true, there seems to be no attempt to do any of the config transformation, aspnet compilation, or deployment that happens when i use the v14.0 tools.
what extra magic incantation do i have to do to make this work?
Make sure that you use the proper MSBuild.exe.
This:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin
Or if IDE (enterprise) installed:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
If configure an MSBUILD step in a TFS server, set the path of the MSBUILD.exe manualy (Advenced/MSBuild/Specify location):
Using this:
C:\Program Files (x86)\MSBuild\15.0\Bin
will cause that no deployment package created.
The issue is the following:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2863,5):
error MSB3086: Task could not find "AL.exe" using the SdkToolsPath ""
or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86". Make sure the
SdkToolsPath is set and the tool exists in the correct processor
specific location under the SdkToolsPath and that the Microsoft
Windows SDK is installed
I've tried various laborious solutions found on the web, but finally I managed to solved the issue like this:
Go to C:\Windows\Microsoft.NET\Framework\v4.0.30319\
Open with a text editor the file Microsoft.Common.targets
Search for "al.exe" in the file at step 2 and replace the "ToolPath" and "ToolExe" fields with the actual path of the "al.exe" file.
I have setup the two fields at step 3 in the following way:
ToolPath="C:\Program Files (x86)\Microsoft
SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\"
ToolExe ="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\al.exe"
Thanks.
You should register variables before MSBuild call:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vsvars32.bat
I use psake, it registers vars automatically.
Alternative solution - add a param:
msbuild.exe "/p:TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools"
You need to check the path of "msbuild.exe"
I solved the same problem by changing the path
from
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
to
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin
I have a .vbproj which is a VB.NET web application project. I can build the solution that contains this project and then right click on the project and publish locally. No issues from with VS 2013 professional update 3.
I am trying to build this solution and then publish the project outside of VS using the msbuild plugin from within Jenkins CI.
The project does not get published as it says it is skipping unpublishable project.
The command and it output is as follows:
Executing the command
cmd.exe /C C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
/t:Publish /p:VisualStudioVersion=12.0 /p:OutDir=C:/temp/eric
StarWebPortal/StarWebPortal/StarWebPortal.vbproj && exit
%%ERRORLEVEL%% from C:\Tools\Jenkins\jobs\STAR-dev_POC\workspace
[workspace] $ cmd.exe /C
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe /t:Publish
/p:VisualStudioVersion=12.0 /p:OutDir=C:/temp/eric
StarWebPortal/StarWebPortal/StarWebPortal.vbproj && exit
%%ERRORLEVEL%% Microsoft (R) Build Engine version 4.0.30319.18408
[Microsoft .NET Framework, version 4.0.30319.18444] Copyright (C)
Microsoft Corporation. All rights reserved.
Build started 8/22/2014 11:46:51 AM. The target "MvcBuildViews" listed
in a BeforeTargets attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets
(840,131)" does not exist in the project, and will be ignored. Project
"C:\Tools\Jenkins\jobs\STAR-dev_POC\workspace\StarWebPortal\StarWebPortal\StarWebPortal.vbproj"
on node 1 (Publish target(s)).
_DeploymentUnpublishable: Skipping unpublishable project. Done Building Project
"C:\Tools\Jenkins\jobs\STAR-dev_POC\workspace\StarWebPortal\StarWebPortal\StarWebPortal.vbproj"
(Publish target(s)).
Any idea why it works from within VS and not from the msbuild command line?
You have to configure Jenkins to pass two additional arguments to MsBuild.exe which are /p:DeployOnBuild=true and /p:PublishProfile=your_publish_profile.pubxml.
The command should be like msbuild your_vb_project.vbproj /p:DeployOnBuild=true /p:PublishProfile=publish_profile.pubxml You don't need to specified path to publish_profile.pubxml as long as it's under the same directory with your vbproj.
As of Visual Studio 2013, MSBuild is now a separate component from the .NET Framework and is included in the install with VS. It is also available as a separate download for build servers. It looks like you are using the "old" v4.0 MSBuild path. You need to use the new MSBuild path which is something like C:\Program Files(x86)\MSBuild\12.0\bin. You need to configure the Jenkins MSBuild plugin to use this path.