Add support for pure .NET Core Projects #887
Conversation
|
Kudos, SonarCloud Quality Gate passed!
|
mickael-caro-sonarsource
force-pushed
the
mc/659
branch
from
dfdc93f to
2c4c80c
Compare
|
@mickael-caro-sonarsource I'm guessing this change works because of the drop of modules in 7.6, so the module id GUIDs never make it as far as the server because the scanner engine translates the module file paths to paths under the root SQ project? |
|
@duncanp-sonar Yes, and duplications are also ignored, which is a good thing. Still the GUID appear as module in the sonar-project.properties file generated, but there's also a strange behavior i described in the description of this PR. I think we may need to work together as some point on that so that i better understand how we can improve this. |
@duncanp-sonar it will be good, but i'm scared of the amount of work to achieve that, and i might have to cut branches at some point if i want to keep the release date early november, except is this can be a quick-win (kind of). |
Makes sense. The thing I'd be most worried about is whether it's a change of behaviour that could have a detrimental impact on existing users. I think it should be ok in most cases; any projects that are currently being analyzed successfully will already have a GUID of some description, including shared projects. |
mickael-caro-sonarsource
force-pushed
the
mc/659
branch
3 times, most recently
from
e67a9f8 to
075b960
Compare
|
@duncanp-sonar after further tests, this works ok-ish in SQ 6.7 : the behavior is the same between the existing and new implementation of that. For SQ 7.6+, code is correctly computed and, even if the module is declared multiple times for the shared (with the number of dotnetbuild command that has the shared lib), LOCs are computed only once. |
…ion, generate a random one.
…perties generation.
mickael-caro-sonarsource
force-pushed
the
mc/659
branch
from
ce3225f to
da11cda
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
mickael-caro-sonarsource
changed the title
* If a ProjectGuid has not been found in either the csproj or the solution, generate a random one.
* Moved from WebClient to HttpClient. (#841) * Split TFS-specific code in a separate exe (#896) * Update license headers (#895) * Detect and take VsTestToolsInstallerInstalledToolLocation environment variable to set CodeCoverage.exe path. (#903) * Remove/Changed SonarQube-only log messages to be more generic with So… (#898) * Remove/Changed SonarQube-only log messages to be more generic with SonarCloud. * Fail fast if sonar.organization is provided in SonarQube.Analysis.xml (#901) * Changed deprecated projectKey parameters while fetching Quality Profile (#899) * Added .NET 5 flavor for the Scanner (#884) * Drop support for single-valued "sonar.cs.roslyn.reportFilePath" and "… (#902) * Drop support for single-valued "sonar.cs.roslyn.reportFilePath" and "sonar.cs.analyzer.projectOutPath" (and VB.Net siblings) * Add support for pure .NET Core Projects (#887) * If a ProjectGuid has not been found in either the csproj or the solution, generate a random one. * Fail fast in case the server license is invalid. (#907) * fixed bug - skipped shared across projects files (#876) * Update documentation (Proxy, .NET Core NET Version, added back conditional blocks for SQ/SC (#905) * Add a warning and clearer message in case of falling back to SonarOutputDir projectbBaseDir. (#908) * Add build configuration to TFS build
fixes #659
When no ProjectGuid has been found in whether the csproj or the solution, then we generate a random one.
Further improvement, which will not be in the scope of this PR, is to ensure that a shared lib is analyzed only once. This is not currently the case since each "dotnet build" on a csproj that has this shared lib will create a directory for it.