NuGet package?

[jvyden]

Like the JavaScript ecosystem's npmjs.com, most .NET library are distributed via the central packaging ecosystem on nuget.org.

Is there any chance to distribute this project on NuGet? I did find this but it looks to be a fork of this project with a bunch of missing metadata and I don't particularly trust it: https://www.nuget.org/packages/RobloxFileFormat

NuGet packages can be entirely automated (give or take renewing a key every so often), I can write a GitHub actions workflow and contribute it if you would like.

[jvyden]

Also I'm unsure of your usecase for this and if it requires the old .NET framework, but I can also migrate this project to .NET 10 which is a lot more portable and is much faster. Or if you would not like that I can at least migrate to the new tooling which can significantly clean up the csproj files.

[MaximumADHD]

Yeah that's not mine.

I was actually looking into this the other day. The only reason I've hesitated to migrate from .NET Framework is because I was worried it made executable files less portable. My previous attempts to migrate over to .NET Core have been a huge mess.

I'll look into this.

[jvyden]

There are quite a few breaking changes between .NET Framework 4.7.1 all the way through .NET 10, but none seem to affect this project.

It would depend on what exactly what you mean by "make executable files less portable", but you can also choose to compile for both .NET Framework and modern .NET, packaging them both in the same NuGet package.

I've successfully migrated it to .NET 10 in a fork with some build-time shenanigans such as removing the unit test project that can easily be worked around, but I haven't for my personal usecase. The core library however seems to work perfectly.

[MaximumADHD]

This is separate to the scope of this project but... anytime I've tried to a .NET Core application, it would either try to bundle all of the .NET dependencies as DLLs that have to be bundled next to the executable, or I'd be required to pack them in the executable directly which would balloon the size.

How I've gone about handling all of this might just be a side effect of being self-taught instead of getting caught up with the ecosystem more properly. If this is migrated to .NET Core, pretty much everything in my datamining toolchain needs to be as well.

[jvyden]

it would either try to bundle all of the .NET dependencies as DLLs that have to be bundled next to the executable

That sounds like a side effect of self-contained deployment. You can force that off by setting <PublishSelfContained>false</PublishSelfContained> in your csproj, or by setting --no-self-contained.

By publishing a self-contained application you remove the need for end users to install the .NET runtime, but you also add the cost of storage space. There is also trimming (removing unused methods and classes, etc.) but trimming can get complicated.

If you're building a desktop application you can set your build type to WinExe which will guide the user via GUI into downloading .NET if the runtime isn't present on their system, at least on Windows. Linux has a similar thing but only displays in the CLI.

or I'd be required to pack them in the executable directly which would balloon the size.

This is PublishSingleFile, which indeed packs them into one file.

[jvyden]

Also worth mentioning that if you build both .NET Framework and .NET 10 into NuGet packages then that will make the transition a lot easier since you can make changes to this project while working on upgrading the rest of the toolchain. Framework projects will use the Framework DLL, .NET 10 projects will use the .NET 10 dll.