-
|
How do I reference a local project from a Source Generator project. The project is also used from normal .Net projects so cannot be marked as an Analyzer. I tried adding a normal project reference: But I get the following error when trying to use the Source Generator: I tried marking it's output type as Analyzer in the project reference OutputItemType as follows: But this had exactly the same problem. All the projects have: The anaylizer is: and the referenced project is: |
Beta Was this translation helpful? Give feedback.
Replies: 15 comments 59 replies
-
|
From the discussions on gitter both @canton7 and @YairHalberstadt have had this problem. Both @canton7 and I are currently working around this by linking in the .cs files we need, but this is a far from ideal solution. |
Beta Was this translation helpful? Give feedback.
-
|
To clarify: I went straight for linking in the cs files I needed, and didn't attempt to do what you're doing. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if this restriction applies to package references as well, if so that means you can't use code from a nuget package unless that package was specifically built as an Analyzer |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
@trampster are you able to see the source generator dependency in the Analyzers node in solution explorer when you add a NuGet package reference to your source generator NuGet package? |
Beta Was this translation helpful? Give feedback.
-
|
No, I'm on vscode for linux |
Beta Was this translation helpful? Give feedback.
-
That is correct, analyzers and source generator can only dependency that is itself marked as an analyzer. This is required to ensure proper execution in presence of shadow copying. We had considered a special AnalyzerDependecy item type, but that did not give us much compared to just reusing Analyzer item type for dependencies. |
Beta Was this translation helpful? Give feedback.
-
|
"but that did not give us much" What about the ability to use any of the many useful nuget packages that are not analyzers. Which is nearly all of them. This severely limits the size and complexity of a Source Generators, without this you can't scale them, because you have to reimplement everything yourself instead of using off the shelf nuget packages. |
Beta Was this translation helpful? Give feedback.
-
|
Tagging @jmarolf @sharwell |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
And @jmarolf might also know if we have a bug tracking a better experience here. Ideally we'd have flag in your analyzer/generator producing project that does all of this magically for you. |
Beta Was this translation helpful? Give feedback.
-
|
I've filed an issue in the MSBuild repo for making an analyzer's NuGet packages be automatically included. See dotnet/msbuild#7640 Is MSBuild the correct repo for this, or would this be better filed in the Roslyn repo? |
Beta Was this translation helpful? Give feedback.
-
|
You can add a dependency to a source generator in the same solution through three steps:
You can see an example of these steps here:
Note that the source generator must target netstandard2.0, and the dependencies must target netstandard 2.0 or netstandard1.x. See #47087. |
Beta Was this translation helpful? Give feedback.
-
|
@trungnt2910 Can you elaborate? 🙂 Here's how we use ExampleProject.csproj: <Project Sdk="Microsoft.NET.Sdk.Web">
...
<ItemGroup>
<ProjectReference Include="..\CodeGenerators\ExampleGenerator\ExampleGenerator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
<ProjectReference Include="..\CodeGenerators\GeneratorCommon\GeneratorCommon.csproj" OutputItemType="Analyzer" />
</ItemGroup>
</Project>ExampleGenerator.csproj: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<LangVersion>8.0</LangVersion>
<IsRoslynComponent>true</IsRoslynComponent>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\GeneratorCommon\GeneratorCommon.csproj" />
</ItemGroup>
</Project>GeneratorCommon.csproj: <Project Sdk="Microsoft.NET.Sdk">
// Nothing special. Note that we don't define <IsRoslynComponent>true</IsRoslynComponent> for this project, since it's a shared library that's consumed by ExampleGenerator
</Project> |
Beta Was this translation helpful? Give feedback.
-
|
What I had was: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net$(_BrowserNetVersion)</TargetFramework>
<Nullable>enable</Nullable>
<LangVersion>latest</LangVersion>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
<IsTrimmable>true</IsTrimmable>
<!-- Ignore those spam warnings to filter out the real problems -->
<!-- No matching param tag in XML comment; Cref attribute cannot be resolved; Referenced assembly does not have a strong name -->
<NoWarn>CS1573;CS1574;CS8002</NoWarn>
<!--
Microsoft.DotNet.SharedFramework.Sdk requires our framework assemblies to be signed
(to have a "public key token")
-->
<SignAssembly>True</SignAssembly>
<AssemblyOriginatorKeyFile>$(_BrowserRootDirectory)/DotnetBrowser.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>
<!-- Unrelated items -->
<ItemGroup>
<ProjectReference Include="..\Trungnt2910.Browser.Generators.TypeScript\Trungnt2910.Browser.Generators.TypeScript.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
</ItemGroup>
<!-- Unrelated items -->
<Import Project="..\Trungnt2910.Browser.Generators.TypeScript\Trungnt2910.Browser.Generators.TypeScript.props" />
</Project><Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Nullable>enable</Nullable>
<LangVersion>latest</LangVersion>
<ImplicitUsings>true</ImplicitUsings>
<DefineConstants>NOGOBIE</DefineConstants>
<!-- Won't work -->
<!--<IsRoslynComponent>true</IsRoslynComponent>-->
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.3" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.2.0" PrivateAssets="all" />
<PackageReference Include="TypeScriptAST" Version="1.0.2" NoWarn="NU1701" GeneratePathProperty="true" PrivateAssets="all" />
</ItemGroup>
<ItemGroup>
<Compile Include="../Trungnt2910.Browser/Generators/JsObjectGenerator.cs" />
</ItemGroup>
<ItemGroup>
<None Include="$(OutputPath)\$(AssemblyName).dll" Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />
<None Include="$(PKGTypeScriptAST)\lib\net452\*.dll" Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />
<None Include="Trungnt2910.Browser.Generators.TypeScript.props" Pack="true" PackagePath="build" Visible="false" />
</ItemGroup>
<PropertyGroup>
<GetTargetPathDependsOn>$(GetTargetPathDependsOn);GetDependencyTargetPaths</GetTargetPathDependsOn>
</PropertyGroup>
<Target Name="GetDependencyTargetPaths">
<ItemGroup>
<TargetPathWithTargetPlatformMoniker Include="$(PKGTypeScriptAST)\lib\net452\TypeScriptAST.dll" IncludeRuntimeDependency="false" />
</ItemGroup>
</Target>
</Project>The major difference between my project and yours is that I used an external reference through a NuGet I am aware that I'm doing some bad practice by referencing a legacy |
Beta Was this translation helpful? Give feedback.
-
|
Carefully reading this discussion's title I can see that it explicitly states "local projects", but I came here through a link from another issue. |
Beta Was this translation helpful? Give feedback.
-
|
@trungnt2910 Ah, yes, I think that if you want to debug the source generator, you probably need to reference it as a local project, rather than a NuGet package (although there might be another way that I'm not aware of 🙂) |
Beta Was this translation helpful? Give feedback.
-
|
A workaround that works fine for me is to do whatever I'm doing for my source generator, and then add another dummy source generator that does not have any external dependencies. When I debug the dummy source generator, breakpoints for the first generator still hit. |
Beta Was this translation helpful? Give feedback.
-
|
I had a situation alike in some regards. I have a source generator with a project reference to a utility lib. The utility lib is used in a VSIX extenstion and in a source generator in webapi project. To make this work i had to reference both the utility project and the source generator project as analyser references in the webapi project, and everything works. Now the source generator project picks up the util project without errors. |
Beta Was this translation helpful? Give feedback.
-
|
This was the problem for me. Seems quite annoying that a simple project reference to the generator is not sufficient? Certainly confusing when trying to reference it from other CS Projects. Probably Relevant is this issue |
Beta Was this translation helpful? Give feedback.
-
|
with System.Text.Json 6.0.0 when running this this never fail when doing dotnet build but visual studio 2022 fail to build... |
Beta Was this translation helpful? Give feedback.
-
|
I have experience similar behavior in Visual Studio, not just Give a try restarting VS. No ideal. |
Beta Was this translation helpful? Give feedback.
-
|
Is your generator project targetting netstandard2.0? |
Beta Was this translation helpful? Give feedback.
-
|
yes and it works fine with System.Text.Json 5 as long as I have |
Beta Was this translation helpful? Give feedback.
-
|
I've just started experimenting with source generators, and as soon as I've began doing interesting stuff, that is, referencing useful packages, everything fell down and I wasted several hours until I found this discussion. I understand what @mavasani said here, but I agree with @thomaslevesque here. Developers will expect similar behavior compared to other projects, and not being able to reference projects and packages seamlessly severely waters down the usefulness of source generators. Furthermore, this was probably known by microsoft since the very beginning, and it should have been explained and pointed in all the introductions I've read, to prevent countless developers wasting their time I was planning to do some stuff with source generators based on the expectations I had... but seeing the state of things, to me it's clearly a no go. Maybe next time. |
Beta Was this translation helpful? Give feedback.
-
|
I completely agree. I spent many hours trying to reference nuget packages and got nowhere. This is such a painful experience and incredibly frustrating. I was hoping to introduce source generators in our code at work, but I will not be bothering until there is a smoother developer experience. |
Beta Was this translation helpful? Give feedback.
-
|
Same here, the manual mangling with numerous options to fix |
Beta Was this translation helpful? Give feedback.
-
|
I've found this useful link about writing practical source generators, which also covers the transient project dependencies in full. I'm still not touching source generators until dotnet provides a simple way of adding the dependencies, but I provide the link for those that might find it useful: https://turnerj.com/blog/the-pain-points-of-csharp-source-generators |
Beta Was this translation helpful? Give feedback.
-
|
The only thing that worked for me was this: <PropertyGroup>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup> |
Beta Was this translation helpful? Give feedback.
-
|
I know this thread already has an answer for package references, but for some scenarios, you would still want to add a reference to a local project with ProjectReference. This is enough if you add your Source Generator as a NuGet package. But if you are going to reference your Source Gerantor as a project reference we should add these too: And: After these steps, you don't need to add anything else to the target project except the Source Generator itself |
Beta Was this translation helpful? Give feedback.
-
|
I just want to emphasise that I believe this is the best solution for Another side note is that, if you reference the SourceGenerator project in e.g. a test project, you might want to add @farid-fereidooni thanks for sharing! |
Beta Was this translation helpful? Give feedback.
-
|
@adampaquette @devantler |
Beta Was this translation helpful? Give feedback.
-
|
I don't really know why this answer is not considered the best one that covers the initial question completely. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, Farid! It helped me to extract a code generation logic to a new proj and create a reference to that one in the original source generator. |
Beta Was this translation helpful? Give feedback.
-
|
At first I thought you cited a chapter from Shakespeare 😝 It's been three years... maybe time for Microsoft to provide us with an elegant solution? |
Beta Was this translation helpful? Give feedback.
-
|
Nothing from this thread worked for me. Interestingly enough only incremental generator failed work. Only way I found to fix it is adding missing dll in consuming project as ANALYZER: |
Beta Was this translation helpful? Give feedback.
-
|
May anyone tell me whether there is any pattern that this PKG variable has to be set with ? $(PKGNewtonsoft_Json) What value shall be set e.g for following: I've tried with following: $(PKGSwashbuckle_AspNetCore_Annotations) (complete example below) does it even matter? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the naming matters 🙂 Here's a complete example from one of our projects: <ItemGroup>
<PackageReference Include="Microsoft.OpenApi" Version="1.2.3" GeneratePathProperty="true" PrivateAssets="all" />
<PackageReference Include="Microsoft.OpenApi.Readers" Version="1.2.3" GeneratePathProperty="true" PrivateAssets="all" />
<PackageReference Include="SharpYaml" Version="1.6.6" GeneratePathProperty="true" PrivateAssets="all" />
</ItemGroup>
<!-- See https://github.com/dotnet/roslyn-sdk/blob/0313c80ed950ac4f4eef11bb2e1c6d1009b328c4/samples/CSharp/SourceGenerators/SourceGeneratorSamples/SourceGeneratorSamples.csproj#L13-L30
and https://github.com/dotnet/roslyn/discussions/47517#discussioncomment-64145 -->
<PropertyGroup>
<GetTargetPathDependsOn>$(GetTargetPathDependsOn);GetDependencyTargetPaths</GetTargetPathDependsOn>
</PropertyGroup>
<Target Name="GetDependencyTargetPaths">
<ItemGroup>
<TargetPathWithTargetPlatformMoniker Include="$(PKGMicrosoft_OpenApi)\lib\netstandard2.0\Microsoft.OpenApi.dll" IncludeRuntimeDependency="false" />
<TargetPathWithTargetPlatformMoniker Include="$(PKGMicrosoft_OpenApi_Readers)\lib\netstandard2.0\Microsoft.OpenApi.Readers.dll" IncludeRuntimeDependency="false" />
<TargetPathWithTargetPlatformMoniker Include="$(PKGSharpYaml)\lib\netstandard2.0\SharpYaml.dll" IncludeRuntimeDependency="false" />
</ItemGroup>
</Target> |
Beta Was this translation helpful? Give feedback.
-
|
Any hope of getting a proper fix for this? The solutions suggested here haven't worked for me and just seem like workarounds. Ideally, adding dependencies into a source generator would "just work". |
Beta Was this translation helpful? Give feedback.
-
|
Well, adding the project as a dependency to resolve at runtime worked for a little bit, but now it doesn't work anymore for some reason. (???) I'm getting errors that it can't be found, hopefully this is just a minor oversight on my end. |
Beta Was this translation helpful? Give feedback.
-
It looks like you are on the right track. Maybe you can use my solution for reference to find your issue: Devantler.DataMesh.DataProduct.Generator/Devantler.DataMesh.DataProduct.Generator.csproj It works for both local and nuget references and shows my approach for both. I fiddled around with it a lot to find the minimal viable solution, so I believe what I do here is the absolute minimum you need to do to reference dependencies in source generators. I use Hope it helps! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, switching to your approach for Unfortunately, I haven't been able to find any notable differences between your project and mine, though, other than that yours is in netstandard2.1 while mine is still netstandard2.0. Specifically, I have the following situation in a big solution:
This had been working for a bit earlier today, but I must have done a clean or rebuild or something where it now just doesn't want to work anymore. I've run countless cleans, rebuilds, and cleared all of the bin/obj directories in my solution but nothing has worked. It consistently throws the above error when trying to run my program. ...in Visual Studio, at least. When I try to run it as a standalone executable, it works just fine. So it seems like this might be a Visual Studio issue? I'll try recloning my project from GitHub and see if that changes anything. Edit: Unfortunately it didn't help. I think I'll just revert these changes again and table this for now. |
Beta Was this translation helpful? Give feedback.
-
|
Something I experienced with the little work I did with generators is that Visual Studio loads the generator into its contexts, and once loaded, it cannot unload it. That means that changes that happen in the code afterwards are not reflected in the behavior of the generator. In fact, the safest way I found to test changes in the generator's code is to exit Visual Studio and reopen it again, which triggers compiling and loading the latest changes into the context. |
Beta Was this translation helpful? Give feedback.
-
|
Very helpful, and still relevant as of November 2023. To aid discovery, I searched for "unable to use local project reference in source generator C#" and eventually found my way here. Thanks for sharing, @MeltyPlayer |
Beta Was this translation helpful? Give feedback.
and others
You can add a dependency to a source generator in the same solution through three steps:
<PackageReference>, making sure to set bothGeneratePathProperty="true"andPrivateAssets="all"<TargetPathWithTargetPlatformMoniker>elements as part ofGetTargetPath, and add all the required dependency assemblies inside this target, making sure to setIncludeRuntimeDependency="false"<GetTargetPathDependsOn>to ensure the target from the previous step is usedYou can see an example of these steps here:
https://github.com/dotnet/roslyn-sdk/blob/0313c80ed950ac4f4eef11bb2e1c6d1009b328c4/samples/CSharp/SourceGenerators/SourceGeneratorSamples/SourceGeneratorSampl…