I'm diagnosing a problem with MsBuild not finding stock configuration files for a toolchain.
msbuild <...> /consoleloggerparameters verbosity=diagnostic traces property changes and the file:line that made the change -- so I can see there the properties go wrong.
But it doesn't trace other aspects of execution, <Import> directives in particular. So I cannot see the actual execution flow -- to understand what is included from where and why. Just searching the .props/.targets for the name of the included file is useless because they are often patterns.
Is there are way to include this information into the diagnostic output?
The MsBuild being used is the stock version included with VS2017:
>where msbuild
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe
>msbuild /version /nologo
15.7.177.53362
You can use binary logs together with the structured log viewer.
Related
How can I avoid code analysis running on TFS Builds at a solution level?
I understand I can do this at a project level, but there are over 200 projects in my C# solution and I'd like to switch off Code Analysis at solution level if its possible.
I still need to run code analysis on developers machines.
I want to save time by not running code analysis on a specific TFS Build (we use SonarQube for CodeAnalysis on a separate build pipeline and so we don't need TFS Build to do it's own Code Analysis)
I have tried the following in my MSBuild arguments :
/p:RunCodeAnalysis=false
/p:RunCodeAnalysis=Never
(This is using the default TfcvTemplate.12.xaml)
But even with these changes I can still see from the build logs that Code Analysis is still occuring:
csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /errorreport:prompt /warn:4 /define:TRACE /highentropyva+
/debug:pdbonly /optimize+ /out:obj\Release\xyx.dll
/ruleset:"..\Rule Sets\MinimumRecommendedRules.ruleset"
/subsystemversion:6.00 /target:library /utf8output
xyz.cs
The full MSBuild arguments I use are:
/m /tv:14.0 /p:RunCodeAnalysis=false /p:GenerateProjectSpecificOutputFolder=True
I'm using Tools Version 14 coupled with Microsoft.Compilers NuGet package to allow C#6 on our TFS 2013 Build Server.
Is there a way to avoid running code analysis at solution level, using just the MSBuild args in a TFS2013 build definition?
The RunCodeAnalysis property is used by the old style FxCop static binary analyzers. The new Roslyn Analyzers do not follow this setting.
There are two options...
You can create a Directory.Build.targets1 file in the root folder of your solution (you can create it during build if needed) and remove the analyzers just before the compiler is invoked:
<Target Name="DisableAnalyzersForBuild"
BeforeTargets="CoreCompile"
Condition="'$(TF_BUILD)'=='True'">
<ItemGroup>
<Analyzer Remove="#(Analyzer)"/>
</ItemGroup>
</Target>
You can include the TF_BUILD check to detect that you're inside a Team Build run.
You can also create a ruleset file that disables all rules and override that as part of the build:
/p:CodeAnalysisRuleSet=AllDisabled.ruleset
1) Not sure if this works with the Nuget compiler extensions.
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)
I'm attempting to do a command line package deploy for our Windows Store Application.
My command line instructions are:
msbuild /m /p:Configuration=Debug /p:Platform=x86 /target:Build
I'm using VS2013 Professional with Windows 8.1
I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Task 'GenerateAppxPackageRecipe' failed. Value cannot
be null.\r [C:\Path\Project.csproj]
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Parameter name: source\r [C:\Path\Project.csproj]
How should I resolve this?
This error was resolved by using the correct version of msbuild.exe
On a clean build server with VS2013 installed, there are (at least) two copies of msbuild.exe installed. In our case the install locations were:
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe
and
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
The one in the .Net Framework folder was the one that gave us the errors. Using the version installed in the Program Files folder resolved the issue.
It's impossible to help you without having the code which can reproduce the error. I suspect some property does not resolve correctly when building outside VS(eg VisualStudioVersion) and needs to be passed from command line. VS also uses msbuild to build your projects, so comparing build logs from VS and CMD should help you track down the problem.
I suggest, that you set visual studio's build output verbosity to diagnostic, clean solution, than build and capture the build log.
Then clean solution and build from command line with verbosity set to diagnostic and /fl switch(log to file, because diagnostic build log is way too long to analyse in console window).
Compare command-line output to VS output. Look for the differences. With diagnostic level of verbosity, chances are, you'll find out what's missing (I had similar issues with database projects failing to build from cmd due to VisualStudioVersion variable not being resolved correctly, so I passed it from command line).
NB: diagnostic log is very verbose which makes analysis hard: I'd start from detailed verbosity level.
I have deleted all files/folders from "project"/bin folder, cleaned the solution and rebuild with success !
For those facing the issue on hybrid app (corodova in my case), delete the build folder manually and re-build from VS.
Standard clean solution didn't do the job.
When I build my solution from the command line using msbuild, I don't get any output from the csharp compiler (Csc) like visual studio does.
For example, if I build my solution in Visual studio I get:
warning CS0162: Unreachable code detected
When I build from command line using msbuild, I get no warning at all (I want the warning to appear!)
Edit: the /verbosity flag does not do the trick
Are you sure you are building the same configuration? Typically Visual Studio will build your Debug configuration by default. MsBuild on the other hand will default to build your Release configuration. Make sure that you have the warning levels set to the same level for both configurations in your project settings.
I think you might need to provide an argument for output verbosity...
From MSDN reference:
Displays this amount of information in the build log. Individual loggers display events based upon the verbosity level. A logger can also be configured to ignore the verbosity setting.
The available verbosity levels are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. /v is also acceptable. For example:
/verbosity:quiet
I have had my first successful build using CC.Net + MSBuild on legacy project. Only took 8 hours.
My newb question is: Where is the output?
My ArtifactDirectory is empty. Where did everything go?
Did you specify the ThoughtWorks.CruiseControl.MSBuild.dll logger in the msbuild-task? Did you have the xmllogger publisher?
EDIT:
What are you looking for : the results/logs that goes into the dashboard and mail or the website/dll/program you built?
Could you post your project configuration?
EDIT2:
The website/dll you built are located in the outDir you specified in your msbuild task. If you didn't override either the OutDir or the OutputPath property (in your msbuild task or msbuild build script) your website should be located in the WebProject\bin\Release (or Debug)_PublishedWebsites and your dlls should be located in every Project_dir\bin\Release (or Debug).
If you want a common output you need to specify it by overriding OutputPath or BaseOutputPath (see here http://msdn.microsoft.com/en-us/library/bb629394.aspx ).
If your source projects don't compile to custom folders, the code will be located wherever the source was pulled down to on the build box. As Benjamin stated, this will be the workingDirectory specified in the msbuild task.
If you didn't specify a working directory, I believe CruiseControl.net puts code in:
C:\Program Files\CruiseControl.NET\server\[Project Name]\WorkingDirectory