.NetCore support

[AxeelAnder]

I simply ported tshock to .netcore today, strictly, it's multi-targeted, support .netfx4.7.2 and .netcore3.1. It works properly as far as I can see. But references of .netfx need more polishment to keep compatibility of current plugins.

[hakusaro]

What does .NET core actually buy anybody? Mono is easy to install and seems to work fine to me?

[QuiCM]

Would also require that all our consumers have 4.7.2 or DNC3.1 installed on their machines. I don't know how much impact that would cause. Would this affect the hosting platforms that provide TShock?

Netcore would allow us to package/build/etc easily as well so it does provide a number of benefits

[AxeelAnder]

Would also require that all our consumers have 4.7.2 or DNC3.1 installed on their machines. I don't know how much impact that would cause. Would this affect the hosting platforms that provide TShock?

Netcore would allow us to package/build/etc easily as well so it does provide a number of benefits

I can downgrade the runtime version as you want, there's no problem

[hakusaro]

Honestly I don't care about what we require users to install. .NET Framework has always been kinda a luxury because most people have it laying around in some form or another but we can always tell people to install things.

[rautamiekka]

.net core has best performance while mono is worst

So Mono support, and thus Linux support, will go ?

[AxeelAnder]

.net core has best performance while mono is worst

So Mono support, and thus Linux support, will go ?

you are still able to run .netfx version on mono, but .netcore is cross-platform and a lot faster than mono, there're artifacts in my pr's actions, you can try it out now. Just download the linux version and run

./TerrariaServer

[AxeelAnder]

I've changed both targets to AnyCPU and it seems did no damage to compatability, x86 plugins works normally on x64 runtime.

[hakusaro]

Okay so honestly, since you're actually on the team: you have the power and authority to decide that we have a .NET core version. In an ideal world, we would offer both a .NET core and a classic version, or at least switch to .NET core when we know for certain it has full support.

If you want to get this into master/gen-dev, you need to:

1. Have working OTAPI, TSAPI, and TShock, all ported in .NET core.
2. At least update the GitHub build tooling to produce downloads of dev versions.
3. Update the readme for cross platform build instructions.
4. Update the tshock.readme.io docs or provide modifications (I can give you access, just ask) so that people can actually set up and use a .NET core version of the server. Since we have docs for setting up mono right now, we'd need to change that.

Honestly if you got everything done and provided people with instructions on what to do and migrate and all that, we could pretty easily just accept the PR and transition it to full support.

[AxeelAnder]

I don't persist on or care much about that, I will follow your opinions, if you support it I'll do all things you listed above, if not I'll just discard this branch

[hakusaro]

I respect and support your judgement as a collaborator and contributor. To be clear, if it makes things easier or better or faster or stronger, ya, for sure, we can definitely accept that. The only reason why I'm not personally excited is because I just don't have experience running the server in dotnetcore or seeing performance changes. If you want to spearhead dotnetcore, let's do it!

[hakusaro]

(To be clear, if you say it's faster, I trust you! :)) just send a PR and I'm sure people will be super happy with it

[ronelm2000]

Just FYI, it's very possible to publish this as an independent binary without any references required. An additional benefit to this is not requiring Mono or netcore on release binaries.

Based on the build instructions, something like this should be within the realm of possibility.

dotnet publish ./TShockAPI/TShockAPI.csproj -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish ./TShockAPI/TShockAPI.csproj -r linux-x64 -c Release /p:PublishSingleFile=true

(More RIDs are available as needed; RPI support sounds like a stellar idea, something that's normally improbable due to mono's requirements.)

I'm in full support of this venture; good luck.

[AxeelAnder]

Done. It's so clean

[bartico6]

Upside of .NET Core is that all the ugly mono hacks you've been using can be phased out. On .NET Core 3+, .NET Framework apps run almost out of the box since all Windows.Forms etc. references were reimplemented and are re-routed by the runtime.

[AxeelAnder]

Thanks, I forgot that .netcore has supported winform yet

[lewisakura]

Hi, just my two cents, if you're going to be doing single file releases of TShock, make sure that you aren't bundling the entirety of .NET Core during your build process otherwise you're going to make giant files. My personal recommendation is a cross platform binary since people, who are going to be installing .NET Core anyway, can just run it with dotnet TShock.dll or whatever.

Another thing I recommend is enabling the trimmer. It gets rid of any unnecessary assemblies that may get bundled but never actually get used when publishing.

Good luck!

[AxeelAnder]

Thanks. The artifacts those name contains "any" is the cross platform binaries. And the reason why I choose to not trim dependencies is, TShock will load various plugins, if a library used by a plugin got trimmed, it may cause error.

[lewisakura]

You can add manual exclusions to the trimmer.

[AxeelAnder]

Thanks for your infomation, I'll try it later

[mixels]

I'm not finding much info on this outside this thread. Did you continue work on this? I'm very interested in a .NET Core release for improved performance.

Never mind, found it! Anyone else interested, you can find the pull request at #1735.