Scenario:
I am migrating our current VS Solution analysis setup from using the sonar-runner to using the MSBuild runner. However I am encountering a fairly significant problem.
In the old setup, we specified our project name, key and most importantly a long list of skipped projects (sonar.visualstudio.skippedProjectPattern) using the sonar-project.properties file.
This is because [WARNING: ugly legacy bad coding practice alert] we have six solutions that build dozens and dozens of projects, all out of the same git repo. A lot of the projects are common across several solutions and we don't want them analyzed more than once. So each solution has a set of projects that it "owns" and which are analyzed as part of it. Thus the sonar-project.properies file for each of the other solutions specifies that these projects are to be ignored.
The Problem: In the new MSBuild Runner approach, there does not appear to be MS solution level (also read as SonarQube Project level) configuration file or mechanism aside from passing arguments on the command line to the MSBuild runner's 'begin' phase. One either has the global configuration file, or the MSBuild *.*proj files, (that is, MS project level configuration files). This latter is clearly out of the question as whether a project gets excluded from analysis is based on which solution is being analyzed.
As noted, conceivably we could pass all this in on the command line but that is sub optimal. Our builds are done by scripts that are, to the extent possible, generic. Having the configuration in the sonar-project.properities file was a big help in keeping them that way and we are hoping we are missing something here that will let us keep using that file or a similar one. Are we?
There currently is no equivalent to the sonar-project.properties file in the MSBuild SonarQube Runner version 1.0. I've added a new ticket to the project's backlog to consider adding this feature in an upcoming release: http://jira.sonarsource.com/browse/SONARMSBRU-124
The v1.0 MSBuild SonarQube Runner supports a /s: command line argument that allows you to specify the global settings file to use. The settings file can contain any additional global settings that previous you would have put in the sonar-project.properties file.
If you don't specify a global setting file the MSBuild Runner will look for a default global settings file in the same location as the runner executable.
See the documentation repo for more information: https://github.com/SonarSource/sonar-.net-documentation/blob/master/doc/appendix-2.md
The properties now can be added via ItemGroups in each .csproj file, this way:
<ItemGroup>
<SonarQubeSetting Include="sonar.cpd.exclusions">
<Value>Models/**/*.cs</Value>
</SonarQubeSetting>
</ItemGroup>
Related
I have a large VStudio solution whose .csproj files I'm porting over to the new .NET SDK format. I have integrated the github project with AppVeyor. When I work on the solution, my project is built by VStudio; AppVeyor uses msbuild to build my project.
All of the class library project files in the solution have been modified so that they specify <TargetFrameworks>netStandard2.0</TargetFrameworks>. For simplicity, let's represent the class library project files with classlib.csproj.
The solution also contains a few command-line tools, which need to be built in advance of some of the other projects, because those later projects need to run the command-line tools as a preprocessor before building themselves. These command-line projects are all specifying <TargetFrameworks>net472;netcoreapp2.0</TargetFrameworks>. Let's represent the tool project files with tool.csproj.
In order to build correctly, tool.csproj needs to be built before classlib.csproj. In the solution I've used the Build dependencies > Project dependencies command in the VStudio solution explorer to indicate this. This works fine when I'm working inside of VStudio.
However, when I push my changes to github, AppVeyor kicks off an msbuild process to build the projects. From the error spew, it's clear that the tool.csproj didn't get built in time. It seems msbuild doesn't understand the project dependency information in the .sln file.
Reading what's posted on the intertubes (e.g. https://devblogs.microsoft.com/visualstudio/incorrect-solution-build-ordering-when-using-msbuild-exe/), I attempted to add the following to classlib.csproj:
<ProjectReference Include="..\tool\tool.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
But when I do this I get the error:
Project '..\tool\tool.csproj' targets 'net472;netcoreapp2.0'. It cannot be referenced by a project that targets '.NETStandard,Version=v2.0'
which clearly makes sense.
Some other solutions I've read suggest editing the .sln file so that tool.csproj gets built first, and hope that building will be completed before classlib.csproj starts building. However, this is a race condition since msbuild is not aware of the dependency.
How, then, do I express that classlib.csproj depends on tool.csproj so that msbuild understands it?
EDIT
It turns out the issue was caused by an interaction between the target I'd written to start my tool and the globbing operation MSBuild does to resolve the <Compile> item collection using a pattern similar to **\*.cs. The tool generated the file after the globbing operation. Since the generated file isn't present when the globbing happens, it is missing from the <Compile> item collection, and the build failed. I mistakenly interpreted the error "foo.cs not found" as a failure to execute the tool, when in fact, it's a timing issue.
To make the build order works outside VS IDE, we need to use add reference
instead of BuildDependencies=>ProjectDependencies.
Right-click classlib project and choose add=>reference, in Project node choose the Tool Project you want like this:
Click ok to add it and save changes. After that, open the classlib.csproj you can find sentence like:
<ItemGroup>
<ProjectReference Include="..\xxx\Tools.csproj">
<Project>{6eaa430f-9793-4639-a84b-6ab767d57147}</Project>
<Name>Tools.csproj</Name>
</ProjectReference>
</ItemGroup>
This what the msbuild can understand. And I think that's what you want.
After that,you can use a single msbuild tool or Appveyor to check the
build order.
And in Appveyor, we can also disable the paralell builds(settings=>build=>msbuild options) to make sure it won't build classlib.csproj until the tools.csproj build ends.
The final build order in Appveyor will be what we defined in VS. Hope it helps.
I'm testing SonarQube with a .Net solution file. I'm trying to figure out which files exactly get uploaded/imported into the SonarQube database. Based on my tests with the SonarQube MSBuild runner, it analysis and uploads all files which are stated in the .csproj project file(s) (only those that can be associated with a language plugin because I have set "Import unknown files" to false).
Is there a way to specify additional files which should be analyzed and imported? I had some hope for the "sonar.inclusions" setting, but it's not exactly what I need because the description says Patterns used to include some source files and only these ones in analysis.
I'd like to just specify additional files.
My use-case: at the moment, SonarQube does not create issues for compiler warnings (see Displaying C# compilation warnings in Sonar?) (which in my opinion is really sad/weird for a tool that wants to improve code quality). So my idea is to use msbuild with an xml-logger, import the generated xml log file and use the XML plugin with custom XML path rules to extract the compiler messages.
Similar issue for analyzing Delphi code. I found an old SonarQube Delphi plugin which I could not yet get to work with SonarQube 5.x, but I'd like to try to get at least the compiler messages into SonarQube (convert Delphi compiler output into XML, get SonarQube to import this file, use custom XML path rules).
Is there a way to get SonarQube to analyze/import such additional files?
I'm just looking at streamlining the nuget packages that are coming out of my build system and I'm stuck on how to only package the files that are required.
I have several configurations sharing a Root VCS checkout. I have a configuration that runs a debug build with unit tests. I also have a release configuration that does a release build, this configuration then also uses the TeamCity OctoPack plugin to create the nuget packages.
What I want to achieve is the building of nuget packages that don't contain the *.pdb and *.xml documentation files as these aren't required for the release deployment.
I've looked through this page on the OD site:
http://docs.octopusdeploy.com/display/OD/Using+OctoPack
And according to this page OctoPack should only package up the required files by default. I'm not entirely clear on how or what needs to be done to get around this problem as it doesn't appear to be working as described.
It seems that one solution would be to provide a nuspec file for the projects I'm looking to deply but I'm also wondering if there is something I'm missing before I head off down that route.
I also have some MEF plugins that are copied in post build events and these aren't included in the nuget packages when in fact they are needed for the application to run. I think I need to get explicit with a nuspec file but would like to confirm this.
What is the simplest way of achieving what I need?
Assuming you're running the later versions of OctoPack, in your release build you can set a system parameter system.DebugType = None which will get passed to the OctoPack build scripts and prevent the PDB's being created.
This simply overrides the setting defined in your csproj msbuild file (assuming C#), so you can use it wherever you want to prevent PDB's being created at the build configuration level (not just OctoPack). I generally prefer this approach as it prevents side-effects in your build from changes by developers in the project file.
As for the xml files, I haven't actually tried this, but you can try a similar approach and create a system parameter system.DocumentationFile = "" to blank out the output.
If you really want to make sure that the files have been removed there are a couple of ways you can do this. Modify your deployment process to:
Execute your own custom PowerShell script in that removes the files
Include a script module from the Octopus Library to the same. Check out the File System - Clean Directory from the Octopus Library
We are using TFS 2010. In our projects we have multiple configuration files. Each configuration file is needed for a specific build.
Example: Project XYZ includes three configuration files, lets say DEV-CONFING, QA-CONFIG and PROD-CONFIG files.
Now we want to find a way that during the build process, the build process includes the right configuration file and excludes the rest.
Example:
Build for Dev should pickup and copy only the DEV-CONFIG file (and excludes all other configuration files)
Build for QA should pickup and copy only the QA-CONFIG file (and excludes all other configuration files)
Build for production should pickup and copy only the PROD-CONFIG file (and excludes all other configuration files)
Is it possible to change the setting of individual build definition and address this issue?
What is best possible solution for this problem in VS 2010 and TFS 2010?
Please list all required steps and be precise as much as possible because I'm a newbie in TFS 2010 and have not much experience with the whole process.
The "Web Config Transformations in VS2010" addresses the problem of modifying the web.config during compile time. Some people might want the web.config to be modified at deployment time instead of compile time (like me) so that we dont have to recompile the code while moving from one environment to another, in that case you can make use of "Web Deployment Parameters"
You can read more about it at:
http://www.asp.net/mvc/tutorials/deployment/visual-studio-web-deployment/web-config-transformations
web config transformation syntax:
http://msdn.microsoft.com/en-us/library/dd465326.aspx
#user2585405 to your comment above "But all the configurations in my case are for the same mode "Release Mode". The decision should relay on the build definition. So when I use a build definition for DEV, the configuration for DEV should be automatically chosen or for QA build definition, the corresponding QA configuration should be automatically chosen."
Doesnt matter whether currently you have only one configuration. You can add how much ever configurations you want, right click the solution and select the configuration manager. Now add a new configuration say "Dev" (it can be in "Release/Debug" and also select the platform "x86, any cpu etc"). Now add another configuration for QA and PROD. Then come back to your web.config and right click and select "Add web config transformation".
Now you should be able to see the web.Dev.Config, web.QA.config etc. The root web.config will have all the common properties and the DEV/QA/Prod specific config will have only the delta changes (you have to define these entries) which are specific to that configuration (lets say connectionstring). When you compile, within the build definition you can select which configuration you want to compile (Dev, QA, prod) you dont have to keep multiple build defintion. Just one is enough! After the compilation is done, the root web.config will be replaced with the values specific to the configuration for the connectionstring part alone.
Hope this helps!
Yes this possible. You can keep configuration files in different mode for eg:
You can have configuration files in Release mode debug mode, release mode and the common configuration file used by all.
So when you build your solution in Debug mode then the debug mode configuration file will be used and when in release mode then release mode configuration file will be used.
For further clarity take example of web config when you will expand the web config tab you will see the two configuration file in different modes.
I know that you can create a template project to ensure that certain required settings (for ex: code analysis, treat warnings as errors, platforms, etc.) are set in a new project.
I want to enforce this as a part of the CI process i.e. in the build I want to validate the C# project files against a template (or an XML file) and cause a build failure if the project files don't conform to it. I need suggestions and ideas on how this can be achieved.
I want to try this with TFS 2010 and VS 2010.
I am writing a custom task to search for all the C# project files and compare the Xml structure of the Template project file with the Actual project file and report any difference as error.
I usually tackle this by customizing my build process to run Code Analysis/StyleCop/etc against all projects regardless of project settings.
Likewise for Treat Warnings as Errors. I just override the proejct settings at the build-level so that no matter what people do to the projects I know that everything I want to run is being run at build time.