-
Notifications
You must be signed in to change notification settings - Fork 652
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
[Bug] CS0436 may be present with InternalsVisibleTo #3606
Comments
@Applesauce314 can you please create a test solution that reproduces the issue, and then we can decide if/when to fix it. If we decide to do it, then it will be implemented in v6 release cycle. |
Apparently the change made for #448 only existed in version 3.2.1, version 4.0.0 was what actually returned to the original behavior. my thoughts on "fixing" it would be to add a configuration option, that way it would not be a breaking change. <GenerateGitVersionInformationInUniqueNamespace>true</GenerateGitVersionInformationInUniqueNamespace> I have a fork I can turn into a pull request with the above suggestion included |
Sure, please send the PR where we can discuss |
pull request is #3619 I am not very happy with the way I handled the template for C♯, its kind of clunky, |
🎉 This issue has been resolved in version 6.0.0-beta.4 🎉 Your GitReleaseManager bot 📦🚀 |
Describe the bug
When
GitVersionTask
was replace withGitVersion.MSBuild
in 5.6.0 the issue described in #448 has reemerged.Expected Behavior
Not sure, GitVersionTask -> GitVersion.MsBuild is obviously a breaking version change, but the inconsistent behavior does not appear to be documented. was this change in behavior intentional or an accidental regression between versions.
Actual Behavior
CS0436 is present if you try to use the
GitVersionInformation
when it is also present in a referenced project which exposes its internals to the current assembly withInternalsVisibleTo
The text was updated successfully, but these errors were encountered: