-
Notifications
You must be signed in to change notification settings - Fork 793
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix regression in editing .NET Core scripts in devenv.exe #13994
Conversation
Note that this repairs .NET Framework-executing tooling analyzing .NET Core scripts. It does not repair the other way around (.NET Core-executing tooling analyzing .NET Framework scripts) I'd like to work out if that scenario matters @baronfel My understanding is that Ionide runs as .NET Core and always analyses scripts as .NET Core. @auduchinok What's the situation with Rider? Does it run as .NET Core or .NET Framework tooling? If .NET Core then do you support editing scripts with .NET Framework references? |
@dsyme FSAC actually still surfaces the option for .NET Framework checking, but I have no data on usage rates, especially because the FSI that we spawn in-editor is only ever .NET SDK-shipped (and therefore .NET Runtime, not Framework). Probably safe to deprecate on our part. |
@baronfel Looking at the previous code I think in-editor .NET Core tooling had always resolved So it won't be a change in behaviour (though would not be correct if we ever want .NET Core tooling to be able to analyze .NET Framework scripts) |
I've added tests to this |
@dsyme Thanks for asking about it! We've switched to .NET Core on Windows some time ago. I haven't done anything special to support the .NET Framework scripting yet, and there're some bug reports in the scripts area that I'm going to look into in 2022.3. They're mostly about choosing incorrect TFM and/or toolset which makes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry about that. This looks like a good fix.
Fixes #13993
The TFM we need to return from FxResolver is the correct TFM to use for script analysis (which is often the running TFM, but not always, in-editor). See notes in code
This resurrects a small portion of the code removed in #13993 (which removed lots of other ugly code, but this bit should not have been removed, and is the only technique we know of to get the target TFM based on an SDK dir)
@vzarytovskii I'll target this to dev17.4