Skip to content

Conversation

@rainersigwald
Copy link
Member

@rainersigwald rainersigwald commented Oct 13, 2021

These assemblies have moved and versioned in Visual Studio 2022.

Update of the workaround for #1675 in #4139.

Fixes #6952

Work item (Internal use): AB#1420314

Summary

As a workaround for an assembly load issue, these assemblies must have an explicit codebase in MSBuild.

Customer Impact

Builds that run C++ code analysis can fail with MSBuild internal errors.

Regression?

Yes, against 16.x which had the correct codeBase for C++ code analysis assemblies.

Testing

Manual testing against repro project from #1675.

Risk

Low. Changes a codebase for an assembly version that should never be referenced to point to the version and location of the extant assembly.

We could further reduce risk by leaving the 16.0.0.0 codeBase entry if that's desired; I don't think it's necessary and I don't know how that assembly could ever get in place in VS2022.

These assemblies have moved and versioned in Visual Studio 2022.

Update of the workaround for dotnet#1675 in dotnet#4139.
@rainersigwald rainersigwald added this to the MSBuild 17.0 milestone Oct 13, 2021
@rainersigwald
Copy link
Member Author

@mavasani this is a new iteration of #4139/#1699. You still a good person to review?

Copy link
Contributor

@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 looked through for other instances of 16.0 anywhere and found three examples that we might consider changing:
global.json and MSBuild.sln suggest we should use VS 16.0. I don't think that should hurt, but we may as well update at some point.
eng\CodeAnalysis.ruleset specifies ToolsVersion="16.0". Also doesn't sound like a critical fix.

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.

5 participants