hxcs icon indicating copy to clipboard operation
hxcs copied to clipboard

.NET Core Support

Open AlseinX opened this issue 5 years ago • 15 comments

Following the tutorial on the website to create a simple helloworld, I failed, and after looking through the related issues and PRs I finally got it transpiled, but still the generated project csproj file was in the old Visual Studio dependant style, which is certainly not working with .NET Core SDK building. I realized hxcs not supporting .NET Core yet.

But note that .NET Framework has been archived with its final version 4.8, then .NET Core (will be called '.NET' version 5 in the future) becomes the unique officially supported .NET implementation. Therefore by a certain day in the future, not supporting .NET Core equals to not supporting .NET.

As most companies have turned to use .NET Core, abandoning .NET Framework in their new projects, not supporting .NET Core is a critical reason that they would not take Haxe for their .NET stacks.

Thus I do think hxcs should pay all attention to support .NET Core, or Haxe would be no longer taken as a language that targets .NET.

AlseinX avatar Jul 29 '19 10:07 AlseinX

Have you seen https://github.com/HaxeFoundation/haxe/pull/8391 / https://github.com/HaxeFoundation/haxe/issues/5480?

Gama11 avatar Jul 29 '19 10:07 Gama11

It's not enough to easily get started with .NET core though =/ I started working on something to interface with dotnet cli but it's still WIP and I don't have much time for this atm.

kLabz avatar Jul 29 '19 10:07 kLabz

@Gama11 Yeah I got it transpiled by both issues related. but the problems is the generated project is incorrect. @kLabz What exactly the difficulty is about? I have been learing .NET Core and leading the team in refactoring the existing projects to .NET Core in for 2 years. I wish I could help but I am new to Haxe. Surprisingly found there a language that I had been seeking for and I wished it would support .NET pretty much.

AlseinX avatar Jul 29 '19 11:07 AlseinX

Yeah atm it only really works with -D no-compilation and using dotnet CLI to do the C# compilation with haxe-generated C# files.

The main difficulty I have is providing an easy way to do all that for everyone, and properly use dotnet CLI from haxe/hxcs to avoid this workaround (+ handle C# dependencies, etc.).

kLabz avatar Jul 29 '19 11:07 kLabz

The project file structure and the build pipeline of .NET Core the clearest one I have ever seen. The properties and items that exist in the csproj file are the only things that should be specified and fully readable. It should be much easier than .NET Framework. I think there should be things like (the naming is just for example):

  • A flag to specify the SDK used:

    --net-sdk Microsoft.Net.Sdk to be converted to <Project Sdk="Microsoft.Net.Sdk"> as the root element of the csproj

  • A flag to specify MSBuild properties:

    --net-prop PublishSingleFile=true to <PublishSingleFile>true</PublishSingleFile> in the PropertyGroup element

  • Flags to specify dependencies in a ItemGroup element (there are only package references and project references in 2.x and also framework references in 3.x):

    --net-package-ref System.Reflection.Emit -v 4.6.0-preview7.19362.9 to <PackageReference Include="System.Reflection.Emit" Version="4.6.0-preview7.19362.9" />

    --net-project-ref ../Foo/Foo.csproj to <ProjectReference Include="../Foo/Foo.csproj" />

    --net-framework-ref Microsoft.AspNetCore.App to <FrameworkReference Include="Microsoft.AspNetCore.App" />

These are all regularly needed. And also there should be an import flag to allow user to customize with the native MSBuild configuration:

--net-props ../bar.props to <Import Project="../bar.props"> at the beginning of the Project element

--net-targets ../bar.targets to <Import Project="../bar.targets"> at the end of the Project element

And that would cover almost all situations. Note that things that exists in the csproj file of a new SDK style project are exactly the things that the user needs to specify.

AlseinX avatar Jul 29 '19 12:07 AlseinX

Thanks, that will help.

Though there is still the "reverse" problem of getting the DLLs from dependencies in order to provide the "externs" to haxe code so that we're able to use C# APIs from Haxe. I have a prototype that does that when you project is "restored" but with poor UX and possibly many edge cases.

Unless we let the users manage that themselves like they probably do with .NET already (and like I do with some custom tools for netcore), but that's far from optimal =/

kLabz avatar Jul 29 '19 12:07 kLabz

I think it a must to generate the csproj and do "restore" when developing. Nuget would generate assets files inside the obj folder and it would list all restored packages. The nuget packages are simply zip files with extensions .nupkg which could be found in ~/.nuget where the .nuspec files inside the package would contain all infomations and the dll files are placed in the path respectively as their target platforms and runtimes. Note that all standard libraries come from nuget in .NET Core 2.x but the core libraries as well as ASP.NET Core are provided directly by .NET Core (known as framework dependencies) which could be found in the /usr/share/dotnet or C:\Program Files\dotnet

AlseinX avatar Jul 29 '19 13:07 AlseinX

Yeah that's what I'm doing. Getting dlls from the sdk felt more hacky but it worked as far as my tests went.

kLabz avatar Jul 29 '19 13:07 kLabz

It is not "hacky" since all of the code intellisense tools like omnisharp use the dlls from the sdk. It is intended.

AlseinX avatar Jul 29 '19 13:07 AlseinX

Yeah, just the way I was doing it felt hacky. I'll get my prototype tomorrow and try to clean it up (and make it work with my work projects)

kLabz avatar Jul 29 '19 13:07 kLabz

@kLabz How is it going on currently?

AlseinX avatar Sep 16 '19 07:09 AlseinX

Haven't had the occasion to work on this again and I don't have my sources right now. Would need to get them tonight/tomorrow morning and use them against my work project tomorrow or some other day this week.

kLabz avatar Sep 16 '19 07:09 kLabz

Woah nice. I am expecting it so much.

AlseinX avatar Sep 16 '19 08:09 AlseinX

I just really need to think about this at a moment I have access to it =/

Though it's already been possible to use dotnet core with haxe for a long time (been doing so for over a year here at work), it's just not really integrated atm but works fine with dotnet watch.

Edit: well.. looks like it's not in the state I expected it to be.. can't get anything to work on my work computer. Will have to try again tomorrow.

kLabz avatar Sep 16 '19 08:09 kLabz

I have just added a pull request (https://github.com/HaxeFoundation/hxcs/pull/53) which adds .NET core support to hxcs.

Hope @kLabz, or other contributors may take a look and if useful, could integrate into the project.

hxgrounds avatar Mar 17 '24 12:03 hxgrounds