search

HaxeFoundation / hxcs

Haxe C# support library. Build scripts and support code.
The Unlicense
57 stars 21 forks source link

.NET Core Support #42

Open AlseinX opened 5 years ago

AlseinX commented 5 years ago

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.

Gama11 commented 5 years ago

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

kLabz commented 5 years ago

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.

AlseinX commented 5 years ago

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

kLabz commented 5 years ago

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

AlseinX commented 5 years ago

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

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.

kLabz commented 5 years ago

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

AlseinX commented 5 years ago

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

kLabz commented 5 years ago

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

AlseinX commented 5 years ago

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

kLabz commented 5 years ago

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)

AlseinX commented 5 years ago

@kLabz How is it going on currently?

kLabz commented 5 years ago

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.

AlseinX commented 5 years ago

Woah nice. I am expecting it so much.

kLabz commented 5 years ago

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.

hxgrounds commented 8 months ago

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.

mesheets commented 2 days ago

I would add my support support for .NET (formerly known as .NET Core) and .NET Standard (which, up to v2.0, can be used with both .NET [Core] and .NET Framework).

Some feedback in follow up to the aforementioned pull request #53 :

Handling of Target Framework Specification

In build-tool/csproj-template.mtt, specifically around line 17, is the following:

<TargetFramework>net::targetFramework::</TargetFramework>

I realize this part of the template for an SDK-style project follows the prior pattern of hard coding in a prefix of the <TargetFramework>, but I would prefer that there be no hard coding or assumptions as to what the Target Framework Moniker (TFM) might be. Many do start with "net" as a prefix, but not all. If the TFM provided to Haxe with SDK-style project files is the same as the TFM used by dotnet, then that might also offer a level of consistency. (Even if all the TFMs aren't supported now, it would make it easier to add support in the future.)

Unless there are other specific issues, I would prefer to see the line noted above replaced with the following (and the documentation updated accordingly):

<TargetFramework>::targetFramework::</TargetFramework>

Haxe Flags for .NET

Is the added "-D dotnet_core" flag intended to deprecate the "netcore" and "netcore-ver" flags (c.f. Haxe PR 8391)? That PR didn't add support for SDK-style project files, though.