dotnet / standard Goto Github PK

From faq.md:

David Fowler provided a developer analogy that explains
.NET Standard in terms of interfaces and classes.

We should incorporate the Gist here and update it to .NET Standard 2.0.

I see:

M:System.Linq.Expressions.Expression`1.Compile(System.Boolean)
M:System.Linq.Expressions.LambdaExpression.Compile(System.Boolean)

won't make it to netstandard20. But these are essential for ORMs: they are used to create projection code from user supplied lambda expressions in linq queries, so they can be run at full speed on each row. Additionally, running user supplied code which has to run in-memory in a linq query projection is easy with these, but very hard/impossible without them

Not porting these will be a big problem.

So my question is: will these be available in an assembly which targets netstandard20? If not, it will be hard to port ORM code which has flexible projection functionality to netstandard20 (or one has to fall back to IL generation at runtime, which sucks)

Edit
I see CoreFX supports LambdaExpression.Compile(), which is great, so it shouldn't be too hard to make an assembly with these which targets netstandard20 ?

We need to compare netstandard.dll with the older PCL profiles. This includes the older v1 PCL profiles as well as the contract based PCL profiles. netstandard needs to contain all the APIs in those profiles.

The constructor is marked obsolete, it won't work on .NET Core, and it forms bad dependency on System.Thread.

The absence of a data story for netstandard20 is a bad sign. If System.Data was part of netstandard, it would be controlled by a committee, things would be designed in the open. Now it's a black box, designed by the SQL Server team who is almost non-existent across the .NET repositories here on github, and communicating with them is in one word: terrible.

For data-oriented libraries and applications which depend on System.Data it's crucial there's a consistent story for System.Data. IMHO it's therefore essential this very important API is part of netstandard20.

System.ApplicationIdentity is part of the click-once appmodel. Examples of other click-once appmodel specific types are ActivationContext or ApplicationTrustCollection. ApplicationIdentity implements parsing of click-once specific application identity strings.

None of the other types for click-once appmodel are netstandard. ApplicationIdentity should be removed as well.

Remove ctor(System.IO.FileStream) from "System.Reflection.StrongNameKeyPair
see dotnet/coreclr#7530 (comment)

• It has zero usage in any of our usage catalogues.
• It's stubbed out to throw a NotImplementedException on Mono.
• ServicePoint in Core will live in System.Net.Requests.dll, and we don't want System.Net.Mail.dll to need a dependency on the former, simply to maintain the API shape (it likely wouldn't use it for implementation).

Right now the casing of the csproj's is inconsistent, leading to output assemblies with names like this e.g. for net461:

We should either make everything lowercase, or use the casing the assemblies have used in the past everywhere.

The protected properties System.Resources.ResourceSet.Table and System.Resources.ResourceManager.ResourceSets are both of type Hashtable.
These types cannot be outside the core assembly so this Hashtable dependency would require moving all of NonGeneric collections into the core assembly as well.

While removing CAS SecurityPermissionAttribute was also removed however there is decent amount of usage (https://apisof.net/catalog/System.Security.Permissions.SecurityPermissionAttribute) because a lot of existing binaries just have it applied even if it does nothing. It does pull in a decent amount of other APIs in its closure.

Given it is just a marker attribute similar to SecurityCriticalAttribute I'm leaning towards including it and its closure after I have a closer look at it.

Remove ArgIterator and TypedReference along with any __arglist overloads as they aren't easily supported on some platforms and there mostly only for managed c++ support which isn't really supported by our newer platforms.

There are very few times developers should be using raw .NET threads anymore so why include them?

We have a fair amount of APIs that are marked as Obsolete in both net461 and xamarian should we include them in the standard?

https://github.com/dotnet/standard/blob/master/docs/netstandard-20/netstandard-20-apis.md
excludes Microsoft.Csharp
but
https://github.com/dotnet/standard/blob/master/docs/netstandard-20/README.md
includes it.
Please have consistent information.

This is an enum that's only used by System.Configuration.IdnElement. It shouldn't be in the System namespace and can be removed as part of S.Configuraiton.

Following apis are not applicable for single appdomain. They require creation of another domain and presence of AppDomainSetup. AppDomainSetup got cut and so following could be removed as well.

    public bool ShadowCopyFiles => false;
    public void AppendPrivatePath(string path) { throw new PlatformNotSupportedException(); }
    public void ClearPrivatePath() { throw new PlatformNotSupportedException(); }
    public void ClearShadowCopyPath() { throw new PlatformNotSupportedException(); }
    public void SetCachePath(string path) { throw new PlatformNotSupportedException(); }
    public void SetShadowCopyFiles() { throw new PlatformNotSupportedException(); }
    public void SetShadowCopyPath(string path) { throw new PlatformNotSupportedException(); }

edit: Removed DynamicDirectory from the list.

While factoring out reflection.emit we broke compat with some TypeLib APIs (see https://github.com/dotnet/standard/blob/master/netstandard/src/ApiCompatBaseline.net461.txt#L2) (

Given one is an interface which we cannot keep compatible I'm think we should remove it from standard completely. As part of that I'm thinking we should exclude all the TypeLib APIs from standard.

I've read the updated details about not introducing breaking changes to .NET Standard 2.0 which I generally like, even though I don't know what APIs would be affected.

But if this can now work without these weird changes, why was it a problem in the first place? What will happen when a .NET Standard 2.0-targeted program runs on .NET Framework 4.6.1 which doesn't have all the capabilities? Will it crash? Will it find and download missing DLLs at runtime? Please explain.

Also, why is updating .NET Framework such a big issue? There's already .NET Framework 4.6.2 on all supported platforms (even included in probably the majority of Windows 10 systems, thanks to forced updates), and updating it isn't a big thing, is it?

https://msdn.microsoft.com/en-us/library/system.reflection.assembly.unsafeloadfrom(v=vs.110).aspx
https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Reflection/Assembly.cs#L217

HttpUtility is helper type that traditionally lives in System.Web.dll and we have a replacement for some of the functionality in System.Net.WebUtility. We have said we don't want System.Web stuff to be in the standard but this type does have some usage so the question is should we include it in the standard or not?

After publishing the blog post on .NET Standard, many people have pinged me with additional questions. I'd like to collect them all so we can answer them.

Please comment below, I'll keep a running tally in here.

The AccessControl APIs are windows specific but cross-cutting across various other APIs in the standard. We need to take a closer look at what APIs get broken if we remove them from the standard.

We want to remove Remoting APIs from the standard but we want to keep BinaryFormatter but it has a dependency on a few Remoting APIs.

public sealed partial class BinaryFormatter : /*System.Runtime.Remoting.Messaging.IRemotingFormatter,*/ System.Runtime.Serialization.IFormatter
{
    public BinaryFormatter() { }
    public BinaryFormatter(System.Runtime.Serialization.ISurrogateSelector selector, System.Runtime.Serialization.StreamingContext context) { }
    public System.Runtime.Serialization.Formatters.FormatterAssemblyStyle AssemblyFormat { get { throw null; } set { } }
    public System.Runtime.Serialization.SerializationBinder Binder { get { throw null; } set { } }
    public System.Runtime.Serialization.StreamingContext Context { get { throw null; } set { } }
    public System.Runtime.Serialization.Formatters.TypeFilterLevel FilterLevel { get { throw null; } set { } }
    public System.Runtime.Serialization.ISurrogateSelector SurrogateSelector { get { throw null; } set { } }
    public System.Runtime.Serialization.Formatters.FormatterTypeStyle TypeFormat { get { throw null; } set { } }
    public object Deserialize(System.IO.Stream serializationStream) { throw null; }
//REMOTING        public object Deserialize(System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) { throw null; }
//REMOTING        public object DeserializeMethodResponse(System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) { throw null; }
    public void Serialize(System.IO.Stream serializationStream, object graph) { }
//REMOTING        public void Serialize(System.IO.Stream serializationStream, object graph, System.Runtime.Remoting.Messaging.Header[] headers) { }
//REMOTING        public object UnsafeDeserialize(System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) { throw null; }
//REMOTING        public object UnsafeDeserializeMethodResponse(System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) { throw null; }
}

As part of removing the remoting APIs I'm planning to remove the APIs on BinaryFormatter that depend on them. Currently they don't have any notable usage and we can get the majority of the value of BinaryFormatter without them so I'm leaning towards removing them.

@stephentoub do you have any opinions on these?

We removed from AppDomain as part of remoting

//REMOTING public System.ApplicationIdentity ApplicationIdentity { get { throw null; } }

Does this mean it's not meaningful in standard? If so we should remove the type and the 2 uses of it in the IsolatedStorage namespace. @JeremyKuhne

If you do this please close https://github.com/dotnet/corefx/issues/10196

Although the ValueTuple and related types won't be part of the 2.0 standard, the meta-package which supports the experience in VisualStudio will reference some additional types for convenience.

@weshaggard @ericstj @tarekgh @terrajobst for information and triage.

While removing CAS APIs I needed to remove the following members from IsolatedStorage:

public abstract partial class IsolatedStorage : System.MarshalByRefObject
{
//CAS        protected abstract System.Security.Permissions.IsolatedStoragePermission GetPermission(System.Security.PermissionSet ps);
}
public sealed partial class IsolatedStorageFile : System.IO.IsolatedStorage.IsolatedStorage, System.IDisposable
{
//CAS        protected override System.Security.Permissions.IsolatedStoragePermission GetPermission(System.Security.PermissionSet ps) { throw null; }
//CAS        public static System.IO.IsolatedStorage.IsolatedStorageFile GetStore(System.IO.IsolatedStorage.IsolatedStorageScope scope, System.Security.Policy.Evidence domainEvidence, System.Type domainEvidenceType, System.Security.Policy.Evidence assemblyEvidence, System.Type assemblyEvidenceType) { throw null; }
}

The abstract member removal from IsolatedStorage is the one that causes the most issues as we cannot have a compatible surface area. For example someone compiling against netstandard and deriving from IsolatedStorage will not see or know they need to implement that abstract member and thus when they run on a platform where that is abstract they will blow-up. We have a few options:

1. We keep the member and add back its closure, which is larger then I like because IsolatedStoragePermission pulls in a decent size closure.
2. We can make the IsolatedStorage type not inheritable by removing its protected constructor. This will allow people to still use its APIs but not extend it.

I'm doing to do more thinking about this and take a closer look at the full closure if we go with option (1) but I also don't think option (2) is terrible as most folks just work with IsolatedStorageFile itself and don't really derive or interact with the IsolatedStorage class.

This document: https://github.com/dotnet/standard/blob/master/docs/netstandard-20/netstandard-20-apis.md

specifies:

The current proposed API list for .NET Standard is being tracked \\fxcore\Platforms\NetStandard\netstandard20.xlsx

But that file isn't found. Where is it located?

We need to figure out which set of AppDomain APIs to include as part of the standard. There is a large intersection with technology we don't want in the standard, such as Ref.Emit, CAS, Remoting, ClickOnce, etc.

for the app bringup effort, we trimmed some of the crypto API's that were problematic and had limited or no usage. (spreadsheet on request)

for .net standard 2.0, we're defaulting to included. this principle needs to be reconciled with the crypto API.

@bartonjs fyi.

I recently switched one of my PCL project over to the standard, and found that the DataContractAttribute Class and XmlElementAttribute Class were not supported.

Will they be added in the future? They are in the other platforms, surprised to see them missing.

It is touched upon with the JSON.NET, but add a generic version also? Something like:

Why is XXX not part of .NET Standard?

If a library is written in pure il (e.g. C#, VB.NET, F# etc) then in can run across all platforms which support the .NET Standard platform or above that it targets, with no code changes; this includes and future platforms. Any additional apis it adds also automatically work on all these versions as well.

If the library lives in a package, this gives that library and library author great flexibility to version and make releases on their own cadence. As well as consumers of that library great choice on when they upgrade the version of that library they are using.

If it is added directly to the standard it can only version at the same cadence as the standard; and will only be supported on other platforms when they update the platform to match the standard, so the release cycle flexibility and platform support is much reduced.

/cc @terrajobst

This is a suggestion for the FAQ:
There is a lot of text about net standard but as a developer I am missing some basic examples (for reference etc, show me the code....). Also I think it is easier to "connect the dots" this way.

For me personally it is not always directly clear how I can "target" net standard in code so I need to look those up, maybe an idea to put this in the FAQ? Questions like:

As a library author, how do I target/use a net standard?
As an app author, how do I target/use net standard?

That rises another question, whats the difference between usage and targetting?

So maybe some examples with:
"dependencies" in project.json
"frameworks" in project.json
"NETStandard.Library" meta package (and what it is/does)
"netstandard1.x" TFMs

And what is Microsoft.NETCore.App? What is the difference with NETStandard.Library and when should I use it

This link explains a lot but not everything: https://docs.microsoft.com/en-us/dotnet/articles/core/packages

TBH I find it still pretty confusing, the doc above is listed under ".NET Core" and not under ".NET Standard" and also is a lot of text so I like the idea of a FAQ (but with code snippets)

As we don't have plan to port NetDataContractSerializer to CoreCLR for now, we should remove it from NetStandard2.0.

/cc: @weshaggard @zhenlan @danmosemsft

We've developed a library for the .NET Core framework with the build target netstandard1.6. It can be executed in Windows, Linux and Mac OS. If we update to netstandard20, will it work on all platforms?

Project: https://github.com/blackcity/backload
Website: https://www.backload.org

Right now, we've haven't included DbProviderFactories for examples, which I think we should.

We are excluding Remoting APIs from the standard and as part of that we need to decide what to do with MarshalByRefObject. There are a few options:

1. Remove MarshalByRefObject as well
2. Remove just CreateObjRef method from MarshalByRefObject to break the remoting API dependency.
3. Pull in the closer of ObjRef into netstandard so we can have a complete closer of MarshalByRefObject in the standard. Currently the closer pulls in ~10 more remoting specific interfaces.

I'm tentatively leaning towards option (2) but I'm interested in other opinions.

This type is only used by ExtensibleClassFactory which has been removed.

For reference we have a compat baseline file at https://github.com/dotnet/standard/blob/master/netstandard/src/ApiCompatBaseline.xamarin.ios.txt which represents the current API Compat issues between netstandard and Xamarian.IOS (which is what I'm using as my reference). The current netstandard is still a work in progress and it was seeded with net461 so there is still plenty of filtering we need to do. As we filter the compat baseline file will get refreshed but the ultimate goal is to have that baseline file show no issues before we finalize netstandard 2.0.

There are two ways to reduce the compat baseline, which I expect we will use on a case-by-case basis:

1. Add more APIs to Xamarian
2. Remove APIs from netstandard (either by completely removing or by filtering out into an extension).

cc @akoeplinger @marek-safar

I figured I'd lift a little conversation with @terrajobst from the comments of the netstandard blogpost to here for better visibility :)

Me:

I’d love to see standard interfaces for json serialization that json.net and others implement. there are other json serializers out there, like Jil and service stack, that don’t get the attention they deserve

@terrajobst:

Interesting. What would these interfaces provide that a generic data pipeline (such as Streams) wouldn’t achieve?

Me:

Besides having a common interface for doing the actual serialization/deserialization(that people usually end up defining them selves in every project), they could include stuff for setting names of json properties or otherwise customizing the serialization process. Similar to how data annotations provide an abstract way to annotate classes for ui that then can be used by different implementations

What do you think? I understand it's pretty late in the game for NetStandard 2.0 but I think it would be very useful. Maybe it doesn't even have to be specific to json but like a general way to abstract naming members for serialization and actually performing the serialization/deserialization

https://github.com/dotnet/standard/tree/master/docs/netstandard-20

I still don't get it. Can you provide an analogy that makes sense for a dev?
David Fowler provided a developer analogy that explains .NET Standard in terms of interfaces and classes.

Refer to this page: https://github.com/davidfowl/NetStandard, instead of that gist ?

The Marshal type currently has lot members which are related to COM and other things which are missing in Xamarin:

public static partial class Marshal
{
//INTEROP public static void CleanupUnusedObjectsInCurrentContext() { }
//INTEROP public static object CreateWrapperOfType(object o, System.Type t) { throw null; }
//INTEROP public static TWrapper CreateWrapperOfType<T, TWrapper>(T o) { throw null; }
//INTEROP public static int FinalReleaseComObject(object o) { throw null; }
//INTEROP public static System.Guid GenerateGuidForType(System.Type type) { throw null; }
//INTEROP public static string GenerateProgIdForType(System.Type type) { throw null; }
//INTEROP public static object GetActiveObject(string progID) { throw null; }
//INTEROP public static System.IntPtr GetComInterfaceForObject(object o, System.Type T) { throw null; }
//INTEROP public static System.IntPtr GetComInterfaceForObject(object o, System.Type T, System.Runtime.InteropServices.CustomQueryInterfaceMode mode) { throw null; }
//INTEROP public static System.IntPtr GetComInterfaceForObject<T, TInterface>(T o) { throw null; }
//INTEROP public static System.IntPtr GetComInterfaceForObjectInContext(object o, System.Type t) { throw null; }
//INTEROP public static object GetComObjectData(object obj, object key) { throw null; }
//INTEROP public static int GetComSlotForMethodInfo(System.Reflection.MemberInfo m) { throw null; }
//INTEROP public static int GetEndComSlot(System.Type t) { throw null; }
//INTEROP public static int GetExceptionCode() { throw null; }
//INTEROP public static System.IntPtr GetExceptionPointers() { throw null; }
//INTEROP public static System.IntPtr GetHINSTANCE(System.Reflection.Module m) { throw null; }
//INTEROP public static int GetHRForException(System.Exception e) { throw null; }
//INTEROP public static int GetHRForLastWin32Error() { throw null; }
//INTEROP public static System.IntPtr GetIDispatchForObject(object o) { throw null; }
//INTEROP public static System.IntPtr GetIDispatchForObjectInContext(object o) { throw null; }
//INTEROP public static System.IntPtr GetITypeInfoForType(System.Type t) { throw null; }
//INTEROP public static System.IntPtr GetIUnknownForObject(object o) { throw null; }
//INTEROP public static System.IntPtr GetIUnknownForObjectInContext(object o) { throw null; }
//INTEROP [System.ObsoleteAttribute("The GetManagedThunkForUnmanagedMethodPtr method has been deprecated and will be removed in a future release.", false)]
//INTEROP public static System.IntPtr GetManagedThunkForUnmanagedMethodPtr(System.IntPtr pfnMethodToWrap, System.IntPtr pbSignature, int cbSignature) { throw null; }
//INTEROP public static System.Reflection.MemberInfo GetMethodInfoForComSlot(System.Type t, int slot, ref System.Runtime.InteropServices.ComMemberType memberType) { throw null; }
//INTEROP public static void GetNativeVariantForObject(object obj, System.IntPtr pDstNativeVariant) { }
//INTEROP public static void GetNativeVariantForObject<T>(T obj, System.IntPtr pDstNativeVariant) { }
//INTEROP public static object GetObjectForIUnknown(System.IntPtr pUnk) { throw null; }
//INTEROP public static object GetObjectForNativeVariant(System.IntPtr pSrcNativeVariant) { throw null; }
//INTEROP public static T GetObjectForNativeVariant<T>(System.IntPtr pSrcNativeVariant) { throw null; }
//INTEROP public static object[] GetObjectsForNativeVariants(System.IntPtr aSrcNativeVariant, int cVars) { throw null; }
//INTEROP public static T[] GetObjectsForNativeVariants<T>(System.IntPtr aSrcNativeVariant, int cVars) { throw null; }
//INTEROP public static int GetStartComSlot(System.Type t) { throw null; }
//INTEROP [System.ObsoleteAttribute("The GetThreadFromFiberCookie method has been deprecated.  Use the hosting API to perform this operation.", false)]
//INTEROP public static System.Threading.Thread GetThreadFromFiberCookie(int cookie) { throw null; }
//INTEROP public static object GetTypedObjectForIUnknown(System.IntPtr pUnk, System.Type t) { throw null; }
//INTEROP public static System.Type GetTypeForITypeInfo(System.IntPtr piTypeInfo) { throw null; }
//INTEROP public static System.Type GetTypeFromCLSID(System.Guid clsid) { throw null; }
//INTEROP public static string GetTypeInfoName(System.Runtime.InteropServices.ComTypes.ITypeInfo typeInfo) { throw null; }
//INTEROP [System.ObsoleteAttribute("Use System.Runtime.InteropServices.Marshal.GetTypeInfoName(ITypeInfo pTLB) instead. http://go.microsoft.com/fwlink/?linkid=14202&ID=0000011.", false)]
//INTEROP public static string GetTypeInfoName(System.Runtime.InteropServices.UCOMITypeInfo pTI) { throw null; }
//INTEROP public static System.Guid GetTypeLibGuid(System.Runtime.InteropServices.ComTypes.ITypeLib typelib) { throw null; }
//INTEROP [System.ObsoleteAttribute("Use System.Runtime.InteropServices.Marshal.GetTypeLibGuid(ITypeLib pTLB) instead. http://go.microsoft.com/fwlink/?linkid=14202&ID=0000011.", false)]
//INTEROP public static System.Guid GetTypeLibGuid(System.Runtime.InteropServices.UCOMITypeLib pTLB) { throw null; }
//INTEROP public static System.Guid GetTypeLibGuidForAssembly(System.Reflection.Assembly asm) { throw null; }
//INTEROP public static int GetTypeLibLcid(System.Runtime.InteropServices.ComTypes.ITypeLib typelib) { throw null; }
//INTEROP [System.ObsoleteAttribute("Use System.Runtime.InteropServices.Marshal.GetTypeLibLcid(ITypeLib pTLB) instead. http://go.microsoft.com/fwlink/?linkid=14202&ID=0000011.", false)]
//INTEROP public static int GetTypeLibLcid(System.Runtime.InteropServices.UCOMITypeLib pTLB) { throw null; }
//INTEROP public static string GetTypeLibName(System.Runtime.InteropServices.ComTypes.ITypeLib typelib) { throw null; }
//INTEROP [System.ObsoleteAttribute("Use System.Runtime.InteropServices.Marshal.GetTypeLibName(ITypeLib pTLB) instead. http://go.microsoft.com/fwlink/?linkid=14202&ID=0000011.", false)]
//INTEROP public static string GetTypeLibName(System.Runtime.InteropServices.UCOMITypeLib pTLB) { throw null; }
//INTEROP public static void GetTypeLibVersionForAssembly(System.Reflection.Assembly inputAssembly, out int majorVersion, out int minorVersion) { majorVersion = default(int); minorVersion = default(int); }
//INTEROP public static object GetUniqueObjectForIUnknown(System.IntPtr unknown) { throw null; }
//INTEROP [System.ObsoleteAttribute("The GetUnmanagedThunkForManagedMethodPtr method has been deprecated and will be removed in a future release.", false)]
//INTEROP public static System.IntPtr GetUnmanagedThunkForManagedMethodPtr(System.IntPtr pfnMethodToWrap, System.IntPtr pbSignature, int cbSignature) { throw null; }
//INTEROP public static bool IsComObject(object o) { throw null; }
//INTEROP public static bool IsTypeVisibleFromCom(System.Type t) { throw null; }
//INTEROP public static int NumParamBytes(System.Reflection.MethodInfo m) { throw null; }
//INTEROP public static int ReleaseComObject(object o) { throw null; }
//INTEROP [System.ObsoleteAttribute("This API did not perform any operation and will be removed in future versions of the CLR.", false)]
//INTEROP public static void ReleaseThreadCache() { }
//INTEROP public static bool SetComObjectData(object obj, object key, object data) { throw null; }
}

We need to decide whether or not we add these to the netstandard or if we make people that want to use them cross-compile to .NET Framework?

cc @yizhang82 @tijoytom

In netfx, these are returned from 4 classes that expose CreateEncryptor()\CreateDecryptor() members. The signature for these members return ICryptoTransform so there was never a guarantee that these members would return CryptoAPITransform\RijndaelManagedTransform types. Newer classes that expose CreateEncryptor()\CreateDecryptor() do not return CryptoAPITransform\RijndaelManagedTransform types.

The likely corefx implementation is to create these two types but throw PNSE on each member and not create an instance of these two types anywhere. This means consuming code would compile, but would throw InvalidCastException when casting from ICryptoTransform to CryptoAPITransform \ RijndaelManagedTransform.

Users should change such variables to ICryptoTransform instead. It is better to have users fix code at compile-time (change to ICryptoTransform) than fail at run-time with InvalidCastException.

@weshaggard @bartonjs

SecurityException is used for more then just CAS stuff but it contains a lot of CAS related members so with the removal of CAS we removed a number of members.

public partial class SecurityException : System.SystemException
{
//CAS        public SecurityException(string message, object deny, object permitOnly, System.Reflection.MethodInfo method, object demanded, System.Security.IPermission permThatFailed) { }
//CAS        public SecurityException(string message, System.Reflection.AssemblyName assemblyName, System.Security.PermissionSet grant, System.Security.PermissionSet refused, System.Reflection.MethodInfo method, System.Security.Permissions.SecurityAction action, object demanded, System.Security.IPermission permThatFailed, System.Security.Policy.Evidence evidence) { }
//CAS        public System.Security.Permissions.SecurityAction Action { get { throw null; } set { } }
//CAS        public System.Security.IPermission FirstPermissionThatFailed { get { throw null; } set { } }
//CAS        public System.Security.SecurityZone Zone { get { throw null; } set { } }
}

Given those members don't really show any usage in our data I think we should just exclude them from the standard.

What is the current thinking on including full support for COM Interop in .NET Standard and .NET Core? It sounds like you would rather not have Windows-specific things like this in Standard. If I'm reading this correctly, apisof.net (currently down) indicates System.Type.GetTypeFromProgID() will be included in the next release: https://webcache.googleusercontent.com/search?q=cache:tYoULw9HjAcJ:https://apisof.net/catalog/System.Type.GetTypeFromProgID(String,String)+&cd=1&hl=en&ct=clnk&gl=us. Can you clarify, or is this still up in the air?

Personally, I will need to work with other technologies via COM Interop for years to come. I hope that doesn't preclude me from moving to .NET Core one day.

aebf70f

If we can add those to Xamarin then they can be included in netstandard and remove some more API differences.

The site https://apisof.net/ does not currently work, it says that "The catalog contains 0 APIs." and browsing or searching does not return anything.

I couldn't find a good place to report this and the site does not have any contact information (only "© 2016 - Microsoft"), so I thought the repo that manages a lot of the APIs that were previously shown on the site would be the least bad place.

While factoring out CodeDom (3238783) I had to remove IDataContractSurrogate as well because it depends on System.CodeDom.CodeTypeDeclaration which has a fairly large closure from CodeDom. This causes a number of serialization APIs to be removed which we may need to figure out a solution for.

Xamarin removes the member from IDataContractSurrogate (https://github.com/mono/mono/blob/d70777a3332af2d630d24adf620c2e548b92b56a/mcs/class/referencesource/System.Runtime.Serialization/System/Runtime/Serialization/IDataContractSurrogate.cs#L21) which is an incompatible API change when talking about sharing binaries between .NET Framework and Xamarin so we cannot do this in .NET Standard.

We basically have 2 choices:

1. Live with the removal of IDataContractSurrogate and associated serialization APIs
2. Pull in the full closure of CodeTypeDeclaration into the standard.

@zhenlan thoughts?