I would like to make my main branch TFS build definitions to treat warnings as errors so that the build fails when the projects are not error free. Since I do not want to activate "treat error as warning" in all project as a default, my first idea was to add a powershell script to my main build definition that substitues false with true in the line <TreatWarningsAsErrors>...</TreatWarningsAsErrors> in all csproj files it finds (something along the line of this). Is there any better/straighter way via some option as part of the build definition settings?
In the build definition specify /p:TreatWarningsAsErrors=True in the MSBuild argument field.
This will override any setting from the csproj files.
Unfortunately, there is no this kind of settings as part of the build definition.
However, you could be able to return warnings and errors from your powershell script using logging commands. With using task.logissue type=error you could fail the build task and then fail the build.
More details you could take a look at this similar question: Is it possible to raise and display build warnings from build steps using TFS 2015
Related
In Azure DevOps I have a Pipeline variable "package version" and I set it using 0.1.3$(Rev:.r)-alpha .
I use that variable to replace the "Version" in the .net core project file.
In the Build tasks the dotnet build give me this error:
so I assume the Pipeline variable cannot use a nested variable.
There is a nother way or a different syntax to do it?
[Edit]
The nested variables should work.
I think the error was the dotnet pack using Automatic package versioning set to "Use the build number" that contain the wrong $(rev:.r) (lowercase!).
Using a custom string for Version in the VS project file gives noise on VS (error if the file is open, warning otherwise) and now the Pipeline Build give me an error on dotnet nuget restore because of the invalid Version.
I decided to use a simple clean version, <Version>0.1.2</Version>, that I can choose and document.
Then I want to find a way to read it in the build pipeline and create a custom variable attaching the Build Revision:
0.1.2$(Rev:.r) => 0.1.2.123
That is the result I want.
I found this: https://marketplace.visualstudio.com/items?itemName=tmarkovski.projectversionasvariable
I'm using it with the default settings.
I'm using the variables it creates to compose a new variable, "package version":
and I use that in the nuget pack task:
but it does not work.
The resulting variable still contain "$(Rev:.r)" not parsed.
I'll try to use again the "Automatic package versioning" and create the build number in the Options...
[Edit 2]
Set the build version number in the Pipeline Build Options worked.
It's not the optimal solution because the Build Number is not parsed and looks awful.
[Solution]
$(Rev:.r) is not available outside Build / Options.
I used $(Build.BuildNumber) and I'm able to create a composed variable:
$(Version.MajorMinor).$(Build.BuildNumber)-alpha
Build.BuildNumber is valorized in Build/Options: $(Build.DefinitionVersion)$(Rev:.r)
Version.MajorMinor is created by the Project Version As Build Variable add-on.
I don't know how to obtain the same result without using a third party component.
I'm glad my extension helped and thanks for the nice review. If you want more control and have a little time to spend to play with PowerShell, you can easily achieve what you want in two steps, without using third party extensions.
Read and parse the .csproj file as XML
Set build variables
Here are couple of links on reading XML files and working with build variables, it's actually pretty easy.
https://www.business.com/articles/powershell-read-xml-files/
VSTS: Pass build/release variables into Powershell script task
[xml]$XmlDocument = Get-Content -Path $env:project_file
echo $XmlDocument.Project.PropertyGroup.Version
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts&tabs=yaml%2Cbatch
Write-Host '##vso[task.setvariable variable=package_version;issecret=true]0.1.2.'
Note: my answer wouldn't fit in a comment, I had to post an answer.
OK, so we're stuck on on-site TFS2015 at the moment. My Nuget Publisher build step is failing with:
##[error]Ambiguous option 's'. Possible values: Source SymbolSource SymbolApiKey.
It appears inside the build step they have put -s instead of -source, and in later versions they've added more commands starting with s. So what are my options?
Write my own in Powershell (Can do, but TFS Build is very clunky for this)
Find wherever this is defined in TFS (hopefully a template .ps file) and fix it there (Anyone know where this is kept?)
Upgrade to a later version of TFS (a fairly large, but perhaps inevitable undertaking)
Somehow override the -s command another way?
????????
Invoke NuGet.exe however you'd like via the Command Line task
If you did #3 (upgrade TFS), you'd find that the PowerShell build task can run an in-line PowerShell script, making it significantly less clunky.
You may be able to extract and modify the task with the tfx command line utility, but I can almost guarantee this will have nasty ramifications when you do eventually upgrade.
I'm adding my answer for details about step 5 maybe it will help team that are still using TFS 2015.
Nuget Publisher seems to use old version, which means "-s" option will not work.
To bypass this situation you can setup your build as follow:
1- Add Nuget Packager Step and specify the the Package Folder value:
2- Add a new step which would copy your artifacts(Note that contents that should be copied must end with nupkg):
3- And Finaly you can just run a command line that will perform the publish operation. In my case we are pushing the whole repository using init command(PackageRepository is the path to our internal feed that we set in we've set in Variables section):
The VSTS msbuild task seems to keep executing CoreCompile, despite the Clean option being disabled and the source files untouched (nothing changed in the source fetch).
Yet locally when I run msbuild locally or directly on the build machine, it behaves as expected - all unmodified projects are not rebuilt; CoreCompile does not run csc.exe.
I found that this was because the "TargetFrameworkMoniker" file that MSBuild generates and injects into the compile silently is written to the temporary directory, i.e. what you get when you run System.IO.Path.GetTempPath().
The VSTS agents however, specify their own temporary directory (_temp) and seem to clear it after every build. This seems like good behaviour - it's MSBuild that should fix it (IMO).
A quick and dirty fix, that may not work if your projects use mixed frameworks, is to add this MSBuild option:
/p:TargetFrameworkMonikerAssemblyAttributesPath=$(Build.Repository.LocalPath)\temp.moniker.cs
Alternatively, you can disable the file generation with:
/p:GenerateTargetFrameworkAttribute=False
I had set up fxcop Custom Dictionaries for several projects in Visual Studio. However when it comes to running FxCop as part of our build process (using NAnt), we ran into trouble.
We currently have FxCop set up to run with the command line arguments /project:ProjectPath as well as /file:OutputPath/*.dll, and it seems to be respecting those arguments.
How can I tell FxCop to respect what I've set up in my .csproj files; through either the command line, or in a .fxcop project file?
Ideally, we don't want to have to change anything any time we add a new project or a new CustomDictionary.xml file. Hopefully, it would find all the custom dictionaries by itself.
The task that executes FxCopCmd in MSBuild actually fetches the codeanalysisdictionary.xml file location from the .csproj. So if you want to execute fxcop yourself, you'd either have to run it through MSBuild or duplicate the behavior into your nant task.
Anyone know if it's possible to build a VS2003 project from the command line without showing any warnings? We've got a heap of VS2003 projects that get built by TSFBuild as part of our platform build and the warnings are just noise in the build log file.
I have looked at the parameters by running devenv.com /help and nothing there seems relevant. VS2010 has a build output verbosity setting but I couldn't find one for VS2003. I am also looking to see if it can be configured through the project file.
Seems like you're building your projects using MSBuild. If so, you can try suppress the warnings by setting the WarningLevel property as suggested here. Or you can choose the console logger to not show the warning and error summary, then output them to seperate files as provided here:
/consoleloggerparameters:parameters
NoSummary: Hides the error and warning summary displayed at the end
of a build.
/fileloggerparameters:
You can use up to ten file loggers by
following the parameter with a digit
identifying the logger. For example,
to generate separate log files for
warnings and errors, use -
/flp1:logfile=errors.txt;errorsonly
/flp2:logfile=warnings.txt;warningsonly