I've been trying to get the MsBuild integration between TFS2013.4 and sonarqube working as it would make my build a lot more efficient. I do this following the procedure that has been announced here.
This has been working nicely up until the point where the FxCop analysis starts. For some reason, sonarqube searches the CodeAnalysisLog.xml file in a directory <TfsBuildBaseDir>\BuildName\Sources\Solution\Project\bin\release\ instead of the directory <TfsBuildBaseDir>\BuildName\Binaries\. (image added below) To me this behavior is strange as it seems to me that the process tries to locate the CodeAnalysisLog.xml on a location that is normally used on a local computer instead of a buildserver. This means that the build fails on the point where the postbuild actions are being executed, which renders the complete analysis operation useless. Has anyone seen this before?
Related
I have a solution that is using an hybrid .csproj and project.json combination (for nuget management purposes). So basically the "project.json" file is working as a "packages.config" file with a floating version capability.
This solution is using a custom RuleSet that is being distributed via Package, and is imported automatically. On the dev machine, works without a problem.
At the build machine (that is, inside the machine itself, working as an user) the solution also compiles without a problem.
However, when a vNext build (is this the name for the new build system?) is queued, it ignores completely the custom ruleset and just uses the StyleCop one (that is also included), which gives a bunch of warnings. Said warnings should not appear as the Custom RuleSet basically suppresses those warnings (ie: Warning SA1404: Code analysis suppression must have justification,
Warning SA1124: Do not use regions, etc)
As far as I have checked, there is no setting to specify the ruleset, and this works with XAML Builds. What is different in this new build system that is causing this? Is there a way to force/specify the Code Analysis Rule Set from the definition?
Thanks in advance for any help or advice on the matter.
Update/Edit
After debugging back and forth with the wonderful help of jessehouwing I must include the following detail on my initial report (that I ignored as I did not know that it was influential):
I am using SonarQube Analysis on my build definition.
I initially did not mention it as I did not know that it replaces the Code Analysis at Build Time (and not only when it "analyzes", as I thought).
If you are using the SonarQube tasks
The SonarQube tasks generate a new Code Analysis Ruleset file on the fly and will overwrite the one configured for the projects. These rulesets will be used regardless of what you've previously specified.
There is a trick to the naming of the rulesets through which you can include your own overrides.
More information on the structure can be found in the blog post from the SonarQube/Visual Studio team. Basically when you Bind your solution to SonarQube it will generate 2 ruleset files. One which will be overwritten during build, the other containing your customizations.
There is a toolkit/SDK to generate a SonarQube plugin for custom analyzers which allow you to import your rules into SonarQube, so it will know what rules to activate for your project(s).
If you're not using SonarQube
Yes you can specify the ruleset you want to use and force Code Analysis to run. It requires a couple of MsBuild arguments:
/p:RunCodeAnalysis=true /p:CodeAnalysisRuleset="PathToRuleset"
Or you can use my MsBuild helper extension to configure these settings with the help of a UI template:
We have an MSBuild task that builds our *.sqlproj file, the output of which is loaded back into TeamCity as an artifact for subsequent deployment.
Similar to this user, we are having some unpredictable output file naming happen:
Invalid file names when trying to deploy SSDT project with TeamCity 8
It appears that sometimes, it produces this output file under /bin/Release:
MyProj.sqlproj.dacpac
Then subsequent builds produce this file in the same folder:
MyProj.dacpac
We haven't done indepth testing yet - I was wondering if anyone else has seen similar or has a suggested troubleshooting path?
To be clear, it's the same task, running the same command against the same project - just run repeatedly overtime as new checkins happen.
Sounds like you have conflicting .sqlproj files being checked in.
I'd start by checking the history.
Well, after looking more closely at the build log I could see that the TeamCity MSBuild runner appears to be creating some temporary virtual project files (or something, I don't know for sure because they get deleted) with names like:
MyProj.sqlproj.teamcity
I theorized that this may be confusing MSBuild or one of the targets related to building dacpacs, so I replaced the TeamCity MSBuild build step with a Command Line build step that calls MSBuild on the original project file itself, and this appeared to solve the problem. It now produces the dacpac with the file I'm expecting.
I don't have time to dig further now, but I could believe that there's some logic in the chain somewhere that is deriving the name for the final *.dacpac from the name of the project file being used. My guess is that it just strips off everything after the last "." and attaches the ".dacpac" suffix.
I don't fully know why it would occasionally create a *.dacpac file with the correct name, but I was at times doing a manual build in the TeamCity agent work folder from the commandline on the build server itself, so this may have just been a file leftover from previous executions.
We are using Code Analysis on our projects. As part of this we have Code Analysis enabled on the build server allowing for continious checks.
Now we are receiving this error:
CA0063 : * Failed to load rule set file '[name].ruleset' or one of its
dependent rule set files.
[name] being a ruleset on our internal network, available for everyone.
Code Analysis runs perfectly fine on each local machine, but not on the build server. How can we fix this issue?
Notes:
We use a custom made ruleset
We are not using any custom rules (yet)
I was having this issue as well. How I solved it was to add my custom ruleset into version control (Git) as a new directory within my project files. We are using Jenkins for our CI, so in my Jenkins.build I then made sure to specify the absolute file path to my ruleset on the Jenkins server, which you can get by looking at your Workspace on Jenkins. For example the path may look like :
e:\Jenkins\workspace\SampleProj-Dev\Rulesets\CustomRules.ruleset
In Jenkins.build file, I added an argument to the msbuild.exe program execution with:
<arg line="/p:RunCodeAnalysis=true;CodeAnalysisRuleSet=e:\Jenkins\workspace\SampleProject-Dev\Rulesets\CustomRules.ruleset"/>
Before I had tried using a relative path but with a build containing many sub-projects, Jenkins tried to append the path onto a changing path. This path was based on the currently building sub-project, resulting in the same error you received.
I stumbled onto a fix for this tonight for a project that has been suffering from it for ages. I created a new configuration CHECKED and the problem disappeared. Then by:
Deleting the existing configurations from Configuration Manger;
Exiting and saving (this step might not be necessary); and finally
Recreating the dropped configurations from the newly created one, CHECKED
the problem has now disappeared completely in all configurations.
This was all in Visual Studio 2013.
I've recently moved to TFS213, did an install on a new machine.
After building one of my projects the result showed an error on MsTest. It turned out that it had invalid switches (as in Error when running unit tests from MSBuild)
Invalid switch "/publish".
Invalid switch "/publishbuild".
Invalid switch "/teamproject".
Invalid switch "/platform".
Invalid switch "/flavor".
I have found various posts online about this and have done the following :
I have installed vs2013 professional on the build-machine, in various posts it's says to install ultimate but I don't have a license for ultimate.
The problem still persists, the MsTest.exe is started from the correct location (it's only installed in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE, and the build-process does find the MsTest executable.
for now I've disabled testing in my build-definition but that's not the 'ideal' situation ;-).
Should I just remove the invalid 'switches' or is there some other solution
TIA,
Jurjen.
I had the same issue and solved it by modifying the properties of the "Run MSTest for Test Assemblies" step in the build.
Summary of fix: I changed the Flavor, Platform and Publish properties of the "Run MSTest for Test Assemblies" step to "" (empty string).
Details of fix: I did this in a custom template but I think you could also make the change in the default template.
Disabled tests (as you did) to make sure my build would work as a baseline.
Followed instructions here to create and use to a custom template:
http://msdn.microsoft.com/en-us/library/dd647551.aspx
Tested that the Custom Template worked by adding a "Write Build Message" step to the build (per advice in article above).
Searched for (drilled down) to the "Run MSTest for Test Assemblies" step in the build. This took a long time because it is deep. I am sure there is a faster way to find it but I am not sure how.
Set Flavor, Platform and Publish properties to "" (empty string). (See photo).
Committed template changes to TFS.
Re-ran the build and it worked.
When all tests pass I don't see test results on the build results screen.
When a test fails it causes the build to fail. I don't see the test failure in the build summary but it does show up when I click "View Log".
This isn't ideal, but at least I have the tests running and preventing a build from passing when a test fails.
I build my solution but CC tools are not installed on build server.
So no rewrite was done.
Now I'm curios why msbuild reports build as successfull if not all tasks were finished?
P.S. I'm completely unexperienced in msbuild so if my question sounds stupid I beg you pardon, guys.
Update
Well, I installed locally Code Contracts extension which created additional tab for project options.Then I enabled code contracts checking at run time and added at the very begining of the Main method the following line:
// test for Code Contracts rewrite
// exception is thrown if no rewrite
Contract.Requires<Exception>(true);
I commited changes to TFS and started the build and it completed succesfully without any warnings. No rewrite was done and my application throws exception.
I've read about Microsoft.CodeContracts.targets file ad found it in CC installation dir but I see no refernces to it inside project file. Only elements like <CodeContractsAssemblyMode>1</CodeContractsAssemblyMode>.
I don't understand where msbuild gets the knowledge about CC and how to apply them.
Update 2
Eventually we installed Code Contracts on Build Server and assembly instrumentation is performed.
Yet it's still not clear what settings are changed during CC installation.
You need to install the tools on the build server as well. The design of the contract tools are such that unless you use Contract.Requires< Exception >(...) one can build and release bits without the use of our tools. If you use Contract.Requires< Exception >(...) however, then you must use the rewriter as the documentation states. Thus, in order for your project to be successfully built, you need to install the tools.
MsBuild and VS and C# know nothing of the contract tools and thus cannot warn you about this lack of tool installation.
Hope this helps.