This repository has been archived by the owner on Jun 30, 2023. It is now read-only.
Source generator fails when used in Visual Studio preview #52
Labels
bug
Something isn't working
Comments
kzu
added a commit
that referenced
this issue
Dec 17, 2020
Given that we pack and depend on some workspace APIs to perform some parts of the code generation, we need the compiler and our workspace dependencies to align. This is trivial to achieve by depending on the toolset that matches our Roslyn version. This would not be required if we removed all dependencies on workspace APIs. Fixes #52
kzu
added a commit
that referenced
this issue
Dec 17, 2020
Given that we pack and depend on some workspace APIs to perform some parts of the code generation, we need the compiler and our workspace dependencies to align. This is trivial to achieve by depending on the toolset that matches our Roslyn version. This would not be required if we removed all dependencies on workspace APIs. Fixes #52
kzu
added a commit
that referenced
this issue
Dec 18, 2020
If the target framework/dependency group doesn't match the one for the other dependencies, its .props is never imported by nuget. Fixes #52
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.
Describe the Bug
If the compiler in use doesn't match the source generator dependencies, code generation fails.
Steps to Reproduce
Install VS preview, install Avatar nuget on a project. Compiler issues a warning like:
This later fails at run-time because the expected avatar types aren't present in the assembly.
Expected Behavior
Things should Just Work :)
The text was updated successfully, but these errors were encountered: