Modernizing .NET version in NuGetGallery (nuget.org service and jobs), move away from .NET Framework

[joelverhagen]

This is based on the issue raised here: #10398.

I wanted to create a discussion instead of having a long back-and-forth on an issue, which can become hard to track.

[joelverhagen]

From @tonyqus (source):

@joelverhagen I'm a bit new to Nuget.org architecture. I have been a normal user for nuget.org for 10 years and I heavily rely on nuget.org data to generate a few community statistics such as China OSS community Ranking. The major reason I created a ranking is to prevent non-sense bullying in China .NET community.

Do you have a post or something that I can see how many servers or components you have for nuget.org? Or an architecture diagram?

[joelverhagen]

Let's try to keep this discussion focused on .NET Core / .NET Framework.

For your advanced statistics, I think the part that is most likely to happen first (still, unclear timeline) is #3450, which is number 2 by upvotes.

[joelverhagen]

I understand your frustration around this issue. Let's try to keep this discussion focused on .NET Core / .NET Framework.

[tonyqus]

I remove the previous comment and let's focus on .NET core migration

[robertmuehsig]

And moving NuGetGallery to .NET Core would be the very last step I think. It would be a huge task since there is deep integration with ASP.NET MVC (non-Core) framework (DI, auth, controller base types).

In general the Frontend and the Backend jobs are quite disconnected, right? The backends jobs might be easier to migrate to .NET Core (at least on the code level, deployment etc. might be more challenging), but in theory it doesn't matter (but the frontend might be harder, because ASP.NET MVC to ASP.NET Core is a bigger "change").

[joelverhagen]

Yes, that's right. Moving backend jobs early in the process makes a lot of sense to me. It would force us to cross target all of the shared code, leaving just NuGetGallery-specific code as .NET Framework only (for the time being).

[tonyqus]

@lahma I'd like to involve my good friend Marko Lahma, the author of Quartz.NET. He is a senior software architect.

Hi Marko, any idea to use Quartz.NET to convert existing nuget jobs to .NET Core and make it work? You are the expert of job scheduling.

[joelverhagen]

I am glad it helped. There is plenty of internal deployment goo that is not included in the diagram and must be considered when moving the job to .NET core. Most importantly, we need to ensure the right .NET runtime is installed on the VM and .NET runtime servicing is considered. These are internal and operational tasks the team is responsibility and block the migration.

[joelverhagen]

If the job can continue to run as a .NET framework exe during the midst of the migration, then this problem goes away (I think).

[tonyqus]

Most importantly, we need to ensure the right .NET runtime is installed on the VM and .NET runtime servicing is considered.

Btw, which .NET runtime is installed by default in internal VMs? .NET 8 (LTS)?

[joelverhagen]

No, not .NET 8. It is .NET Framework. I don't believe .NET runtime is on there at all. Which is part of the problem. We use the .NET Framework runtime built into Windows OS, and leverage the .NET Framework servicing provided by our managed Windows server image.
[edit: there may be a built-in .NET (not framework) runtime there. But we don't use it directly. We use .NET Framework runtime].

[erdembayar]

I think any migration should follow order we did for Azure SDK migration https://github.com/NuGet/NuGetGallery/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+sdk, by merging to feature branch.
First we update the shared core project then move to the consuming projects