Problem installing packets

[Ghiraim]

Describe the bug
Hello, I'm trying to install NuGet packages to build the "els_kom_new" project, but actually I can't at all. I tried to build the directory downloaded with git, putting it in the dotnet sdks folder. Then I tried to install them using MSVisualStudio's Package manager, but nearly all of them result in a 404 error. Also, links to Elskom.Common, Elskom.Sdk and UnluacNET return a 404 error. I hope you can help me

To Reproduce
Steps to reproduce the behavior:

1. Enter in Package manager the line "Install-Package [Packet_Name] -Version [Version_suggested]"

Screenshots
Trying to install BlowFish:

While trying to install Elskom.Sdk, version 1.0.0:

[AraHaan]

Currently everything is not available on nuget yet due to a regression in the zlib so everything including updating the Els_kom_new project is delayed. Currently I would recommend cloning this repository and the zlib.managed repository as well, doing a build, and adding the build artifact directories to your computer's nuget.config file for now as separate nuget feeds.

Also because of the delay expect to also need to git pull && dotnet build and then nuke the nuget cache with dotnet nuget locals all --clear in the mean time.

[AraHaan]

After thinking about this, I think the best course of action is to make a .NET global tool that can inject into the .NET 6 SDK workload manifests and then users would have to install the Elskom workload in order to use the SDK and it's runtime.

However there are 5 things though that would need to be done:

• splitting the actual C# code from here to a new repository for the runtime pack for the workload (Elskom/runtime)
  • hopefully the runtime packs are allowed to work when targeting .NET Framework or anything older than .NET 5 (the netstandard2.0 target on the runtime pack)
• having this repository for the Sdk pack.
• having another new repository for templates (Elskom/templates) for plugins.
• having the workload manifest for it all created and somehow properly done.
• The .NET global tool able to properly know where to spit the workload manifest.
  • This will be complex because there would be no way to know if they should go into only the newest .NET SDK or to a specific .NET SDK version.

[Ghiraim]

Ok, thanks! I will give a try to the first solution. The other one sounds too complicated :c I hope you will be able to solve this!

[AraHaan]

The other one should solve this where I should be able to then deploy the Sdk standalone to nuget.org with the runtime being a separate pack that will need to get in place updates on.

As for where it will need to check for the runtime updates, I am not sure. I do know that either way an .NET global tool will be needed to be installed for it all. I also plan to have it do a little update check for the runtime pack frequently though (I probably should have it check github for that one).

[AraHaan]

The new templates was just pushed to nuget.org. 👏

The Sdk will follow, and then the ref pack, and runtime pack.

I will also however see if I want to keep pushing the runtime parts as separate packages as well for those who do not want to go the workload route however I probably should deprecate those for the workload route.

[AraHaan]

The rest has been published even the Sdk. Now Els_kom_new should be able to be built at least soon if not currently now.

However it requires a tool to be installed and ran to install them, however Elskom/runtime can be built locally to produce installers which the tool would then pick up and use the files installed from them as well.