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
Use of EditorBrowsableState.Never
leads language service to claim it's gone
#720
Comments
I have zero issues with changing the editor browsable state for these APIs. But before we're changing the APIs to accommodate tools I'd like to understand the IntelliSense behavior. Is this a side effect of how the combined language service works in multi-targeted projects? If so, can we fix this? |
The "this is only available on one side" logic is implemented by computing the list for both targets; it merges all the times together and if it didn't appear on one side or the other then the warning is given. You could imagine that we could instead merge and compute the warnings prior to throwing out the things for EditorBrowsableState.Never, although I'm not sure how much work that would take. I would have two things to think about:
|
@dpoeschl might also know more about the behavior here as well. |
That's what I thought. I don't think the current behavior is desirable. You show a warning in IntelliSense that never materializes as a diagnostic when building. As this issue demonstrates, this is confusing because IntelliSense claims an API to be unavailable when in fact it is available but hidden. If the API is marked as
That's why I'd like to avoid having to change the API declarations.
I don't buy the described scenario. If the person obsoletes the API for one TFM, then the consumer will get a warning when building for that TFM. Keep in mind that when people use multi-targeting they often do so because they need to support multiple versions of the same TFM. In that scenario you're often forced to call API that was obsoleted/hidden in a later TFM because the replacement isn't available in the earlier TFM. In that scenario, not showing me the API is the opposite of being helpful. |
We have the So what's the plan here? How can IDispatch even be deprecated to begin with? |
I’m not sure why it’s marked as hidden. I’ll take a look tomorrow. FWIW, I agree with you that In 99% of cases obsoletion and hiding shouldn’t be combined. |
Fixing this will greatly improve the quality of IntelliSense we get when we develop Office Add-in and other COM interop code which we plan to target for .NET Framework and .NET Core. |
Are these even supposed to be deprecated? There is an issue about some COM features that mistakenly were marked obsolete. |
OK, I've created dotnet/roslyn#40370 to track the potential for changing how IntelliSense deals with hidden APIs. Now let's keep this thread focused on the why these particular APIs are hidden/obsoleted. |
These APIs were marked hidden/obsolete when the original port to coreclr was made. At that time we had no COM support so it made sense. In 3.0, we have that support so they are technically still valid. Issue https://github.com/dotnet/corefx/issues/40376 was created based on my comments at https://github.com/dotnet/coreclr/issues/26207#issuecomment-522070936. At a minimum these APIs shouldn't marked |
@AaronRobinsonMSFT , started to port our COM-object from NETfx to NETCore, got |
@Dennis-Petrov See https://github.com/dotnet/core-setup/issues/7800 for an end-to-end with VBA and the current issues. |
@AaronRobinsonMSFT , thanks a lot! |
@AaronRobinsonMSFT Why not just use |
@AArnott, in my particular case COM object is just a thin legacy wrapper around large piece of functionality. It depends on number of NETStandard2.1/NETCore 3.1 libraries. Actually, absence of type library is a headache. I'm considering available options... Create IDL manually, compile it with MIDL compiler? How to register that TLB on target machine? |
@AArnott That is a valid point. Since all that is needed is a TLB it is possible to simply take the .NET Framework DLL and generate the TLB to represent the contracts. The only caveat is the automatic generation of class interfaces, which is not supported in .NET Core and unlikely to be brought back. This reduces to the idea that if one defines all their interfaces in C# compiles for .NET Framework and then runs the assembly through |
@AaronRobinsonMSFT are you OK with these changes then? public enum ComInterfaceType
{
- [System.ComponentModel.EditorBrowsableAttribute(System.ComponentModel.EditorBrowsableState.Never)]
- [System.ObsoleteAttribute("Support for IDispatch may be unavailable in future releases.")]
InterfaceIsDual = 0,
InterfaceIsIUnknown = 1,
- [System.ComponentModel.EditorBrowsableAttribute(System.ComponentModel.EditorBrowsableState.Never)]
- [System.ObsoleteAttribute("Support for IDispatch may be unavailable in future releases.")]
InterfaceIsIDispatch = 2,
InterfaceIsIInspectable = 3,
} |
@terrajobst Yep, that makes sense to me. |
Ping? I just hit this with 5.0p4. |
Looks good as proposed public enum ComInterfaceType
{
- [System.ComponentModel.EditorBrowsableAttribute(System.ComponentModel.EditorBrowsableState.Never)]
- [System.ObsoleteAttribute("Support for IDispatch may be unavailable in future releases.")]
InterfaceIsDual = 0,
InterfaceIsIUnknown = 1,
- [System.ComponentModel.EditorBrowsableAttribute(System.ComponentModel.EditorBrowsableState.Never)]
- [System.ObsoleteAttribute("Support for IDispatch may be unavailable in future releases.")]
InterfaceIsIDispatch = 2,
InterfaceIsIInspectable = 3,
} |
Reactivating because the proposed and accepted API change was made, then lost. See? The attributes are still there: runtime/src/libraries/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs Lines 149 to 158 in d5b1a7f
|
@AaronRobinsonMSFT Can you re-apply your change? |
It's not just the language service discoverability issues. These attributes are leading to CS0618 warnings on legitimate code. |
@AArnott That is a different API. This issue was for |
Due to the
Never
flag used on a couple of these enum values:runtime/src/libraries/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs
Lines 288 to 298 in 20ab2fa
When coding against multiple frameworks, Roslyn claims the APIs are simply missing:
Can we get these
Never
settings to be changed toAdvanced
instead?Desired API Changes
The text was updated successfully, but these errors were encountered: