We want to refuse checkins which break our custom defined static code rules. Therefore we have defined a Gated Checkin build, with "Perform Code Analysis" set to 'AsConfigured'.
When I build the solution locally, using the same configuration and target as defined for the Gated Check in build, there are no errors. But the Gated Checkin build seems to ignore any [SuppressMessage] attributes that we have defined in source, thus reporting errors.
The Gated checkin build does not ignore [SuppressMessage] attributes that are defined in a GlobalSuppressions file.
Any one else have this problem?
When you said you build locally fine, did you build from Visual Studio, or did you build with MSBuild?
TFS Build uses MSBuild to build the projects, and you should be able to see what MSBuild command is run during the build by looking the log from the build report (if you set the verbosity level at least to Normal).
To investigate this issue, I would recommend you use this MSBuild command to build your solution locally (you would need to change the path to the solution on your machine, rather than the path used on the build machine), and it will likely give you the same errors, which indicates a discrepancy between building with MSBuild and building with Visual Studio. Then we can look at the MSBuild command and see why it does not behave the same way.
Hope this helps.
Related
In VSTS (hosted TFS) I have a build definition which uses MSBuild. What I would really like is to have pull requests annotated with any rule violation detections. However I can't get the analysers to work at all. What I've done so far;
Installed Microsoft.CodeAnalysis.FxCopAnalyzers in one of the projects that gets build
Verified that running "Analyze Code" in Visual Studio does output rule violations
All the *.ruleset files are not available on the self-hosted build agent, as it only has MSBuild installed (no full-fledged Visual Studio). For the same project as in point 1, I've also used a custom ruleset.
I have also build the project on a hosted build agent (which has VS2017 installed), but also to no avail.
With all of the above, the build log / build overview in VSTS doesn't list any rule violations. It's my understanding that the code analysis should be run automatically and the output should appear on the build overview page (i.e. https://MYSITE.visualstudio.com/MYPROJECT/_build/index?buildId=XXX&_a=summary&tab=details).
The Code Analysis setting is based on the configuration and platform, so you need to make sure you build the project with the same configuration and platform that enabled code analysis on build.
You also could specify it in MSBuild Arguments of MSBuild task:
/p:RunCodeAnalysis=true;CodeAnalysisRuleSet=..\RuleSets\MyMixedRecommendedRules.ruleset
I have a TFS build that runs on a schedule. Within the build process I have a step that checks out that project's properties file, increments the assembly's version number, then checks in the file bypassing any gated check-ins. This is creating a problem as the check-in of the properties file automatically sets the scheduled build to run the next day, causing an infinite loop.
My question is, is there a way to associate changesets made within the build process to the current running build?
I've tried refreshing the build detail and re-associating changesets after the msbuild compiles the project, but before the build finishes, without success.
Our projects are for Visual Studio 2010 and we are running against TFS 2013.
EDIT 12/21/15: For clarification:
I know about the NO_CI for bypassing CI Builds and including the /bypass in the command line. Overall my check-in that I am doing looks like the following:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe" Checkin %My_FILE% /comment:"***NO_CI*** Version Updated to %NewVersion%" /noprompt /bypass
I"m having trouble with scheduled builds kicking off, because my check-in is telling it that there is a changeset to build.
You need to check in without triggering the build.
To tell the build system to ignore the check-in operation, a check-in comment value***NO_CI*** is specified to indicate "No Continuous Integration" meaning "please don't start a CI build because of this check in". Place the following into the comment field:***NO_CI***and when you check-in TFS will not kick off a build. More details for your reference: http://bartwullems.blogspot.hk/2012/08/tfs-do-check-in-without-triggering.html
update
You could customize your build template and add in the custom TFSVersion activity from the TFS Community Build Extensions that will handle this. Detailed steps for your reference:http://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation
I have a c# solution with multiple projects. I have a .sln file I build the solution with in VS2012.
I am looking to set up TFS Build and want to include some custom msbuild actions, such as running stylecop and fxcop rules. I want these tasks to fire when building the solution locally and within tfs build.
I have looked at creating a .proj file for the solution. However, I am not sure how this can be setup locally and to run the tasks locally.
What is the correct setup for tasks to be run within tfs build and visual studio?
My best guess is to set the flag "Enable Code Analysis on Build" in the project settings "Code Analysis". More on that here.
I suppose that running StyleCop is better fitted in the IDE (check R#) or the VCS (check SVNStyleCop) on commit. I am not sure if the same exists for GIT or other repositories.
In the project I've inherited, the original developer used a number of post-build events in his Visual Studio projects to copy around DLL's and stuff when building inside VS.
This is causing some grief now that I'm trying to move these things to the TFS 2010 Build system.
I was hoping to be able to create a new "Continuous" project configuration, and exclude those post-build events from Visual Studio in that configuration - but it seems those calls aren't configurable based on your project configuration....
Any ideas? Is there something I could check for to know I'm running under TFS Build and then just skip those CMD files? Any ideas would be most welcome!
My approach is to guard the pre- or post-build code with this
IF "$(BuildingInsideVisualStudio)"=="true" (
…your code here…
)
That variable is automatically defined by Visual Studio and you do not need to change the build definition.
I use a similar approach to do this. I add the following to each project's post-build steps:
if '$(TeamBuild)'=='True' exit 0
Then when configuring the Build Definition I simply add:
/p:TeamBuild=True
...to the MSBuild Arguments.
This gives me the flexibility to keep all the configuration in the projects and the build definition.
What if you set an environment variable on your team build server, and then you could write a check into your post build steps to check for that environment variable. If the environment variable is set, you'd know to skip the command files that do the post build steps because you'd know you are running under TFS build.
You could combine all your post build steps into one script possibly, and then just check the environment variable at the beginning of that script.
Or you may be able to do it the opposite way and build the check into your TFS build script. You can refer here for how to check an environment variable in a TFS build.
So in your TFS build script you'd have something like:
<RunScripts Condition=" '$(RunScriptsServerVar)' != '' ">
the environment var is NOT set, so run your scripts since we aren't in
a TFS build
</RunScripts>
Allow me to start by saying that this is a new and first time TFS deployment with 0 experience in Visual Studio as an added bonus. I've managed to get everything installed and am excited to say that I can even deploy as part of the build process to our different staging environments, but this is where things have gone south.
I'm trying to set up separate build definitions for each stage of development so that I can take advantage of config transforms and use granular permissions for who gets to promote where. In the configuration manager I have it set up so each solution configuration has a 1-1 mapping to a project context and always building 'Any CPU'. The problem is that when I use the /p:Configuration=QA switch in the MSBuild Arguments or just specify it in the 'Items to Build; section of the Build process parameters the build fails with a warning and it doesn't seem to get as far as MSDeploy.
Using the following arguments to MSBuild I am deploying with a default configuration, but again, no love on specifying a configuration.
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=WMSVC /p:MsDeployServiceUrl=10.31.60.109 /p:username=tfsdeploy /p:password=lulz /p:DeployIISAppPath=Bob /p:AllowUntrustedCertificate=True
Here is the warning I get in the TFS Build Explorer when specifying the configuration to use.
C:\Builds\2\Bob\Bob - Final Test\Sources\Bob\Bob.sln.metaproj: The specified solution configuration "QA|Any CPU" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration.
The solution originally was created in VS2008 and a local copy from VSS was pulled down with VS2008 and then pushed into TFS2010 using VS2010 pretty much letting MS work its magic to convert/update.
Any help is greatly appreciated.
The issue I ran into here was that the names of the build configurations were different in the .sln and .csproj files and these can't be mapped to each other as I thought I was doing from within the VS2010 ide.
This is actually a pretty simple error. If you get it, check your spelling in the build definition then verify against the .sln and .csproj files using a text editor like vim/notepad.
Did you get this fixed? I've noticed some of our builds are "AnyCPU" and others are "Any CPU", makes reports a little more interesting!