Skip to content
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 loading of rollback installed workloads in Visual Studio #39901

Merged
merged 1 commit into from
Apr 1, 2024

Conversation

marcpopMSFT
Copy link
Member

@marcpopMSFT marcpopMSFT commented Mar 29, 2024

Description

With PR #37681 , we introduced a new code path that will load System.Text.Json in framework and core versions of the .NET SDK. This code path triggers when installing SDK workloads using rollback files. While this scenario is not broadly documented, it is the default for all dogfooders of Aspire workloads as a script is used to install specific versions of the workloads.

We don't reference S.T.J in the framework version of the msbuildsdkresolver. However, it transitively pulls in a 7.0 version of that package through another dependency. Because of transitive pinning, this gets hoisted to version 8.0.2 which VS does not have.

This is fine in the .net core SDK but breaks VS.

Customer Impact

Any customer installing workloads from a rollback file will have their workload templates be broken and get errors when doing file new on any project.

https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2013426

Regression

Yes,

Risk

Low - we have similar pinned package versions in other framework assemblies for this specific reason.

Testing

Jose tested manually copying the newly built files over the old ones that he was unblocked with no errors and valid templates showing up.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Infrastructure untriaged Request triage from a team member labels Mar 29, 2024
@v-wuzhai
Copy link
Member

v-wuzhai commented Apr 1, 2024

/azp run

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@Forgind Forgind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine VS's version is being updated on a regular basis, in which case this presumably also needs to be updated? If so, would it be better to make this a variable and have it auto-updated somewhere? Or is it ok because VS has a wide binding redirect catching 0.0.0.0-(current) and redirecting it properly? In the latter case, maybe add a comment?

@marcpopMSFT marcpopMSFT added Servicing-consider and removed untriaged Request triage from a team member labels Apr 1, 2024
@marcpopMSFT marcpopMSFT changed the title Pin to 8.0.0 in framework builds for two components loading in VS Fix loading of rollback installed workloads in Visual Studio Apr 1, 2024
@marcpopMSFT
Copy link
Member Author

I imagine VS's version is being updated on a regular basis, in which case this presumably also needs to be updated? If so, would it be better to make this a variable and have it auto-updated somewhere? Or is it ok because VS has a wide binding redirect catching 0.0.0.0-(current) and redirecting it properly? In the latter case, maybe add a comment?

They control the version they have installed and load and would update their own binding redirect. Us compiling against the lowest version in framework allows us to permit any 8.0 version (basically, it's using the package as a reference assembly at that point)

@marcpopMSFT marcpopMSFT merged commit d297c38 into release/8.0.3xx Apr 1, 2024
16 checks passed
@marcpopMSFT marcpopMSFT deleted the marcpopMSFT-STJversion branch April 1, 2024 20:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants