dotnet / Nerdbank.GitVersioning

Stamp your assemblies, packages and more with a unique version generated from a single, simple version.json file and include git commit IDs for non-official builds.
https://www.nuget.org/packages/Nerdbank.GitVersioning
MIT License
1.37k stars 168 forks source link

error CS0122: 'ThisAssembly' is inaccessible due to its protection level #449

Closed MSThug closed 4 years ago

MSThug commented 4 years ago

Hi there I'm on a project that uses Nerdbank.GitVersioning 3.1.68. After a number of changes updating our WPF project to .NET Core 3.1 at some point we started to see the follow error.

error CS0122: 'ThisAssembly' is inaccessible due to its protection level

To be clear this had been working. But at some point we changed our project SDK from "MSBuild.SDK.Extras" to "Microsoft.NET.Sdk.WindowsDesktop".

Of course this is because we use some of the properties from the ThisAssembly class in our code. After a number of attempts to determine the cause I finally tried defining ThisAssembly in our code as seen below.

internal static partial class ThisAssembly { internal const int IgnoreMe = 0; }

This changed all the errors all to something along the lines of the error below.

error CS0117: 'ThisAssembly' does not contain a definition for 'AssemblyVersion'

I only found a couple references to the first error online but they seemed to work around the issue by disabling GitVersioning and one eluded to the timing of when ThisAssembly is created. That would certainly explain the two different errors and the fact that I see the errors in VS after building but they very quickly disappear in the Error List panel when I navigate to the files with the errors. However, they can always be found in the build logs.

Use of GitVersioning is seems pretty straight forward and the only significant csproj file change was the SDK change. All other changes were code so I doubt they could affect this.

AArnott commented 4 years ago

I believe the reason you're struggling is due to an open issue in the WPF build SDK, where it doesn't respect PackageReference in its "inner build".

Your issue sounds like a duplicate of #404, though the symptom is slightly different because your WPF project references another project that also uses NB.GV, whereas in #404 that isn't the case.

Basically in WPF's inner build, NB.GV doesn't get a chance to run and thus doesn't create the ThisAssembly class. But you have a project reference to another assembly that does define it, so C# thinks references in your code to ThisAssembly must be referring to that one. Since this class is always defined as internal, you then get an error that you can't access it, which is misleading because you actually want to be accessing your own internal one that doesn't exist.

The good news though is there are workarounds for this. Check out #404 (and links) to learn more.

MSThug commented 4 years ago

That did the trick. Thanks!

LevYas commented 3 years ago

This issue is the first in Google results, so instead of the long chain of links I'll add a shortcut: https://github.com/microsoft/CsWin32/issues/7#issuecomment-799718520