I am currently doing an invoke process from my custom XAML build definition to run VSTest.Console.exe with some parameters. I have hard coded the path to the Visual Studio folder in the FileName property. I would like to use the $(VSINSTALLDIR) variable instead of hard coding the C:\Program Files (x86)\Microsoft Visual Studio 14.0\ portion of the path since I believe that the $(VSINSTALLDIR) points to the latest (or perhaps last?) installed version of Visual Studio.
Below is my current InvokeProcess XAML directive:
<mtbwa:InvokeProcess Arguments="[msTestParamsBuilder.ToString()]" DisplayName="Invoke VSTest.Console for Test Assemblies" FileName="C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\VSTest.Console.exe" sap2010:WorkflowViewState.IdRef="InvokeProcess_4" WorkingDirectory="[BuildDirectory]">
$(VSINSTALLDIR) is not the environment variables in TFS. TFS build does not apply the value of $(VSInstallDir) macros (C:\Program Files (x86)\Microsoft Visual Studio 14.0\ ) Detail info about the environment variables in TFS build please refer this link: Team Foundation Build environment variables
In your case, you need to add the value in XAML build config:
Process->Build->5. Advances->MSBuild arguments add /p:VSInstallDir = Value
Related
I am setting up a new TeamCity build agent. Several build configurations that run perfectly well on the existing agent are failing on the new agent, with errors like this (whitespace added for clarity):
[22:14:32][someproject.vbproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Microsoft.VisualBasic.CurrentVersion.targets(322, 5):
error MSB4019: The imported project
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Roslyn\Microsoft.VisualBasic.Core.targets"
was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Note the path on line three after "The imported project". The error is correct; the folder does exist but the file does not exist there. However the Microsoft.VisualBasic.Core.targets file does exist at a slightly different path
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Roslyn\Microsoft.VisualBasic.Core.targets
Is there an easy fix for this, perhaps a registry entry telling MSBuild where to look?
Cause
On your machine, there are two copies of VS 2017 installed, Professional edition and the raw Build Tools.
You didn't install VB bits for Professional, while did that for Build Tools.
TeamCity prefers MSBuild from Professional edition.
Combine all above, the issue happened.
Fix
You should either force TeamCity to use MSBuild from Build Tools, or add VB to your VS Pro installation.
Reference
https://blog.lextudio.com/the-rough-history-of-msbuild-cc72a217fa98
When enabling Static Code Analysis on my builds, I get the following error thrown by MSBuild:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Microsoft.CSharp.CurrentVersion.targets(134,9): warning MSB3884: Could not find rule set file "AllRules.ruleset". [C:\Program Files\VSTS Agent_work\PATH_TO_MY.csproj]
To get Static Code Analysis working on build agents (only MSBuild, no Visual Studio), for older versions of the build tools one would:
Copy C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets\ to the build server
Add a registry entry pointing to that folder
(see also this bug report)
However, these instructions doesn't work with "Build Tools for Visual Studio 2017". I'd like to know how I resolve this, without needing to copy the rulesets into my own repository or changing anything in my csproj?
Update:
I've tried setting the following registry key, to no avail:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0\Setup\EDev]
"StanDir"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\Team Tools\\Static Analysis Tools"
Digging through the registry, I've found that the following registry keys. On my machine I've installed both VS2017 Build Tools and Test Agent, and it seems like this points to the latter, which I have installed after installed Build Tools:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7]
"15.0"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\TestAgent\\"
"14.0"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\"
Update 2:
Both answers mention the file Microsoft.CodeAnalysis.Targets. However this file is not present on my build server. I've tried copying this folder over from my VS2017 installation:
from: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\CodeAnalysis
to: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\CodeAnalysis
However besides the rulesets not being found, it now also throws errors about being unable to find Microsoft.WebApplication.targets:
XXX.csproj(296,11): error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuil
d\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 $(VSToo
lsPath) - "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:
Based on my test, you don't need to change anything manually, just need to install the default components of Build Tools for VS2017, then the necessary files will be added automatically.
Old:
Regarding default folder of code analysis files, you can check Microsoft.CodeAnalysis.targets file:
<PropertyGroup>
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'=='' and Exists('$(VsInstallRoot)\Team Tools\Static Analysis Tools\')">$(VsInstallRoot)\Team Tools\Static Analysis Tools\</CodeAnalysisStaticAnalysisDirectory>
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the first registry path, assume we're in a 64bit process. -->
<!-- read registry from Wow6432Node -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- if we didn't find the registry path yet, then try Win8 Express location -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Microsoft\VSWinExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, then try Win8 Express 64-bit location -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VSWinExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, try WP Express locations -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Microsoft\VPDExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, try WP Express 64-bit locations -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VPDExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, try WD Express locations -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Microsoft\WDExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, try WD Express 64-bit locations -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\WDExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- Default rule set search paths -->
<CodeAnalysisRuleSetDirectories Condition=
"'$(CodeAnalysisIgnoreBuiltInRuleSets)'!='true' and
'$(CodeAnalysisStaticAnalysisDirectory)'!=''">$(CodeAnalysisRuleSetDirectories);$(CodeAnalysisStaticAnalysisDirectory)\Rule Sets</CodeAnalysisRuleSetDirectories>
<!--
In scenario where we run CA from command-line , we don't get "CodeAnalysisVSSku" variable passed by the IDE, so in case of Express-only installation
we attempt to load rule sets that are only present on Pro and above - and fail. Let's assume we're in "Express" mode if the Pro+ rule set doesn't exist.
-->
<CodeAnalysisVSSku Condition="'$(CodeAnalysisVSSku)'=='' and !Exists('$(CodeAnalysisStaticAnalysisDirectory)\Rule Sets\NativeRecommendedRules.ruleset')">Express</CodeAnalysisVSSku>
</PropertyGroup>
Based on the code, you just need to put the code analysis rule files in $(VsInstallRoot)\Team Tools\Static Analysis Tools folder and the value of $(VsInstallRoot) is C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools if you just install Build Tools for Visual Studio 2017 on the build server.
To conclude, you just need to put rule files in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Team Tools\Static Analysis Tools folder.
Officially you'd need to install Visual Studio onto the build server, as the Code Analysis these rules come from are part of Visual Studio, not of MsBuild.
You can still copy the Static Analysis directory to your build server and supply the following parameter to MsBuild in the Additional Arguments option:
/p:CodeAnalysisStaticAnalysisDirectory=c:\analysisdirectory
Or copy just the rule files and specify this MsBuild argument, that's probably easiest when you put the rules files in source control:
/p:CodeAnalysisRuleDirectories=c:\analysisdirectory\rules
Optionally you could edit the project file and set the property in a property group.
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?
After adding MSBuild arguments:
/tv:14.0 /p:VisualStudioVersion=14
I get the following error message:
C:\Builds\10\IW_*****\Dev\src\Sites\******\Properties\CompileLicxFiles_Patched.targets (98): The "LC" task was not given a value for the required parameter "TargetFrameworkVersion".
I'm trying to build using VS2015 (TFS2013 server)
Found this: https://connect.microsoft.com/VisualStudio/feedback/details/1406942/new-required-lc-task-parameter-targetframeworkversion
However, I've checked and all projects in the solution have 4.5.2 version assigned.
Log (it seems it's still using VS2013):
Added package 'NEST.1.9.1' to folder ...
Added package 'FluentAssertions.4.17.0'....
...
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\10\IW_****\Dev\src\Solution123.All.sln" /nr:False /fl
To use VS 2015, the argument should be /p:VisualStudioVersion=14.0.
First thing first.
I was using VS2015 to edit TfvcTemplate.12.xaml build template which cased issues. For some reason, when using VS2015 - it was modifying the xaml document incorrectly. To make any type of changes to TfvcTemplate.12.xaml template you have to use VS2013!
TfvcTemplate.12.xaml does not contain "ToolPath" variable. To make this work I simply added "14.0" (quotes necessary) under "ToolVersion"
TFS2013 will use VS2015 MSBuild to run the build. No need for MSBuild command line switches. Works without them.
Output log:
Run MSBuild00:13:39 C:\Program Files\Microsoft Team Foundation Server
12.0\Tools\nuget.exe restore "C:\Builds\9************\packageRestore.proj" -NonInteractive MSBuild
auto-detection: using msbuild version '14.0' from 'C:\Program Files
(x86)\MSBuild\14.0\bin'.
You could also just modify your build definition with Visual Studio. On the process tab of the build definition that uses TfvcTemplate.12.xaml expand 2.5 section to see the MSBuild arguments. Add the below arguments to the build definition and save it. I assume your problem was you had /p:VisualStudioVersion=14 instead of /p:VisualStudioVersion=14.0.
/p:VisualStudioVersion=14.0 /tv:14.0
I have added a Build Step in TeamCity 8.0.6 (build 27767) to execute FxCop against a specific c# project assembly.
When running FxCop from within VS 2013 with the MinimumRecommendedRules set I get no errors or warnings (I fixed them all).
Now I want to wire this up in TeamCity. To limit the rules I am specifying a command line property as follows:
/ruleSet:=MinimumRecommendedRules.ruleset /rulesetdirectory:'FxCop\Rule Sets'
(The rulesetdirectory parameter points to a location in my source tree which contains the full contents of the standard Rule Sets folder)
However this does not have the desired behaviour, the FULL rule set is run and I get an error as follows:
FxCop warning: Keyword=CA0063 Kind=Engine Type=Microsoft.FxCop.Sdk.FxCopException * Failed to load rule set file 'MinimumRecommendedRules.ruleset' or one of its dependent rule set files.
And this is the TeamCity generated command line:
[17:32:29]Starting: "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe" /forceoutput /ignoregeneratedcode /ruleSet:=MinimumRecommendedRules.ruleset "/rulesetdirectory:'FxCop\Rule Sets'" /f:dal\bin\release\MyDAL.dll /out:C:\TeamCity\buildAgent\temp\buildTmp\fxcop-output-1891867450083417003\fxcop-result.xml
Can anyone spot what is wrong?
I figured it out so hopefully this is helpful to someone else.
the /ruleSet: parameter needed to have the full (relative or absolute) path to the ruleset file as follows:
/ruleSet:"=%teamcity.build.workingDir%\FxCop\RuleSets\MinimumRecommendedRules.ruleset"
(Note: the double quotes are to handle the possibility that the teamcity.build.workingDir might contain spaces)
Secondly, the second command line parameter /rulesetdirectory: is no longer necessary. I suspect this second parameter does not actually work.
Please also note, my working command line parameter here points at my MinimumRecommendedRules.ruleset file in my source code. It could just as easily have been copied into the standard Rule Sets folder under "c:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\Rule Sets".
And finally, as my projects are all VS 2013 and TeamCity only recognises up as far as v10 I also set "Specifiy installation root" to "c:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop" explicitly to ensure that the latest version of FxCop was being used and would not choke on .Net 4.5 code. (Note: I have VS 2013 installed on the build server because of C++ project build requirements, I'm not happy about this but it turned out to be convenient for me in dealing with the FxCop set up. There are other ways to put the FxCop stuff on your build server without installing VS 2013)