Updating everything

[TclasenITVT]

Hi jmecsoftware I am trying to update the whole plugin to the newest possible version of everything that is used. Is there documentations about what the constraints of this solutions for instance why framework 4.5.?
I hope that with a little bit of help I can get this finished fairly quickly.

[milbrandt]

Framework 4.5 was up-to-date when the plugin was created in (May) 2015. 4.6 was relased later in that year. Thus I assume it was never updated.
Let give it a try and create a pull request even with 4.5. I would hope that several issues can already then retested and closed. A second step would then to go for .NET Core.

[TclasenITVT]

My First issue with updating the Plugin is that after updating the packages to the newest version, that still supports 4.5,

Error FS0193 The module/namespace 'Microsoft.FSharp.Compiler.Range' from compilation unit 'FSharp.Compiler.Service' did not contain the namespace, module or type 'range' FsSonarRunnerCore C:...\sonar-fsharp-plugin\FsSonarRunner\FsSonarRunnerCore\SQAnalyser.fs

After researching what happend to 'Microsoft.Fsharp.Compiler.Range.range' I found that it moved to 'Fsharp.Compiler.Range.range'. The Problem is that even with the open Fsharp.Compiler.Range it still shows that error. I can't find the place where that type is used in the SQAnalyser.

[milbrandt]

I see the message that the FsSonarRunnerCore project doesn't reference on net45. I'll try to give it a try on the public holiday.

[jmecosta]

nop, u can try to upgrade! or even better i think the way forward is to do .net core --self-contained package. I think i will have a bit of time in the upcomming weeks to update all this. Apologies for getting a bit behid.

[milbrandt]

Self contained dotnet Core will require replacement of FSharp.Compiler.Service.*

For now a PR #30 was created to update most nuget packages, update to full .Net framework 4.7.2 and new project format of Net.SDK.

There are still some issues (most unit tests, Maven build) - anything already fixed and support are welcome.

[jmecosta]

for reference https://www.nuget.org/packages/FSharp.Compiler.Service/ 29.0.0 targets .net standard 2.0. So in principle we should be able to create self deployment packages once we upgrade those.

[milbrandt]

Yes, but unfortunately https://www.nuget.org/packages/FSharp.Compiler.Service.ProjectCracker/ v29.0 still is only .Net 4.6.1

[jmecosta]

Alright thanks for the effort and update. I havent checked the compiler service but earlier version was requiring mono to run on linux, it would be nice to move to .net core at this time. Even if it takes a bit more time updating the compiler service

…

On Thu, 30 May 2019, 12:40 Volker Milbrandt, ***@***.***> wrote: Self contained dotnet Core will require replacement of FSharp.Compiler.Service.* For now a PR #30 <#30> was created to update most nuget packages, update to full .Net framework 4.7.2 and new project format of Net.SDK. There are still some issues (most unit tests, Maven build) - anything already fixed and support are welcome. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#26>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH6HSDOHUQQ4LKYQAERAADPX6OINANCNFSM4HDKPNIQ> .

[jmecosta]

This is probably a good candidate for removal since this is a legacy package. I dont remenber why we even have it here 🙂

…

On Fri, 31 May 2019, 09:58 Volker Milbrandt, ***@***.***> wrote: Yes, but unfortunately https://www.nuget.org/packages/FSharp.Compiler.Service.ProjectCracker/ v29.0 still is only .Net 4.6.1 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#26>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH6HSA5LN23N6RK25CM7ELPYDEDFANCNFSM4HDKPNIQ> .

[milbrandt]

@TclasenITVT in PR #30 I updated everything on the F# side up to now. The solution compiles. tests are passing and I could run the FsSonarRunner on this project. Only the intended "bugs" in FsSonarRunner\FsSonarRunnerCore.Test\Resources\LintTestFile.fs are still in. Maybe you want already to have a look on it, also review on the PR would be welcome.

[milbrandt]

nop, u can try to upgrade! or even better i think the way forward is to do .net core --self-contained package. I think i will have a bit of time in the upcomming weeks to update all this. Apologies for getting a bit behid.

This will restrict us to a target platform (eg win7-x64): https://docs.microsoft.com/en-us/dotnet/core/versions/selection#self-contained-deployments-include-the-selected-runtime

Up to now with the dependency on net45/net472 we are also restricted to Windows. But shall we continue to require this or demand that a current .NET Core is installed on the build servers? Then (in theory) the plugin would be OS independent.
Easier to do is for sure the win7-x64.

[jmecosta]

nop, u can try to upgrade! or even better i think the way forward is to do .net core --self-contained package. I think i will have a bit of time in the upcomming weeks to update all this. Apologies for getting a bit behid.

This will restrict us to a target platform (eg win7-x64): https://docs.microsoft.com/en-us/dotnet/core/versions/selection#self-contained-deployments-include-the-selected-runtime

Up to now with the dependency on net45/net472 we are also restricted to Windows. But shall we continue to require this or demand that a current .NET Core is installed on the build servers? Then (in theory) the plugin would be OS independent.
Easier to do is for sure the win7-x64.

Hum, not sure i understand.

this is how i do for a wrapper i created https://github.com/jmecsoftware/CxxSonarQubeRunner/blob/master/CxxSonarQubeRunner/CxxSonarQubeRunner.fsproj#L9 then i have https://github.com/jmecsoftware/CxxSonarQubeRunner/tree/master/Tools scripts that call one platform or the other.

as a side note, the plugin was supporting .net and mono. but the problem iwht mono is that it needs to be installed.

on the other hand, creating self contained packages will increase the size of the package quite a bit. If its put in marketplace they might not accept because of the size

[milbrandt]

nop, u can try to upgrade! or even better i think the way forward is to do .net core --self-contained package. I think i will have a bit of time in the upcomming weeks to update all this. Apologies for getting a bit behid.

This will restrict us to a target platform (eg win7-x64): https://docs.microsoft.com/en-us/dotnet/core/versions/selection#self-contained-deployments-include-the-selected-runtime
Up to now with the dependency on net45/net472 we are also restricted to Windows. But shall we continue to require this or demand that a current .NET Core is installed on the build servers? Then (in theory) the plugin would be OS independent.
Easier to do is for sure the win7-x64.

Hum, not sure i understand.
this is how i do for a wrapper i created https://github.com/jmecsoftware/CxxSonarQubeRunner/blob/master/CxxSonarQubeRunner/CxxSonarQubeRunner.fsproj#L9 then i have https://github.com/jmecsoftware/CxxSonarQubeRunner/tree/master/Tools scripts that call one platform or the other.
as a side note, the plugin was supporting .net and mono. but the problem iwht mono is that it needs to be installed.
on the other hand, creating self contained packages will increase the size of the package quite a bit. If its put in marketplace they might not accept because of the size

Sure, multitargeting is not an issue during compile time for self-containing. And yes, you can pack all of them in the zip.
But now the Java plugin needs to call the matching for the build server OS. On a first glance, you have several scripts to execute manually, but this needs to be done by the plugin without user intervention. This might be tricky, maybe it's easy - I don't now.

For framework dependent deployment, we would depend on installed dotnet Core - as you did on Mono. That's easier to deploy - but also easier to break.

[jmecosta]

the java plugin is already doing that for mono https://github.com/jmecsoftware/sonar-fsharp-plugin/blob/master/sonar-fsharp-plugin/src/main/java/org/sonar/plugins/fsharp/OsUtils.java, so it should be big issue to make it flawlessly everywhere. The problem i see the size of the jar, that will become huge :) if that is a problem they going with .net core seems the most suitable way forward.

[milbrandt]

Update to net472 and updating all nuget and Maven dependencies in release v1.1.0.
I'll keep this open as here is some discussion regarding upgrading to .NET Core.