cc @mairaw @safern @jkotas @jbartlau

Do we also want to remove the Obsolete attributes on UnmanagedType.Struct (which is the way to explicitly request an object is marshalled to a VARIANT)?

Do we also want to remove the Obsolete attributes on UnmanagedType.Struct (which is the way to explicitly request an object is marshalled to a VARIANT)?

Would be helpful, yes, otherwise anyone doing real VARIANT work would still encounter warnings. Also see my comment here regarding VarEnum.

Okay. Here are my thoughts.

Also see my comment here regarding VarEnum.

Makes perfect sense. I will remove that.

Do we also want to remove the Obsolete attributes on UnmanagedType.Struct

Boo. This is annoying, but I get the semantic need. I will remove this.

The other types I will remove the attribute for:

• UnmanagedType.IDispatch
• UnmanagedType.SafeArray
• UnmanagedType.VariantBool

I am leaving the attribute on the following though:

• UnmanagedType.AnsiBStr
• UnmanagedType.AsAny
• UnmanagedType.Currency
• UnmanagedType.TBStr
• UnmanagedType.VBByRefStr

My reasoning is because the BSTR ones are incredibly nuanced and cause more stress than need be and should be actively discouraged. The previous argument is inline with VBByRefStr as well, even though there will be VB scenarios where it is used, I am inclined to make users suppress in those cases. One of my biggest issues is AsAny since it basically allows the user to throw up their hands and say "you deal with this", which is never the right thing to do when working with COM/Interop since there is no chance to always do the right thing for everyone. As far as Currency is concerned, I can see Office developers being the only group that has a strong opinion so we can discuss that if there is push back.

Any concerns with this reasoning?

Sounds like a good plan to me!

@jeffschwMSFT do you have any concerns with my plan above?

@dotnet-bot test Packaging All Configurations x64 Debug Build please

@stephentoub Does the above look weird to you? Looking at the errors in the above failure they seem to be unrelated to anything I am doing in this PR. Are you seeing similar failure in your PRs? Do we have a contact for these kind of infrastructure issues?

OSX failure is: https://github.com/dotnet/corefx/issues/35224
UWP failure I don't know if it has an issue yet but it is a known issue related to the Windows Version we're using to run the tests. cc: @ViktorHofer another instance here.

I reported the issue to Azure DevOps, that when retrying a build through the Checks UI, Re-run button, it creates another job in the PR, with a different name, leaving the failing leg there.

it creates another job in the PR, with a different name, leaving the failing leg there.

Thanks @safern. Based on the above, I am going to assume all legs are now passing.