Update Proj-Info and solidify .net 6 support#825
Update Proj-Info and solidify .net 6 support#825baronfel wants to merge 19 commits intoionide:mainfrom
Conversation
| //TODO: does the backgroundservice ever get config updates? | ||
| do | ||
| let allowedVersionRange = | ||
| let maxVersion = System.Environment.Version.Major + 1 |
There was a problem hiding this comment.
this version range will be 5.something on .net 5 and 6.something on .net 6, so we should ensure that the SDK/Runtime we load for FSX is within that bound.
This still floats to the highest in that bracket, but we can very easily allow some user customization here and just change the way we create the Range.
| logQueueLength optsLogger (Log.setMessage "Getting NetCore options for script file {file}" >> Log.addContextDestructured "file" file) | ||
| let allFlags = Array.append [| "--targetprofile:netstandard" |] fsiAdditionalArguments | ||
| let! (opts, errors) = checker.GetProjectOptionsFromScript(UMX.untag file, source, assumeDotNetFramework = false, useSdkRefs = true, useFsiAuxLib = true, otherFlags = allFlags, userOpName = "getNetCoreScriptOptions") | ||
| optsLogger.trace (Log.setMessage "Got NetCore options {opts} for file {file} with errors {errors}" >> Log.addContextDestructured "file" file >> Log.addContextDestructured "opts" opts >> Log.addContextDestructured "errors" errors) |
There was a problem hiding this comment.
might revert this now that I've debugged enough to have confidence in this code path again
| let allModifications = replaceFrameworkRefs >> addLoadedFiles >> resolveRelativeFilePaths | ||
| return allModifications opts, errors | ||
| let modified = allModifications opts | ||
| optsLogger.trace (Log.setMessage "Replaced options to {opts}" >> Log.addContextDestructured "opts" opts) |
| sdkRoot <- Some directory | ||
| sdkVersion <- Environment.latest3xSdkVersion directory | ||
| runtimeVersion <- Environment.latest3xRuntimeVersion directory | ||
| //TODO(CH): should this range be user-assignable somehow? |
There was a problem hiding this comment.
similar point as in the background services: how should this be user-assignable?
| "Ionide WorkspaceLoader", WorkspaceLoader.Create | ||
| // These are commented out because of https://github.com/ionide/proj-info/issues/109 | ||
| // "MSBuild Project Graph WorkspaceLoader", WorkspaceLoaderViaProjectGraph.Create | ||
| "MSBuild Project Graph WorkspaceLoader", WorkspaceLoaderViaProjectGraph.Create |
There was a problem hiding this comment.
graph loader works in the new proj-info, so we can reenable it
|
Test hangs are due to a typeloadexception in the msbuild dlls. We're hitting a corner case in the test suite for some reason that not caught in a try-catch inside the loader loop in projinfo (which we should probably address in that library).
problem is:
Weirdly, the 6.0.1xx previews have the same assemblyversion. |
baronfel
force-pushed
the
udpate-proj-info
branch
from
e9d8010 to
02c07d7
Compare
|
Current status on this is that it works for .net 6 FSI scripts, but project loading has some kind of a hang - even on .net 5 now we start loading the project but it never completes. We need some additional logging/tracing here to have insight to what's happening in proj-info. Once that's resolved things should start lighting back up, I expect tests to be as green as they were before this change. The next hurdle will be .net 6 testing. We may initially do manual testing on .net 6 SDKs just to get it out of the door, but we'll need .net capable FAKE runners or a pivot to .net 6 build projects in order to run the tests in a .net 6 target to keep that verification active in the future. |
baronfel
force-pushed
the
udpate-proj-info
branch
from
c94422a to
02c07d7
Compare
baronfel
force-pushed
the
udpate-proj-info
branch
from
02c07d7 to
1c01b09
Compare
|
@Krzysztof-Cieslak did some additional debugging and for some reason (for local usage) project cracking is loading an 15.x msbuild dll, which of course isn't resolvable in the SDK directory we're pinned to because those are 16.x. Where does this come from? no one knows. FSharpLint and FCS itself have 16.x msbuild dependencies, but this 15.x dependency can't be found easily by either of us. Might need to dip into binlogs to trace where it's coming from. |
|
closing in favor of #846 |
2 participants
No description provided.