❔ ✅ `System.Runtime` Assembly missing in `CSharpCompilation` when using referenced Attribute
Heya!
I've been playing around with testing source generators and I ran into an odd issue when getting the
SymbolInfo
of an Attribute that is part of a referenced assembly. I have both the assembly and the Syste.Runtime
assembly referenced in the CSharpCompilation
which the generator driver is using.
What's the issue?
When calling <SemanticModel>.GetSymbolInfo(<AttributeSyntax>).Symbol
I would expect it to return the attribute symbol for the attribute from the referenced assembly. Instead, I get null
. I have a minimal reproducible example here: https://github.com/StrawbrryFlurry/CSharpCompilationAttributeReference, which shows this behavior.
I've tried to investigate this a little further, following the GetSymbolInfo
call leading me to this line:
https://github.com/dotnet/roslyn/blob/72e0a39fe59cd242dbf441df1f8beae694c8f068/src/Compilers/CSharp/Portable/Compilation/PublicSemanticModel.cs#L20-L21
where attributeType
is an ExtendedErrorTypeSymbol
, that is able to resolve the namespace of the attribute in the referenced assembly (ReferenceLibrary.ReferencedAttribute
) with the error:
error CS0012: The type 'Attribute' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Would anyone happen to know how I can fix this? Am I not referencing the System.Runtime
Assembly correctly? I'd greatly appreciate any pointing in the right direction GitHub
roslyn/src/Compilers/CSharp/Portable/Compilation/PublicSemanticMode...
The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs. - dotnet/roslyn
25 Replies
You said you were messing around with source generators, so let me start by asking what the end goal here is
Because it sounds like you're barking up the wrong tree entirely 🙂
To fix your specific example, don't try to manually create your framework references like https://github.com/StrawbrryFlurry/CSharpCompilationAttributeReference/blob/master/SourceGeneratorIssueExample/SourceGeneratorIssueExample.Tests/CSharpCompilationExampleTest.cs#L27. That's just going to lead you into pain
GitHub
GitHub - jaredpar/basic-reference-assemblies: Produce NuPkg files t...
Produce NuPkg files that have .NET Reference assemblies as resources - GitHub - jaredpar/basic-reference-assemblies: Produce NuPkg files that have .NET Reference assemblies as resources
But for source generators, I wouldn't expect you to call
GetSymbolInfo
on any attributes at all, so let's also talk about that 🙂Hi Fred,
Thanks for the quick reply! It could very well be that I'm doing something completely wrong here, I was just lead here by something else I've been working on, and that seemed like a sensible way to go about it..
I get the full name name (e.g. without namespace or anything if specified) to compare against the actual type - I know this is prolly not the most efficient way, but it's what I was going with to start off :P I use it like this:
https://github.com/StrawbrryFlurry/mumei/blob/7c0cb2ffac9e77c9f80b079f0e3abf5fc10bf56c/src/Mumei.Roslyn/Extensions/MemberDeclarationSymbolExtensions.cs#L18C8-L18C8
Here:
https://github.com/StrawbrryFlurry/mumei/blob/7c0cb2ffac9e77c9f80b079f0e3abf5fc10bf56c/src/Mumei.DependencyInjection.Roslyn/ModuleMumeiGenerator.cs#L33
Note that this is all still very very much WIP ^^"
The idea is that you can run a test on the source generator with a relatively simple fluid interface like this:
https://github.com/StrawbrryFlurry/mumei/blob/7c0cb2ffac9e77c9f80b079f0e3abf5fc10bf56c/test/Mumei.DependencyInjection.Roslyn.Tests/MumeiModuleGenerator.cs#L37
SymbolInfo
from an attribute in order to get it's SourceGeneratorTest
is here https://github.com/StrawbrryFlurry/mumei/blob/7c0cb2ffac9e77c9f80b079f0e3abf5fc10bf56c/test/Mumei.Roslyn.Testing/SourceGeneratorTest.csI'm really not understanding the purpose of that
HasAttribute
extension
In source generation testing, you typically want to verify file content and compile errors (or lack thereof)
I'm not sure what HasAttribute
would be useful for in that loopOh, yeah - that is not for the assertions in the test, but the source generator itself. I run into the "issue" when running the generator in a test, using this setup
Ok, if it's for the source generator itself, you're probably doing something wrong 🙂
You should be using
ForAttributeWithMetadataName
to find all syntax tagged with your attribute
Oh no, you're still on ISourceGenerator
Please tell me this isn't unityNo, I'm trying to build Incremental Generators.. there might be an old source generator lying around somewhere :P
https://github.com/StrawbrryFlurry/mumei/blob/7c0cb2ffac9e77c9f80b079f0e3abf5fc10bf56c/src/Mumei.Roslyn/SourceGeneration/TestSourceGenerator.cs is the one in the same project as that helper you linked
GitHub
mumei/src/Mumei.Roslyn/SourceGeneration/TestSourceGenerator.cs at 7...
🦉 [WIP] Your Owl Pal For Writing Source Generators - StrawbrryFlurry/mumei
Yeah that's just a silly think I've toyed around with - will be thrown out / smashed into an incremental generator at some point
I would also highly recommend deleting your reflection adapters and never looking at them again
<:shy_hide:809861272036311100>
The runtime did something similar for a generator and it causes them nothing but pain
I see.. I thought it would be a neat way of inter opting other parts of the code base that work with "regular types" ^^"
Reflection and type symbols do not work in the same way and attempting to bridge those gaps is going to result in pain for you
Most recent example I was pulled into: the runtime's generator needed to be able to know whether something was
required
. Roslyn's symbol API has this information. Reflection doesn't (or didn't, not sure if they added that info)
A naive adaption will differ from the behavior you'd get at runtime regardlessRight, there already were some hiccups when implementing some of the parts I already have for those.. I do (as of now at least) only really use the name, namespace and some other trivial information that should be part of either of the APIs.. though it'd prolly be smart to re-think if doing that is worth it
Thank you for mentioning this! It must have skipped past me and is definitely a better way of going about this then what I was doing
Literally several orders of magnitude faster
Haha, I can imagine that ^^"
For future questions, #roslyn exists, and is checked by more people at more hours of the day 🙂
Will remember that, thanks a lot, Fred!
yw. Feel free to $close the thread if there's nothing else
Use the /close command to mark a forum thread as answered
$close
Use the /close command to mark a forum thread as answered
Was this issue resolved? If so, run
/close
- otherwise I will mark this as stale and this post will be archived until there is new activity.