Port to .NET Core

[bugproof]

I ran dotnet-apiport against the project and it seems like it's pretty compatible 😄
https://1drv.ms/x/s!ArqMTZb-afYkgQh9voOZzGCd7NKh

https://docs.microsoft.com/en-us/dotnet/core/porting/

Porting to .NET Core would make Sharpmake cross-platform just like CMake is and possibly increase performance too.

The first step would be to convert project files to the new format.

If I wanted to submit a PR, I should work on dev branch is that right?

EDIT: I already ported the project to the newer csproj format which greatly simplifies things but then I've noticed it's using itself now to generate project (74c8af9 )

which complicates things a bit... so either:

• revert this commit and use new csproj format
• write generator for new csproj format (does it make sense anyway?)

then another cool thing would be to make use of dotnet tool to install sharpmake easily without building it yourself.

[kudaba]

I opened a pull request that makes it so we can at least generate .NET Core projects (#63). Next I'm going to see if I can use that change to bootstrap Sharpmake into .NET Core and build natively in WSL.

[bugproof]

With all due respect, does it even make sense to use a project generator for C# projects?

People are using only one format anyway on Mac and Linux too (https://stackoverflow.com/a/6604782/2828480). In my opinion, it makes sense only for C++ projects as there are multiple formats.

Because of that I would drop C# support completely and focus on C/C++ projects only.

---

I think the biggest limitation in porting Sharpmake to .NET Core is Microsoft.VisualStudio.Setup.Configuration.Interop package for locating visual studio instances - it's .NET Framework only. The best workaround would be to port this package to .NET Core or use registry to find VS instances - CMake does it similarly.

[kudaba]

Yeah, that's going to be a challenge. I'm thinking I should be able to move that code into a separate dll that only gets built/imported on windows.

And it absolutely makes sense to generate c# projects. It's not so much about an individual file's format, it's more about enabling a lot of flexibility and freedom in overall project structure. Moving code around, generating multiple projects, complex inter-dependencies are very complex problems that sharpmake helps to trivialize.

The example about the VisualStudio setup dependency is a great example. Sharpmake scripts would allow me to add a platform specific IDE interop layer that only gets added to the solution for that platform.

[bugproof]

New csproj format can be used for both frameworks. You can still move code around as it implicitly compiles all the .cs files in a directory.

I think it's more convenient than sharpmake for c# projects - it just works cross-platform and no additional generation step is needed. And it looks like .NET framework will become obsolete soon or already is (https://github.com/dotnet/core/blob/master/roadmap.md). That being said, MSBuild is more than enough for c#/f#.

You can still multi-target but ideally .NET Core should be used even when targeting Windows.

<PropertyGroup>
  <TargetFrameworks>netcoreapp2.2;net462</TargetFrameworks>
</PropertyGroup>

Also, take a look at https://blog.magnusmontin.net/2018/11/05/platform-conditional-compilation-in-net-core/ for a nice solution to do platform conditional compilation

[kudaba]

I now have Sharpmake fully ported to .net core, including boostrapping and running on linux. I'm getting a friend to test it out on Mac soon. Going to wait for main devs to respond and get some feedback before doing a full PR for this. I also still have to test debug solution generation.

https://github.com/kudaba/Sharpmake

One thing that I noticed is a bit odd about working in .net core is that development builds are actually .dll files and not .exe files. To get proper functioning .exe to distribute you have to 'publish' which is quite a bit slower build.

[belkiss]

This is pretty neat! I'll try to test it out :)

[bugproof]

regarding dll files and not exe files: https://github.com/dotnet/cli/issues/6237#issuecomment-511001872

[malkia]

Is this still on the roadmap?

[belkiss]

Hello! Yes, it'll happen eventually, but because of the split between reference and runtime assemblies that was introduced with net core it has proven difficult to get it to work reliably.