.NET Core Support about hxcs HOT 15 OPEN

Have you seen HaxeFoundation/haxe#8391 / HaxeFoundation/haxe#5480?

from hxcs.

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.

from hxcs.

@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.

from hxcs.

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.).

from hxcs.

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.

from hxcs.

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 =/

from hxcs.

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

from hxcs.

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

from hxcs.

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

from hxcs.

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)

from hxcs.

@kLabz How is it going on currently?

from hxcs.

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.

from hxcs.

Woah nice. I am expecting it so much.

from hxcs.

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.

from hxcs.