My TFS Build task in Windows Server 2012 R2 fails throwing the error as stated below
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (2863, 5)
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
Copied AL.exe from different location and pasted in C:\Program Files (x86)... as suggested here but it didn't solve my issue.
Install the Windows SDK from Microsoft site and/or configure RegEdit. This should work
For anyone out there, if you ware trying to update your Visual Studio Build Tools to newer version, make sure that "Build" task in tfs finds proper MSBuild folder- if agent that runs the build is old, it might not find new Visual Studio Build Tools. I just changed method of locating MSBuild from "Specyfic Version" to "Specyfic Path" in "Build" and pointed to new VS Build Tools
Related
Here the repro steps:
Start VS 2017
Create a cross-platform project ==> Sample.sln
Build it in VS ==> Ok
By building with it with the command "msbuild Sample.sln" I get 4 times the following error message: error MSB4066: The attribute "Version" in element "PackageReference" is unrecognized.
Anything missing in the .csproj files I am supposed to add?
Thanks in advance for your support.
Make sure that you use the path to msbuild.exe that is installed with Visual Studio. Use the Developer Command Prompt for Visual Studio 2017 if unsure, it has the PATH set up so that msbuild will point to the right executable.
This error happy when you use an old version of MSBuild (e.g. the version included in .NET Framework) that doesn't support the necessary features - metadata as attributes in this case.
I'm trying to set up Jenkins in a Windows Server 2012 and Visual Studio 2015 and I cannot build my application using MSBuild, I get some Windows SDK issue.
(ResolveComReferences target) ->
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(2015,5):
error MSB3091: Task failed because "AxImp.exe" was not found, or the
correct Microsoft Windows SDK is not installed. The task is looking
for "AxImp.exe" in the "bin" subdirectory beneath the location
specified in the InstallationFolder value of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86. You may be able to solve
the problem by doing one of the following: 1) Install the Microsoft
Windows SDK. 2) Install Visual Studio 2010. 3) Manually set the
above registry key to the correct location. 4) Pass the correct
location into the "ToolPath" parameter of the task.
I've tried the following:
Create the Registry key pointing to the SDK installed. No sucess.
Uninstall all C++ Compilers, download Windows 7 SDK iso and install, as explained here. No success.
Modify Visual Studio 2015 installation adding and removing components, marking explicitly SDKs to be installed. No success.
When building from Visual Studio it builds fine.
I really don't know what's happening here and why I cannot get it working, seems a bug to me regarding Windows or Visual Studio 2015.
The solution was much easier than it seemed to be, just changing the ToolsVersion of the Project node from 4.0 to 14.0 made the trick:
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
So I had a really similar issue, using Jenkins and Msbuild to build projects, and getting this same error.
My solution steps:
first find out IF Aximp.exe exist on the Jenkins machine. I don't have access to the machine, so I included a stage in my jenkinsfile to run this command:
//temp, try and get location of aximp.exe on build machine
bat 'dir "C:\\Program Files (x86)\\Microsoft SDKs\\Windows" /b /s aximp.exe'
I then reviewed the output to see where it lives.
then, I added a parameter to my msbuild command in my jenkinsfile like this:
bat 'msbuild mysolution.sln /p:VisualStudioVersion=14.0 "/p:TargetFrameworkSDKToolsDirectory=C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v10.0A\\bin\\NETFX 4.6.2 Tools" ' //your folder where aximp.exe lives
And the build now runs!
I'm using Windows 7 SP1 and Visual studio Ultimate 2013. TFS server 2013 is installed in Windows Server 2008.
Below error occurred while trying to build one solution which supports multilingual resx files:
C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets
(3001): Task could not find "AL.exe" using the SdkToolsPath "" or the
registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.1A\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 have gone through similar questions, but those solutions didn't work. Few are given below:
Install Windows SDK
Windows SDK is already installed
al.exe is present in C:\Program Files\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
al.exe is present in \Windows\v7.0A\bin and v8.0A\bin\NETFX 4.0 Tools
Remove resx files and build
Resx files are part of the project and I want them to be in my build.
Any idea to fix this issue?
Thanks for your comments. I installed Windows SDK in server machine, where TFS is installed. It solved my problem.
My configuration:
VS2010 solution
TFS 2008
Build server - TFS 2008
Build server also has VS2008 Team Suite and VS2010 ultimate installed
TFS 2008 builds my VS2010 solution properly. But when it comes time to run the unit tests I get the following MsTest error.
Using "TestToolsTask" task from
assembly "D:\Program Files\Microsoft
Visual Studio
9.0\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll".
Task "TestToolsTask" Command:
d:\Program Files\Microsoft Visual
Studio 10.0\Common7\IDE\MSTest.exe
/nologo
/searchpathroot:"D:\Builds\App\Source\86\Binaries"
/resultsfileroot:"D:\Builds\App\Source\86\TestResults"
/testcontainer:"D:\Builds\App\Source\86\Binaries\\Tests.dll"
/publish:"http://tfsServer:8080/"
/publishbuild:"vstfs:///Build/Build/26029"
/teamproject:"Proposal" The
"TestToolsTask" task is using
"MSTest.exe" from "d:\Program
Files\Microsoft Visual Studio
10.0\Common7\IDE\MSTest.exe". No platform specified for publish
operation. For switch syntax, type
"MSTest /help"
MSBUILD : warning MSB6006: "MSTest.exe" exited with code 1.
[D:\Builds\App\Source\86\BuildType\TFSBuild.proj]
The previous error was converted to a
warning because the task was called
with ContinueOnError=true. Build
continuing because "ContinueOnError"
on the task "TestToolsTask" is set to
"true". Done executing task
"TestToolsTask" -- FAILED.
I am not sure what is causing MsTest to fail.
Things tried:
- Provided write access to the build folder to the service account that builds the source on the build machine
You can execute a VS2010 build from within TFS2008's MSBuild, but it looks as if it's using Visual Studio 9.0 TestToolsTask (2008) to try to run a Visual Studio 10.0 (2010) test project (MSTest.exe). I'd try tweaking MSBuild to run the TestToolsTask from the "Microsoft Visual Studio 10.0" folder rather than "9.0", so that the entire process is using the same version of the tools. You can override the tools paths in your tfsbuild.proj file's Properties to ensure the correct version of Visual Studio is used to build with - something similar may apply to the test tools.
Alternatively, it's running the VS2010 test tools correctly, but still trying to use a command line that is specific to 2008 - check the settings and see if you can tweak the command line (you may need to override the MS targets files that is running the build if it's a 2008 version). For example in TFS 2010, a lot of command lines changed from using a simple "server:MyServer" to something like "collection:http://MyServer:8080/tfs/MyCollection". You may therefore have to alter the command line to gain full compatibility with the 2010 version of the tool that is now running, even if it still ultimately points at a 2008 server.
My third suggestion (which isn't necessarily very helpful) is to just upgrade to TFS2010 - it's typically a painless install, vastly better than 2008, and will eliminate any difficulties caused by using a hybrid 2008/2010 setup. (If it helps, I was reluctant to upgrade to 2010 because the 2005->2008 upgrade was 8 days of sheer hell. But in comparison the core of the upgrade to 2010 only took a few hours and "just worked" - the install/upgrade process is much improved)
Jason had the correct idea that lead me down to the correct solution.
In my case, I had to update the "Microsoft.TeamFoundation.Build.targets" to point to "Microsoft.TeamFoundation.Build.ProcessComponents.dll" (VS2010 dll) instead of "Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll" (VS2008 dll)
I also had to make sure that the PlatformToBuild was specified in the TfsBuild.proj file.
Once these 2 steps were done, UnitTests were being run as part of the CI build using TFS2008 and a VS2010 solution.
I have blogged about the solution in detail here: http://blog.aggregatedintelligence.com/2011/03/vs2010-tfs-2008-and-unit-tests.html
I seem to be unable to install a build agent on our TeamCity 5.1.2 build server that is compatible with a VS2010 (sln) build configuration.
Under "Build Runners", the following runners are listed:
Ant: Runner for Ant build.xml files
Duplicates finder (.NET): C# and VB duplicate code finder
Command Line: Simple command execution
And under "Compatible configurations", the project I've configured to build with the Visual Studio 2010 (sln) build runner is listed under "Incompatible configurations".
To install the build agent, I'm simply running the .msi installation package, but it seems the default settings are not good enough. The build server machine has Visual Web Developer Express 2010 as well as .NET versions 2.0-4.0 installed, but no full version of VS. Do I need anything more?
(I have no experience whatsoever of building with msbuild scripts, so if I can I want to avoid having to do that.)
I think I figured it out:
Install the Windows SDK from Microsoft. Right now, the latest version is 7.1.
Note that since I just suddenly noticed that it worked, I don't know for certain that this is what did it - it might me completely irrelevant, but this is the only thing in my configuration I changed that I think could be relevant.
TeamCity build agent does not detect .NET 4.0 Client Profile as dotNetFramework4.0. Check you have full .NET Framework 4.0 installed.
Another reason of that is build agent has corrupted plugins. To fix it:
- stop agent
- remove /plugins, /system, /tools folders
- start agent
- wait till agent autoupgrade (agent service may be shown as stopped, just wait)