Source Generators Not Generating Sources #49249
Comments
Dotnet-GitSync-Bot
added
Area-Compilers
untriaged
Source generators must target netstandard2.0. |
|
@jasonmalinowski @chsienki this seems like a case where the wrong error is getting reported for an incorrectly targeted source generator. |
sharwell
added
Bug
Feature - Source Generators
|
The project has been updated to use netstandard2.0 and the error is gone; however, the generated source does not appear to be able, nor do I see it in the obj/bin folders (when I used net5.0 I saw the generated file in the obj folder). |
|
I did more testing last night, and it appears that the sources are being generated (basically). Changes or new sources are not available until closing and reopening Visual Studio. Once restarted, I have access to the generated source like in all the samples. I can [control]-[click] on it and it takes me to the generated source and I can see it even after making a change to the generator, it appears to update (most of the time, it is not reliable). That being said, it still requires me to relaunch Visual Studio to use the latest source. Example Experience/ScenarioI have a generator that makes a class SampleClass with a static method SampleMethod() and all it does is Debug.WriteLine("test"); It never shows up in Visual Studio but I can tell it generates cause I will see issues in the output window. I have to clean the solution and build the project, close and reopen Visual Studio, and most of the time, the code is available. Now, I can use it in my project. All basically well. I decide to change the text "test" to "something else". I cannot tell if it worked or not, but clean and build again just in case (I have also tried skipping this step with the same results). When I [control]-[click] on the method where I use it, it shows the change, but when I run the code, it has not changed; however, when I restart Visual Studio it works just fine (the change is realized). |
So we outright blocked things targeting the .NET Framework; @chsienki I believe the block doesn't block .NET Core referencing ones, albeit it won't really work in VS for Windows?
The experience is a bit rougher there, but as long as you have the latest C# Extension installed you should have basics working fine.
Yeah, the one limitation we have in VS due to .NET limitations is once we've loaded your generator into our process, we don't have a way to unload it at this point. #48083 is another example of that too. |
|
Experiencing the same problem. The source generator is definitely executed (verified with Visual Studio: Version 16.8.3 |
|
+1 I am also unable to generate any content after upgrading to latest visual studio. |
@jasonmalinowski Will support for projects targeting .net 5 be coming in the future? |
|
@mstancombe just to make it clear (since your question can be read two ways), a generator can run in a project targeting any framework. The generator itself must target netstandard2.0. The problem with moving that forward is generators today run in places that aren't .NET Core/.NET 5: they run in Visual Studio itself (which is still a .NET Framework app as of this writing), and other places. Do you have need for the generator to target something newer? |
|
@jasonmalinowski I guess our issue was we wanted to use the source generator to use some classes in another internal library that was targetting net5, not .net standard, and as the source generator has to target netstandard 2.0, then the other internal library now has to target netstandard 2.0, which sets off a chain of retargetting. |
|
My source generator seems to have the problem despite calling -> var generated = string.Format(
CultureInfo.InvariantCulture,
"// <autogenerated/>{0}{1}{0}{0}[assembly: GitInformationAttribute(\"{2}\", \"{3}\", \"{4}\", typeof({5}{6}))]{0}",
Environment.NewLine,
splittedLen > 0 && !string.Equals(
gitinformationNamespace,
usingStr.ToString(),
StringComparison.Ordinal) ? $"using {usingStr};{Environment.NewLine}using {gitinformationNamespace};" : $"using {gitinformationNamespace};",
this.RunGit("describe --all --always --dirty", Directory.GetParent(gitBuildInfoJsonFile.Path).FullName),
this.RunGit("rev-parse --short HEAD", Directory.GetParent(gitBuildInfoJsonFile.Path).FullName),
this.RunGit("name-rev --name-only HEAD", Directory.GetParent(gitBuildInfoJsonFile.Path).FullName),
splittedLen > 0 ? splitted[splittedLen - 1] : options!.AssemblyType,
options!.IsGeneric ? "<>" : string.Empty);
context.AddSource("GitAssemblyInfo.g.cs", SourceText.From(generated, Encoding.UTF8));Yes I use manual string because I do not know how (other than Yes I should use A way to somehow fix this would be appreciated, for some reason cswin32 displays them but for me vs2019 16.10 preview says my source generator is not generating files. And yes it uses |
|
@AraHaan source generators must not perform file I/O, either directly (e.g.
You can use Nerdbank.GitVersioning to inject Git properties as build properties, that can then be declared as compiler-visible properties accessed through |
And it exposes the results of what the I guess I could use an inline build task to expose them as an msbuild property and then access it with the source generator if I absolutely needed to. |
It might not offer all of what you're after, but it probably does offer at least a subset, plus a solid example for how to implement any others you might need. |
Alright removed all I/O and visual studio still says that it does not produce files even though I call Edit: restarting VS2019 oddly made it show them up. |
I believe that due to the way source generators are loaded, the view in Solution Explorer, as well as any Intellisense, etc., is set when VS loads. You need to restart it to change that. |
See #48083 |
??? |
|
I am experiencing this also, although my code-generator is already targeting 2.0: Target project: CodeGenProject:
After I installed Visual Studio 2022 it works. I think it's related to the SDK version installed, it uses dlls from their (GAC) and not whatever is defined in the project. Very confusing. |
|
Is there a path towards allowing Source Generators to be written in .NET5/.NET6? .NETStandard 2.0 seems kinda obsolete for new code. |
|
Not yet. Perhaps in 2 more years of waiting it can be done. |
Je ne comprendre pas. You run the generator when you run the generator. Nobody else will.
Again, I don't get it. I will pack the dependency with the retarded netstandard2 project. It'll run on a dev machine or a build server. Where else? |
We run the generator when inputs change. So we need to know what the inputs are. If you do additional io, then you are dependent on the result of that io and need to be rerun of that io would produce different results. But we don't know if that would happen since we don't know what io you performed |
An isolated sandbox that has no access to io whatsoever. |
I'm not interested in that. I'm interested in escaping the netstandard chains and for this purpose I just need the native library to load anyway.
OK, so its only about the up to date check, ty - I can reason about that and work with MSBuild to make it right if at all needed. |
then:
That's all we're saying. You can do whatever you want. We just do not support it and will not work to make it easy. It may also break badly in teh future. You're in 'undefined/unsupported' space. Effectively: "all bets are off". |
The problem here is taht we may assume fully anything about this (because you are doing defined behavior). So we may do things like cache previous results if we don't believe any of the inputs has changed. So, what may work today may break tomorrow. |
|
P/Invoke must stay - not to defeat a sandbox, but because it is so useful. The |
|
Where did you read that the requirement may be dropped? Can you link me? |
|
Yeah, that's not a statement about 2023. That appears to be tongue-in-cheek. The statement about netstandard is true. It is the only thing currently supported. That may drop in the future. But there is no statement or plan to announce around a particular date. |
|
What I said back then does not offer any guarantees that it will be done in the future, or ever. Also I am at no power to even make decisions for any of the teams for any of the repositories here and all of those are up to those that are in said teams (Not intending to be mean to anyone). |
|
Yeah sure, I think everyone understands what you both say. But it would still be such a huge benefit for what I'm planning to do and what many others are doing or will be doing that it would be very helpful to have an idea of the why and how so we can get an approximate idea of the when and decide whether it is worth waiting for or not and the amount of effort that is justified to work around this horrible issue. |
|
The only way to allow source generators to target .NET 6 and newer would be for the IDE itself to migrate to .NET 6 and newer which will take probably a few more years for the Visual Studio team to do so and migrate .NET Framework specific code out of process (which is a lot of work to do). There is also the issues with the compiler that runs on the .NET Framework as well for those who want to use C# 8 or newer with their .NET Framework projects as well. With all this considered it might not be possible because of the compiler build that runs on .NET Framework as well in order to build .NET Framework projects. |
|
Yes, again, not much imagination needed to predict that to be the main reasons, but that also means it doesn't tell me anything new or specific enough.
I would seriously hope that most of the .NET ecosystem can evolve without being held hostage by this, whatever the implications on Roslyn itself are. Could even think of VS loading a different MSBuild depending on compatibility of say the solution, seeing that most of it is already out of proc and there are many people by now like me who just dont have .NET Framework code anymore for a long time. And that population is growing rapidly. But yeah, I don't have to make that happen, so for me its an easy thing to say. |
I can't imagine us ever supporting this. It's a genuine anti pattern. :-/ |
Using |
|
No. Doing io. |
|
You quoted me talking about targeting .NET 6 and when all the issues that I read about around here and that many people struggle will mostly just vanish. Otherwise I just need the native lib. How is that an anti-pattern. And today it runs from a Visual Studio extension and references half of a major solution. Doesn't matter how that became to be. It is how I found it. I have to fix it. Preferably quickly. Don't talk from your high compiler tower. If you have useful guidance, give it. The genuine anti pattern is your snarking. Again. |
You asked earlier about what the issues are. I was just explaining. Stating that something is undefined behavior is just a way to explain what we are supporting versus what might be working today but which could break in the future.
Ok. I have no problem with that. I'm just trying to explain what the state of things are :-)
Sorry, it wasn't clear to me that this statement was only limited to that aspect of things. It sounded like it was about all the issues you were reporting. I do hope eventually we might be able to support net6, but it's going to take a ton of work across many teams, so no way to even know if it will happen or when that might be if it does. |
Just checking if this is still the case in 2024 and with
Yesterday, I created a source generator in a project which multi-targets |
|
Yes this is still currently the case. |
|
@sharwell wrote:
So all of this code here is broken?! It's full of language features that won't work with the old .NET Standard 2.0. Can I only use generators that are limited to .NET Framework code even if they support a library that only targets .NET 8? There's even a video from a dotnetconf where these new language features are used. That feature or its limitation doesn't make any sense. What's the use case of code generators after all? I have the same error message as the original post. Targeting .NET 8.0 for everything. VS 2022. |
|
@ygoe: Don't confuse that there are a few different in play here: you must target netstandard2.0, which means the DLL containing the generator targets netstandard2.0. But that's different than what the end project is targeting, or which language version that application consumes. You can happily target net8.0 for everything except the generator. It can still see newer language constructs in the target application just fine too since you're seeing those as syntax APIs. But yes, implicit in this is you can't use newer language features in a generator, but that's usually not too much of a hardship. And if it is, you can override the language version in the project file, just understanding warranties are void and you can run into strange corners if you're not careful. But the expectation is that generators are small, fast, and not pulling in many dependencies so it should be fine. |
|
The code from the page I linked to is for the generator implementation, so that's the generator project. In fact the only official documentation I could find is this cookbook and it explicitly recommends using records – a feature that does not exist or work in .netstandard2.0. So still this whole design is pointless in my eyes. It requires a runtime that it cannot run in. How stupid. Also, clearly that cookbook code has never been tested in reality. Besides a missing parenthesis I found there, all of it would never compile. I know that I can use the generator in any other target project. I'm talking about the generator project itself here. |
|
Records should work fine in netstandard2.0. I recommend polysharp for this |
|
Okay, after a lot of searching and try and error, here's the missing information that everybody needs in order to really write source generators:
The generator's .csproj file looks like this: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<LangVersion>latest</LangVersion>
<Nullable>enable</Nullable>
<EnforceExtendedAnalyzerRules>true</EnforceExtendedAnalyzerRules>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.10.0" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.4" PrivateAssets="all" />
</ItemGroup>
</Project>And creating such a project and setting it up won't work immediately. The generated types cannot be found, no matter how often you recompile. Visual Studio must be restarted, then the generated types are recognised in the application code. It also must be restarted every time these static generated types (with Any source generation will only happen when explicitly compiling the application project. Modifications to the generator project will at least be picked up immediately. No generation happens while editing or saving application source files or when loading the project. A manual recompilation is needed. In order to verify the generated code, it is helpful to save it to files on disk. To enable this, the application project consuming the generator needs this setting: <PropertyGroup>
<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
</PropertyGroup>The generated files can be opened in Visual Studio, but may not be updated to reflect the latest contents if the compilation failed. An external file editor is needed in that case. The files are stored in obj\Debug\net8.0\generated\ or similar. |
|
To use the following versions of the libraries: |
and others
I am having trouble getting the source generators to run/work. I am not sure what is not working. I have been working on this off and on for several days, and then today when I open the solution it just had worked at some point. Not sure if it was while opening the project or what caused the success. I went and added a new file to create a new source generator and then nothing. Now when I build the project, I get the following warning when building:
I have added this project to my sample Blazor app github repo so the issue can be easily duplicated.
Sample Source Generator Project
I created this source generator project, added it to my solution, and modified the associated SampleSourceGenerators.csproj file to be as shown below. I also added the sample HelloWorldGenerator.cs by copy/paste from the online examples. I then went to the project where I wanted to use the generated source and added the modification shown below to the Website.Server.csproj.
I initially was using VSCode 1.51.0, but with source generators, I switched over to using Visual Studio 2019 Preview 6 since I am not aware of source generators working in VSCode yet. I am also using the .NET SDK framework 5.0.100-rc.2.20479.15.
Build Output Window
SampleSourceGenerators/SampleSourceGenerators.csproj
SampleHostedApplication/Website/Server/Website.Server.csproj
dotnet --info
The text was updated successfully, but these errors were encountered: