You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@CharliePoole The method RuntimeFrameworkServices.GetBestAvailableFramework doesn't seem to be called. Can it be deleted?
If so them all but one usage of the ClrVersion property can then be removed.
That only leaves: string monoOptions = "--runtime=v" + TargetRuntime.ClrVersion.ToString(3);
@manfred-brands Yes, if it's not called... if you only verified that using GitHub, double check when you are working in the project as GitHub seems to occasionally miss references.
As for launching under mono with monoOptions, it depends whether you have mono installed in order to test. You could put something inline or just not specify the particular framework at all and see if it will run.
However, I think we may need to do a separate "get mono working" issue once the engine is reorganized as we want it. Mono is much less important than it once was but some people still need it. If you can't do something under mono, I'd favor temporarily commenting out the part of the code, which runs under mono and adding a TODO and maybe a new issue.
Use your judgement as to how much work you want to put into this one, 'cause there's lots more to do. :-)
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.
The text was updated successfully, but these errors were encountered: