Skip to content

Conversation

@safern
Copy link
Member

@safern safern commented Mar 4, 2021

The reason why this was failing is because the old MSBuild locator was resolving the newest SDK regardless of the runtime that the tool was running on. This: microsoft/MSBuildLocator#92 fixed that issue and only returns SDKs that are same or earlier than the runtime the tool is running on.

cc: @carlossanlop

@carlossanlop carlossanlop linked an issue Mar 4, 2021 that may be closed by this pull request
@carlossanlop
Copy link
Contributor

carlossanlop commented Mar 4, 2021

@ericstj mentioned in #36 (comment) that a workaround is to target net6.0 in the tool. @safern Should we also add Eric's suggested change?

I can address that separately. I'll merge this.

@carlossanlop carlossanlop merged commit e9446bc into dotnet:master Mar 4, 2021
@ericstj
Copy link
Member

ericstj commented Mar 4, 2021

Are you sure it'll be safe to analyze projects which require a newer SDK / MSBuild using an older one? What if those projects use features only available in the newer MSBuild/SDK?

@safern safern deleted the UpdateLocator branch March 4, 2021 17:04
@safern
Copy link
Member Author

safern commented Mar 4, 2021

Are you sure it'll be safe to analyze projects which require a newer SDK / MSBuild using an older one? What if those projects use features only available in the newer MSBuild/SDK?

Yeah that is a good point. I think we should update the Roslyn we are using and target the tool to 6.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Some users report the csproj files are not getting loaded

3 participants