Skip to content
This repository has been archived by the owner on Jun 30, 2023. It is now read-only.

⚙ Support multiple compiler toolsets #59

Merged
merged 1 commit into from
Dec 18, 2020
Merged

⚙ Support multiple compiler toolsets #59

merged 1 commit into from
Dec 18, 2020

Conversation

kzu
Copy link
Member

@kzu kzu commented Dec 18, 2020

Due to our usage of code fixes and refactorings, we have a (non-public) dependency from the source generator (only used for compile-time avatars in supported configurations, namely C# 9+) to the roslyn workspace API. This dependency doesn't work if at least (so far) major.minor version of Roslyn don't match between the compiler and our generator+deps.

Rather than forcedly switching the compiler in use (like fix for #52 did), we instead make it easy to support multiple toolsets. The goal is to keep at any one time only the publicly supported .NET/VS versions so that our package size doesn't grow too much.

The packaging project was updated to include a new (3.9.0-2.final based) supported toolset for users running VS preview at the time of this commit. An acceptance test verifies the combination against latest VS Preview, so we get early warnings for newer VS preview versions that render our generator incompatible.

In the future, we should explore removing the dependency on workspace, but it's non-trivial amount of work given we'd need to do essentially the same as Override All Members does in VS as well as "Implement Interface/Abstract Class", plus "generate constructors".

Fixes #58.

@kzu kzu added the enhancement New feature or request label Dec 18, 2020
@kzu kzu force-pushed the toolsets branch 4 times, most recently from 61a3522 to 496f4bd Compare December 18, 2020 22:35
Due to our usage of code fixes and refactorings, we have a (non-public) dependency from the source generator (only used for compile-time avatars in supported configurations, namely C# 9+) to the roslyn workspace API. This dependency doesn't work if at least (so far) major.minor version of Roslyn don't match between the compiler and our generator+deps.

Rather than forcedly switching the compiler in use (like fix for #52 did), we instead make it easy to support multiple toolsets. The goal is to keep at any one time only the publicly supported .NET/VS versions so that our package size doesn't grow too much.

The packaging project was updated to include a new (3.9.0-2.final based) supported toolset for users running VS preview at the time of this commit. An acceptance test verifies the combination against latest VS Preview, so we get early warnings for newer VS preview versions that render our generator incompatible.

The analyzer (containing the source generator) we add dynamically are now also annotated just like the nuget-provided ones, for more transparency and in case the `NuGetPackageId` and `NuGetPackageVersion` attributes are later on used for something we don't expect, for future compatibility. As a side benefit, users can now use `$(AvatarVersion)` to inspect the version of the dependency too :).

In the future, we should explore removing the dependency on workspace, but it's non-trivial amount of work given we'd need to do essentially the same as Override All Members does in VS as well as "Implement Interface/Abstract Class", plus "generate constructors".

Fixes #58.
@kzu kzu merged commit d2e7c0c into main Dec 18, 2020
@kzu kzu deleted the toolsets branch December 18, 2020 23:33
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't force usage of a specific compiler toolset
1 participant