Observations while working on dotnet buildpacks

[KieranJeffreySmart]

I would like to start by explaining a bit about the naming of .net frameworks and why it is no longer called .net core.

The original .Net framework versions 1.0 - 4.* were developed with a hard dependency to the Windows platform and so any app built with these versions of the framework can only run on a Windows stack.

Around the time of .Net Framework 4.5 Microsoft moved towards a cross-platform framework but continued to support and improve their existing Windows framework. This led to .net core being developed in parallel with .Net 4.* and so, there were two framework options; .Net 4.* for windows apps and .net core for cross-platform apps.

The ultimate goal for Microsoft was to publish a single framework. To do this, the .net core framework was rebranded to .Net 5, to be consistent with older frameworks and a clear migration path was established from .net core 3.* to the new .Net 5 framework.
However the older frameworks, 1.0 - 4.* being heavily dependent on Windows meant not all features could be ported across to the new .Net 5. This means there is no clear migration to get from .Net 4 to .Net 5 and often results in a rewrite of sorts.

Effectively .Net 5 broke the backwards compatibility of previous versions of the .Net framework, and .net core is considered the precursor to .Net 5 and above, which is backwards compatible.
Any app using .Net 4.* and below is tied to the Windows platform and incompatible with .Net 5 and above. Any app using .net core framework is cross platform and is compatible with .Net 5 and above.

If I were a new developer I would see .Net Framework as being the branded name for 5.0 and above, not .net core (or dotnet core). I think it is only developers that have worked with the legacy framework that identify it in that way.

There is also a framework called .Net Standard. This framework is at the root of both .net 4.* and .net core and offers the only cross compatibility between Frameworks but can only be used for class libraries, not executables. However since moving towards .net 5 this is obsolete as there is only the one framework.

Anyway I hope this helps clarify the crazy branding of the .Net framework, please let me know if there is anything I can add here.
For reference this article has a more detailed review of the differences between frameworks

onto my observations:
SDK, Runtime and ASP Buildpacks
Dependencies between buildpacks and what an app developer might expect:
When building any application, the SDK and Publish buildpacks will always be needed
When running an ASP.net web app the ASP runtime will always be needed
When running a console app (batch jobs/cron jobs), only the standard runtime is needed

I understand the majority of applications are going to be web apps, and it is possible that no one will care that ASP is included with the runtime, however there could be a use case for not including it in cron, batch or pipeline applications, where there is no web api.
If there is already some insight into this that you considered when making the decision to merge the ASP and runtime buildpacks, then please share that with me.

Detecting target framework
During my investigation I spent a long time digging through the logic to extract the target framework. I observed the following:
Detect logic is duplicated between packages and possibly the functionality is being coded in different ways.
A lot of hard coded version manipulation caused complexity when trying to resolve pre-release versions of the .net framework. The logic in the ASP-runtime buildpack is particularly complex and was difficult to follow.
Perhaps there could be some refactoring of this code to make it easier to read and debug and possibly re-use logic or keep it consistent between buildpacks.

The logic for detecting the version of .net using a project file, is part of the runtime buildpack. This seems unusual as it is the SDK buildpack that is responsible for building the project and I would have thought the runtime buildpack would assume the build has already happened and a .json file is available for retrieving the correct version of .net, as opposed to the SDK making this assumption. I think my biggest concern would be if the order you list your buildpacks is important and not getting that right could result in a failure to detect a project. Not really sure that is the case but it does seem a little odd.