Internal attributes prevent build on .NET4.8

[amirburbea]

I'm trying to decorate a method parameter with [AllowNull]. Inside the IDE, visual studio recognizes it and works fine, but when I go to compile the project I can not - it says the attribute is internal not public

[manuelroemer]

Hi, I‘d like to help you, but I need more information to see where the problem lies since it’s working as intended in my local test projects.

Could you either upload a sample C# project where the problem occurs or alternatively list the exact steps required to reproduce the error? Ideally both?

Many thanks!

[manuelroemer]

Also, are you using a WPF Project? If so, could your issue be related to #11?

[manuelroemer]

Closing this for now since I cannot reproduce an error without more information. If the issue persits, please comment and provide further information. We can then reopen this issue.

[amirburbea]

Closing this for now since I cannot reproduce an error without more information. If the issue persits, please comment and provide further information. We can then reopen this issue.

It was WPF framework but with new csproj format. I think making them public would solve the problem. I have public copies of the ones in a .net standard project I reference and it is fine. And it seems a .net core project also referencing that standard project has no conflict

See in https://GitHub.com/mburbea/koar-item-editor

There's a project KoAR.Core it is standard and has those attributes. The saveeditor is a wpf framework project and itemtesting is dotnetcore. No conflict and works fine

[manuelroemer]

Alright, thanks for the follow-up, much appreciated!
The issue with WPF projects is already tracked in #11 (it's the same issue with a different error message). As mentioned there, I don't really have a solution for this at the moment. If I ever find one, I'll fix the issue ASAP.

Making the attributes public is not an option as there will 100% be conflicts in certain projects, especially libraries. If the attributes could be public, there would be no reason to provide this package in source-code form. Instead, we could just publish it as a .dll and call it a day.

Nontheless, thanks again for reporting!