This repository has been archived by the owner on Jun 30, 2023. It is now read-only.
Don't force usage of a specific compiler toolset #58
Labels
enhancement
New feature or request
Comments
kzu
added
bug
kzu
added a commit
that referenced
this issue
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
added a commit
that referenced
this issue
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. Note that the preview job doesn't depend on the windows build, since it can use the ubuntu-built package just as well and that is typically much quicker to finish. Also, setting up net5.0 isn't needed on Windows agents anymore. 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
added a commit
that referenced
this issue
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. 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
added a commit
that referenced
this issue
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. 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
added a commit
that referenced
this issue
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. 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
added a commit
that referenced
this issue
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. 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
added a commit
that referenced
this issue
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. 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.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The quick and easy fix for #52 was to simply add a dependency on the one compiler toolset we compile our generator against. This isn't great as it prevents leveraging any new compiler features (i.e. during a VS preview). Moreover, this was completely opaque to the user, since it was just a dependency we pulled in, so they had no heads-up that we were changing the compiler for them.
A better approach is to instead support a range of compiler versions, while having an easy mechanism for adding more supported compiler versions down the road. Initial test should be (alongside an acceptance test) to install VS preview and ensure the acceptance tests still pass using the preview compiler included. Once the preview becomes stable, we can bump the version and be done.
A friendly error message should state clearly if a given compiler version is not supported and provide actionable suggestions on how to fix it, namely: install a compiler toolset that is compatible (suggest latest supported version) or turn off compile-time avatars entirely with
EnableCompileTimeAvatars=false.The text was updated successfully, but these errors were encountered: