As @manfred-brands pointed out in #1176, this code makes the engine a bit fragile as new runtimes are introduced.
We could, of course, invent some fake CLR version to return here, but that might cause the problem to pop up elsewhere.
The code in question is only called to populate the ClrVersion property of the RuntimeFramework class. Let's take a look at where that property is used and see if we really need it. If it isn't, let's remove it. Or if it's only needed in our .NET Framework builds, let's make it conditional, which would keep the problem from arising as new runtimes are released.
@manfred-brands I'm assigning this to you as requested. You should note that our longer-term goal is to replace the RuntimeFramework class with something new, based around FrameworkName. So if this particular fix gets too complicated, we should move on to replacement. However, if RuntimeFramework can be simplified first, replacement will then become a bit easier.
As @manfred-brands pointed out in #1176, this code makes the engine a bit fragile as new runtimes are introduced.
We could, of course, invent some fake CLR version to return here, but that might cause the problem to pop up elsewhere.
The code in question is only called to populate the ClrVersion property of the RuntimeFramework class. Let's take a look at where that property is used and see if we really need it. If it isn't, let's remove it. Or if it's only needed in our .NET Framework builds, let's make it conditional, which would keep the problem from arising as new runtimes are released.
@manfred-brands I'm assigning this to you as requested. You should note that our longer-term goal is to replace the RuntimeFramework class with something new, based around FrameworkName. So if this particular fix gets too complicated, we should move on to replacement. However, if RuntimeFramework can be simplified first, replacement will then become a bit easier.