Enable connected mode for .Net Core projects

[Evangelink]

Currently it is not possible to used connected mode to analyse .Net core projects.

Contributes to MMF-876.
Is duplicated by SVS-151.

[Evangelink]

ProjectTypeGuid for
.Net Core xproj: 8BB2217D-0F2D-49D1-97BC-3654ED321F3B
.Net Core csproj: 9A19103F-16F7-4668-BE54-9A1E7A4F7556

On .Net Core csproj, we need to add the following:

<PropertyGroup>
    <CodeAnalysisRuleSet>MyRuleset.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
<ItemGroup>
    <AdditionalFiles Include="SonarLint.xml" />
</ItemGroup>

When the guid is supported and the PropertyGroup and ItemGroup are added the analyzers seem to be working properly but:

• the squiggle lines don't appear (when activating a new rule) until project is unloaded/reloaded or solution is closed/reopened.
• warnings properly appear in the build log (output window)
• Lightbulb doesn't show up but CTRL + . is working.

[ghost]

Hi,

Saw this feature planned for milestone 2.14, now planned for 3.0.
Is there any chance to get this feature in coming days/weeks ?
My team is starting to use .Net Core for new projects, and would be great to get this feature soon, there's no emergency for us to get it, but if we have to wait for month, we will not wait, and try the workaround posted before.
So any idea on the schedulle of this feature ?

Thanks a lot for your work

[Evangelink]

Hi @TangAgapes,
You are right this was originally planned for 2.14 (that we changed into 3.0) but after some investigations the solution seems to be a bit more complex than expected (especially to fully support C#7 syntax).

[NeilCross]

Cheers for the update, any rough indications on the timelines we could expect as this issue has no milestone assigned currently?

[ed11s8c]

@Evangelink Is there any news for this task? It seems to have been pushed back several times over the last couple of months. Its a real pain when .Net Core is now stable so will be used by many for new projects going forward.

[mracz]

@Evangelink Could you please give any update on ETA of the fix for this issue? We heavily rely on .NET Core projects and we would like to utilize SonarLint. Thanks!

[Evangelink]

@TangAgapes @NeilCross @ed11s8c @mracz Hi guys, we know that this feature is really important for you and we haven't forgotten about it but we cannot commit to a release date at this point. We definitely hope to have this done by Q4 but I can't be any more specific than that.

[TheYorkshireDev]

@Evangelink Will you be developing the integration of SonarQube for the newly released .Net Core 2.0 only or will you also be developing with support for .Net Core 1.0 & 1.1 too?

[Evangelink]

@TheYorkshireDev I don't know yet but my gut feeling is that we will support only .Net Core 2+

[Robak23]

@Evangelink Any ETA for resolving this issue?

[Evangelink]

@Robak23 I am tempted to answer still on time but to be fair we only did one step forward for now (moving the analyzers to .net core - unpublished for now).

[Robak23]

@Evangelink Thank you for the answer. I look forward to your updates on that issue.

[danielgreen]

Hello @Evangelink are you able to offer a more concrete ETA please?

[abhishekbdutta]

Hello @Evangelink can you please tell us some probable dates, would be very nice.

[ghost]

Is this up for grabs. Please let us know if anyone can help towards resolving this.

[Evangelink]

Hi guys,
We expect to be able to provide the support for .Net Core projects in SonarLint connected mode by the end of next week.

[abhishekbdutta]

The connected mode is working but the rules which are configured as errors on the severs are shown as warnings in the rule set in visual studio

Sonar lint: 3.8
SonarQube server: 6.7
Sonarc# Analyzer on server: 6.6 (build 3969)

[valhristov]

@abhishekbdutta that's by design and applies to all languages and IDEs - if the rules in VS were configured as errors we would break your build and we don't want to do that.

[abhishekbdutta]

@valhristov thanks for the reply, but i have some concerns
The one of objective of putting the sonarqube in an organization is to have a set of rules consistent across all the teams. These rules are part of quality gates.
This means that the server will report errors and stop by CI process. The developer needs to fix these ASAP.

In this given case if they are configured as error in VS then the above uses case wont come right ?

[valhristov]

@abhishekbdutta that's correct, but imagine a project that contains hundreds (or thousands) of issues - you will have to fix them all immediately after installing SonarLint because otherwise you will not be able to work. We want to avoid that. The developers should be able to ignore the old issues (e.g. the technical debt) and fix them little by little. In addition, sometimes it might be required to add new debt, for example to quickly provide a version to the QAs to test.

By the way, the Scanner for MSBuild will also turn off TreatWarningsAsErrors, so CI will not be broken even if you commit not very clean code.

The general recommendation is to enforce clean code through quality gates or code reviews (which is a good practice even without SonarQube).