Moving package management to a csproj

In order to move forward with duality we have to find a way to make dualities way of managing packages compatible with .netnstandard en .netcore.

As it already turned out the nuget upgrade is very painful, so much that I don’t really see this upgrade happening anymore.

This issue is to research a completely different approach in which we actually remove the build in package manager from duality. Instead managing packages will be done like any other .NET project, from a csproj.

This has a number of advantages:

• Its the standard way to managing packages so developers are already familiar with it
• if the csproj is the source of truth then distributing duality could also be done with a dotnet new template based approach (https://devblogs.microsoft.com/dotnet/how-to-create-your-own-templates-for-dotnet-new/).
• Better integration with the .NET build system (self contained applications?)

Some disadvantages:

• building a csproj will dump all dlls in the same folder. This means plugins won’t end up in a plugin folder. Duality currently cannot handle this without some modifications.
• documentation XML files are not copied to the build output folder. I think duality has to be modified to also look for matching documentation files in the global nuget folder. Alternatively we could add a custom target:

<Target Name="CopyXMLFromPackages" AfterTargets="Build">
    <Copy SourceFiles="$(PkgPackage_Name)\lib\netcoreapp3.1\{PackageName}.xml" DestinationFolder="$(OutDir)" />
</Target>

• probably some more loose ends.

Most optimal solution would be to stay as close to a default csproj as possible, which means I would lean more towards modifying duality to fit with the default instead of csproj wizardry.

Work has begun on a poc duality template https://github.com/Barsonax/DualityProjectTemplate

[Barsonax]

So, why not try and go along the route of having a .net core editor (made with Avalonia maybe)? Of course this would also mean that until OpenTK doesn’t come out with its .net standard compliant version, we can’t proceed with a full upgrade, but that would be the case anyway, no?

This sounds like a total rewrite of the duality editor. A much bigger change than what we are trying to do now. Might be interesting for the future (duality 5.0.0? 😛) though. We do want the duality editor to be crossplatform on netcore (or net 5 in the future) eventually.

Pretty much solved the path issues already, just running into some issues that is caused by duality nuget packages not following the (newer) standards.

[Barsonax]

Sounds good. Maybe we can get down to just a .csproj, .sln and maybe an optional “extract + run” convenience script.

I think so so this will make the initial package really small and we could probably turn it into a VS template or do something with dotnet new so you can start a new duality project purely from the command line. That’s more stuff for the future though but a very nice to have.

I think immutable is generally okay for content and source that comes bundled with a package - it’s not meant to be modified, and any modification to them in a project would be gone when updating the package. We should still check what exactly immutable means - does it flag the files as read-only? Are they only read-only in Visual Studio?

Last time I checked you could actually modify them from visual studio. This seemed like a bug to me. Content files are shared (as in they don’t actually reside in the solution directory) so I don’t think you even want to modify them as that can cause some issues with other projects referencing those files. Even if you do as soon as you push it to a CI server your changes would be completely gone.

So let’s say we use a custom build output path that is the folder where the .csproj and .sln are itself, that would mean all the required binaries, launcher and editor would end up right there as well. The editor will create its own subfolders as needed when run, and all packages bundling content could target a Data\PackageXY subfolder. Bundled sample source code could target Source\Code\PackageXY, but that would only make sense if the users game plugins are there as well. So where is the user going to write their game code?

Plugins should be a separate csproj but we can add it to the same solution file.

I’d recommend not changing Duality’s general directory structure in the first step - it’s an option, but as long as we can manage without, that would be the safer route.

Yup we can try to see how far we can get without changing the directory structure. I don’t think we can get to 100% though but it will make the bigger picture more clear.

I think we could use an overview on the directory structure and files we’re going for, so we have something concrete to talk about and iterate on. @Barsonax Can you create one based on prototype and latest thoughts in the thread?

Ye agreed I can setup a template, it will not work yet as it will require some changes in duality but it would make our idea’s more concrete than just a discussion.