Hello, Currently we have a setup running using the C# 3.4 plugin for SonarQube and are relying heavily on custom powershell scripts in order to start a SonarQube analysis post-test. This works for us, however it takes a lot of time to maintain
this solution and has some quirks. That’s why I was pleasantly surprised to see that SonarSource and Microsoft have joined forces in order to provide us with a full integration :-) Unfortunately, most of our builds run in multiple build configuration, e.g. Debug Any CPU and Release Any CPU. This so that we can always match our production binaries to debug binaries in case of any issues. The MSBuildRunner currently
doesn’t support this. Are there any plans to support this in the (near) future? Or am I overlooking an option? We’re running SonarQube 4.5.4 in combination with the 4.0 C# plugin, version 1.2 of the Visual Studio Bootstrapper plugin and v0.9 of the MSBuildRunner. Thanks, Peter Op dit e-mailbericht is de disclaimer van Info Support van toepassing, zie http://www.infosupport.com/disclaimer |
Hi Peter, There are no plans at the moment to support this in the short term. We thought about this use case, and recommend that users setup a separate single configuration build for the SonarQube analysis. On Mon, May 18, 2015 at 4:38 PM, Peter Toonen <[hidden email]> wrote:
|
Hi Dinesh, We thought about that solution too but that means that you potentially have different binaries in production than the ones that you have full debug symbols for.
How do you suggest handling that? Thanks,
From: Dinesh Bolkensteyn [mailto:[hidden email]]
Hi Peter, There are no plans at the moment to support this in the short term. We thought about this use case, and recommend that users setup a separate single configuration build for the SonarQube analysis.
Dinesh Bolkensteyn On Mon, May 18, 2015 at 4:38 PM, Peter Toonen <[hidden email]> wrote:
Op dit e-mailbericht is de disclaimer van Info Support van toepassing, zie http://www.infosupport.com/disclaimer |
Hi Peter, I am not sure to get that point - you don't need to publish the artifacts produced by the analysis build, do you? The artifacts produced by the analysis build can simply be ignored. This means that you would end up with: 1. one multi-configuration build, which generates all your production&debug binaries - unchanged from today 2. one single-configuration analysis build, which generates binaries that you simply don't use On Tue, May 19, 2015 at 9:57 AM, Peter Toonen <[hidden email]> wrote:
|
Hi Dinesh,
You are correct. Sorry, I misinterpreted your answer. Thanks! Peter
From: Dinesh Bolkensteyn [mailto:[hidden email]]
Hi Peter, I am not sure to get that point - you don't need to publish the artifacts produced by the analysis build, do you? The artifacts produced by the analysis build can simply be ignored. This means that you would end up with: 1. one multi-configuration build, which generates all your production&debug binaries - unchanged from today 2. one single-configuration analysis build, which generates binaries that you simply don't use
Dinesh Bolkensteyn On Tue, May 19, 2015 at 9:57 AM, Peter Toonen <[hidden email]> wrote:
Op dit e-mailbericht is de disclaimer van Info Support van toepassing, zie http://www.infosupport.com/disclaimer |
Free forum by Nabble | Edit this page |