enable deserialization of cached project file data and fix legacy project tests #139
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
baronfel
force-pushed
the
fix-project-cache-loading
branch
from
263cf0d to
6288d23
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR does two main things:
fsac.cachefiles in theobjdirectory of projects, andCache Loading
The core fix here was to mark the cache data structure as public, so that newtonsoft.json could serialize it and deserialize it again. When the type was internal, none of the fields were written into the cached structure. I also brought this under test for the first time. A slight fix was needed to the background loader logic to present a sensible chain of project-loading events to consumers.
Legacy project loading
The MSBuild found by VSWhere on my VS2022-installed windows host was skipped by the current logic, resulting in test failures on my machine. I think this is also the case for CI, where the hosts have VS2022 installed and run under .NET 6. I moved the probing logic to take the most recent VS instead of the least recent. @su8898 I would appreciate it if you could check this out and verify.