-
Notifications
You must be signed in to change notification settings - Fork 353
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
Revert "Work around implicit usings breaking change (#7745)" #7766
Conversation
This reverts commit 5f00dd2.
I'm not sure we should do this. Afaiu, @tmat made this to unbreak a bunch of repos across the stack. Would it be possible to unblock winforms by enabling the feature in the failing projects? |
We absolutely have to do it. First it broke VB that "always" worked. And the implicit usings are being re-done in dotnet/sdk#19521 and dotnet/sdk#19599, and this property is no longer relevant... |
The sdk changes won't make it anywhere until we release one that includes them correct? I'd like to understand how this is a safe change for the other repos. |
dotnet/sdk#19599 was merged a week ago, it should have flown through to target repos. |
ping. All arcade updates into winforms repo are blocked. @tmat . |
@RussKie is it possible to conditionalize this on project type so that VB is supported, but C# keeps this behavior? |
@mmitche this property in Q was and is used only by VB targets. It was erroneously reused for C# scenarios in dotnet/sdk#18459, but reverted back in dotnet/sdk#19599. The whole implicit usings has been reimplemented. IMO Arcade in general shouldn't be used for these kinds of changes. Each repo owner must opt-in or out of specific SDK features. |
Alright, I have no-concerns on reverting this. |
This reverts commit 5f00dd2.
This broke Visual Basic, that requires implicit usings to work. dotnet/winforms#5437
To double check: