-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SG dependencies section #28054
Add SG dependencies section #28054
Conversation
<Target Name="GetDependencyTargetPaths"> | ||
<ItemGroup> | ||
<!-- Do this for every package you reference. The "PKG" prefix remains the same, while any periods in package name are replaced with underscores --> | ||
<TargetPathWithTargetPlatformMoniker Include="$(PKGThePackageYouReference)\lib\netstandard2.0\ThePackageYouReference.dll" IncludeRuntimeDependency="false" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❗ This won't work due to the way Roslyn's assembly loader works. All assemblies must be located in the same folder on disk in order for them to be usable. Naturally, the easiest location ends up being $(OutputPath)
, like this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sharwell Does this mean the source generator sample I quoted the code from is incorrect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sharwell btw, the sdk itself uses the directory as the source generator sample:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean the source generator sample I quoted the code from is incorrect?
Likely yes. @genlu where is the issue filed where people noticed the behavior change when we restricted assembly load locations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the sdk itself uses the directory as the source generator sample
I believe this source generator is special and doesn't run in the same way as others. It might not be impacted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think our current samples are correct here
@jmarolf The line you linked is almost the same as the sample. Sorry noticed it's totally different. I was initially paying attention to the path only. Any advantage for this approach over this one?
I'll add a note about the netstandard2.0
requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sharwell I tested now. The OutputPath
approach didn't work while the other worked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean the source generator sample I quoted the code from is incorrect?
Likely yes. @genlu where is the issue filed where people noticed the behavior change when we restricted assembly load locations?
@sharwell In case you'd still like a link to the issue, I believe it's dotnet/roslyn#56442 🙂
I'm closing this as very stale. It's been more than 2 years since the last comment, and there are now conflicts. If you want to reopen the PR, address the conflicts and the comments, we'll take another look. |
@sharwell @jmarolf can someone review? Thanks!