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)
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
I have the following warning when building some of my class library csprojs:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3101: Could not write state file "..\..\tmp\dotnet\anvil.controls\obj\vs2017\net461\debug
\anvil.controls.vs2017.net461.csprojAssemblyReference.cache". The file 'E:\anvil\Anvil.Controls\tmp\dotnet\anvil.controls\obj\vs2017\net461\debug\Anvil.Controls.vs2017.net461.csprojAssemblyReference.cache' already exists. [E:\anvil\Anvil.Controls\src\anvil.controls\anvil.controls.vs2017.net461.csproj]
I've tried using msbuild 15.0 (VS2017 and Standalone 2.2.103) and 16.0.
Same warning in Visual Studio 2017 and JetBrains.Rider
Does not happen if I wipe my temp folder. Then happens in subsequent builds or even rebuilds.
Happens to a subset of my projects, only similarity I can see is that they are all projects that contain .xaml files. But it doesn't happen on all projects with .xaml files.
Happens when I use -maxcpucount:1 (to disable parallel build).
Each project has a unique tmp/intermediate folder, set to this: ..\..\tmp\dotnet\ubisoft.controls\<bin|obj>\vs2017\net45\<debug|release>\
Any ideas what might affect this error in my projects?
Sometimes 'mysterious warnings' (and errors) come from too long paths. Try to use a shorter output path, i.e.
E:\build\Anvil.Controls\tmp\net461\debug\
instead of
E:\anvil\Anvil.Controls\tmp\dotnet\anvil.controls\obj\vs2017\net461\debug\
See this answer as well
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 am trying to build a program for x64, but I keep getting the following error messages:
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2554,5): error MSB4216: Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR4" and architecture "x64". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe" exists and can be run.
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2575,7): error MSB4028: The "GenerateResource" task's outputs could not be retrieved from the "FilesWritten" parameter. Object does not match target type.
MSBuild.exe exists and can be run, so I don't know why I am getting these errors.
I am using Visual Basic in Visual Studio Professional 2013 (Update 4). I am not using any DLLs, all I am creating is a standalone .exe file.
I've tried searching, both here and on Google, but cannot find anything helpful. Then again, I have a tendency to overlook things, so the answer has probably been screaming in my face for the last hour. I apologise in advance if this turns out to be the case.
Any and all help is very much appreciated.
replace
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe
by
C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
and try.it should do some difference.this occurs because the version on msBuild.exe has changed after update4 of vs2013.check for version differences..
also i suspect you are trying to build the solution in x86 architecture.if first solution doesnt work,go to the Build tab, change the Platform target from Any CPU" to "x86" and try. hope it helps.
I just encountered this exact same error in a multiple project VB solution when trying to start a debug instance of one project. By forcing a rebuild of that one project I was able to fix the issue and start the debug instance.
I solved this problem by opening the project in Visual Studio 2017, instead of 2015
Am trying to configure the static code analysis(FxCop) in my Continuous integration system.But my developers are using a rule set file for static analysis with Visual Studio.
Is there a way that i can re-use the same rule-set file and convert it into a FxCop rule-set dll and perform the static code analysis while build?
Thanks in advance,
Ravi
If you have Visual Studio installed on the CI server, then simply specifying /p:RunCodeAnalysis=[True|False|Always|Default|Never] on the MsBuild command line should run Code Analysis as it was configured on the developer's configuration. The rules files are automatically included in the Visual Studio project file, so they should resolve on their own.
To run FxCop after the build you can specify the ruleset as a commandline parameter:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop>fxcopcmd /?
Microsoft (R) FxCop Command-Line Tool, Version 12.0 (12.0.21005.1) X86
Copyright (C) Microsoft Corporation, All Rights Reserved.
/ruleset:<<+|-|=>file> [Short form: /rs:<<+|-|=>file>]
Rule set to be used for the analysis. It can be a file path to the rule set
file or the file name of a built-in rule set. '+' enables all rules in the
rule set; '-' disables all rules in the rule set; '=' sets rules to match the
rule set and disables all rules that are not enabled in the rule set.
/rulesetdirectory:<directory> [Short form: /rsd:<directory>]
Directory to search for rule set files that are specified by the /ruleset
switch or are included by one of the specified rule sets.
The difficult part of running FxCop from the commandline is that you will want to pass all references and that it can only process files targeting the same .NET system libraries (it can only hold one of those in memory). You can specify these references using the following parameters:
/platform:<directory> [Short form: /plat:<directory>]
Location of platform assemblies.
/directory:<directory> [Short form: /d:<directory>]
Location to search for assembly dependencies.
/reference:<file> [Short form: /ref:<file>]
Reference assemblies required for analysis.
If you want to run code analysis only without having to call fxcop directly and specify all that extra information, do the following:
<MSBuild Projects="#(CodeAnalysisProjects)" Properties="RunCodeAnalysis=True;Configuration=Release;BuildProjectReferences=False;WarningsAsErrors=False;RunCodeAnalysisDependsOn=;" Targets="RunCodeAnalysis" StopOnFirstFailure="false" />
You send in the list of projects in the itemgroup CodeAnalysisProjects. You run the target RunCodeAnalysis and you set the property RunCodeAnalysis=True. You also set the property RunCodeAnalysisDependsOn=; so that nothing else runs besides code analysis.
This is the same solution we use for our CI. We build all day and then run code analysis only at night.