Skip to content
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

Setting GenerateAssemblyInfo=false stops source generator from running #407

Closed
MagicAndre1981 opened this issue Sep 30, 2024 · 20 comments · Fixed by #422
Closed

Setting GenerateAssemblyInfo=false stops source generator from running #407

MagicAndre1981 opened this issue Sep 30, 2024 · 20 comments · Fixed by #422
Assignees
Labels
bug Something isn't working

Comments

@MagicAndre1981
Copy link

MagicAndre1981 commented Sep 30, 2024

Describe the Bug

After Updating ThisAssembly to from 1.5.0 to 2.0.0 I can no longer access the ThisAssembly.Info properties like ThisAssembly.Info.Description

image

As they come from 3rd party tools, not from my project:

image

Steps to Reproduce

update from "ThisAssembly.AssemblyInfo" to 2.0:

<PackageReference Include="ThisAssembly.AssemblyInfo" Version="2.0.0">

Expected Behavior

code can be called var Description = ThisAssembly.Info.Description; fine as in 1.5.0

In my csproj I have set thoise 2 entries:

<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
<CompilerGeneratedFilesOutputPath>Generated</CompilerGeneratedFilesOutputPath>

and I no longer see the genereted ThisAssembly.AssemblyInfo.g.cs file only the ApplicationConfiguration.g.cs which includes the generated calls for ApplicationConfiguration.Initialize();

Back this issue
Back this issue

@MagicAndre1981 MagicAndre1981 added the bug Something isn't working label Sep 30, 2024
@devlooped-bot devlooped-bot added the sponsor 💚 Sponsor via contributions label Sep 30, 2024
@kzu
Copy link
Member

kzu commented Sep 30, 2024

Hi there! Some questions:

  • Is this an intellisense or a build error? (Try filtering for build in the error list)
  • Does it also fail when doing dotnet build in the CLI?
  • Does closing and reopening the solution make a difference?

Thanks!

@kzu
Copy link
Member

kzu commented Sep 30, 2024

I created a new console app, added the package, and verified that the intellisense doesn't work at first, but after first build, it does. Seems to be something in VS since I'm not doing anything different on that front.

image

@kzu kzu removed the sponsor 💚 Sponsor via contributions label Sep 30, 2024
@kzu
Copy link
Member

kzu commented Sep 30, 2024

If you delete bin/obj without closing the source file, you see the same effect:

image

(note the Build + Intellisense in the drowdown). Doing a "full build" fixes it automatically though.

Does that match your experience?

@MagicAndre1981
Copy link
Author

closing/reopening make no different and also deleting the obj nuget folder makes no difference.

This is a compile error as the generated class is not found I can't compile the project at all no matter if I try it from VS2022 or cli with dotnet.

@kzu
Copy link
Member

kzu commented Sep 30, 2024

Could you share which package you're using? ThisAssembly.AssemblyInfo or ThisAssembly (metadata package)?
Also, would you mind creating a blank console app, adding the same package and using WriteLine as I did above? If you see the same error, would you mind running dotnet build -bl and attaching the binlog? 🙏

@MagicAndre1981
Copy link
Author

I use this one:

https://www.nuget.org/packages/ThisAssembly.AssemblyInfo/2.0.0

and before updating I was using the 1.5.0 version which is now unlisted?

https://www.nuget.org/packages/ThisAssembly.AssemblyInfo/1.5.0

I'm now out of office for the rest of the day, I'll try to compare the build with 1.5.0 and 2.0.0 tomorrow.

@kzu
Copy link
Member

kzu commented Sep 30, 2024

Yeah, I have unlisted 1.5 in favor of 2.0.

@kzu kzu added need info and removed bug Something isn't working labels Sep 30, 2024
@MagicAndre1981
Copy link
Author

ok, comparing 1.5.0 and 2.0.0 shows that 2.0.0 nuget misses the actual generator dll ThisAssembly.AssemblyInfo.dll and so this is no wonder why no code is generated. The thisassembly.constants package still contains the ThisAssembly.Constants.dll so consts are translated into code. 🤔 Why is the dll missing? What have you changed?

And I'm not allowed to provide such a binlog (GDPR).

@MagicAndre1981
Copy link
Author

Why is the dll missing? What have you changed?

ok, after looking at the commits (which are horrible as there are a lot of meaningless commits "Bump files with dotnet-file sync" which is awfull to see what commits do, you need to check every commit what is changed) I found this commit.

This explains the dependency on ThisAssembly.Constants and here is my issue. With MSBuild Structured Log Viewer I can see that the task to transfer my assembly infos into constants is not called so the Constants Source generator can only transfer my dummy constants I've added to check if this code generator is called.

image

@kzu
Copy link
Member

kzu commented Oct 1, 2024

ThisAssembly.AssemblyInfo is indeed just a special case of Contants (most packages are, now). That should not be the issue at all.

Could you please create a repro project? I simply cannot reproduce your issue as-is. The fact that those targets are greyed out do not indicate much (could have run previously already, for example). Without either a repro project or a binlog, there isn't much I can do :(

you need to check every commit what is changed

Not really, you can just look at commits that actually affect the specific project folder or files. dotnet-file sync keeps my template repo in sync only, which involves gh workflows, markdown text, and so on. Nothing in C# files in most cases.

@MagicAndre1981
Copy link
Author

I've created a demo that works fine with 1.5.0 and fails with 2.0.3. It is an empty .net 8 WinForms application but includes all reference nugets as in my real application but it depends on subversion for version control.

You need to checkout the code from the repo with svn/TortoiseSVN and open the sln in trunk

ThisAssembly.AssemblyInfo.Demo_SVN_Repo.zip

If I downgrade the package to 1.5.0 I get the generated files.

@MagicAndre1981
Copy link
Author

Could you please create a repro project? I simply cannot reproduce your issue as-is.

Did you have some time to look at it? You need use svn checkout file:/// with path to create a working copy and get the project.

@OoLunar
Copy link

OoLunar commented Oct 7, 2024

Able to reproduce as a first party consumer and with `dotnet build` in CLI.

@OoLunar
Copy link

OoLunar commented Oct 7, 2024

This seems to only happen when upgrading from a previous version. Remove ThisAssembly from your csproj file, run dotnet clean, then readd the updated version through: dotnet add package ThisAssembly --version 2.0.3

@kzu
Copy link
Member

kzu commented Oct 8, 2024

Roslyn does heavy caching of intermediate files. I'd suggest deleting bin/obj recursively and try again.

I do not have or use svn to test this locally from the provided zip. I doubt it has anything to do with source control, to a simple zip of the actual sources should be enough if it does repro.

@MagicAndre1981
Copy link
Author

As already said, clearing obj/bin makes no difference.

without svn the code doesn't compile as I've added Unclassified.NetRevisionTask I also use in my project. You wanted all references, you get all references in the demo

@MagicAndre1981
Copy link
Author

ok, I found the cause. Setting GenerateAssemblyInfo to false prevents the constant translation, setting it back to true makes your generator works again and I can see the files under Generated\ThisAssembly.Constants\ThisAssembly.ConstantsGenerator But I have to set this to false, otherwise I Unclassified.NetRevisionTask doesn't work and I don't see the svn revision in the file version

@kzu
Copy link
Member

kzu commented Oct 8, 2024

That's great actionable investigation, thanks! I'll look into it ASAP.

@kzu kzu changed the title Source Generator no longer runs since updating to 2.0.0 Setting GenerateAssemblyInfo=false stops source generator from running Oct 8, 2024
@kzu kzu added bug Something isn't working and removed need info labels Oct 8, 2024
@kzu kzu self-assigned this Oct 8, 2024
kzu added a commit that referenced this issue Oct 8, 2024
We were missing this since the SDK defaults the specific attributes to `true` only if the overall flag `GenerateAssemblyInfo` is `true`. We change that in our targets, but without forcing `GenerateAssemblyInfo=true`. This allows to turn off codegen, but still get the attributes as items.

Fixes #407
@kzu
Copy link
Member

kzu commented Oct 8, 2024

Got the fix 💪 #422

@kzu kzu closed this as completed in #422 Oct 8, 2024
kzu added a commit that referenced this issue Oct 8, 2024
We were missing this since the SDK defaults the specific attributes to `true` only if the overall flag `GenerateAssemblyInfo` is `true`. We change that in our targets, but without forcing `GenerateAssemblyInfo=true`. This allows to turn off codegen, but still get the attributes as items.

Fixes #407
@MagicAndre1981
Copy link
Author

MagicAndre1981 commented Oct 9, 2024

Got the fix 💪 #422

nope, still the same error. The translation to constants runs but generates crap (Company gets project name, version is 1.0.0.0 not my version from Unclassified.NetRevisionTask) so the default values. And the Copyright, Description from AssemblyInfo.cs are not translated and so I still have compile error CS0117: 'ThisAssembly.Info' does not contain a definition for 'Description'

And when I update the nuget in my demo project to 2.0.4 I get this error:

Generated\ThisAssembly.Constants\ThisAssembly.ConstantsGenerator\Info.Company.g.cs(17,15,17,27): error CS0101: The namespace '<global namespace>' already contains a definition for 'ThisAssembly'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants