Git Product home page Git Product logo

standard's Introduction

standard's People

Contributors

danmoseley avatar ericstj avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

standard's Issues

Obsolete APIs

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

Remove System.ApplicationIdentity

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.

RCF: Creating an FAQ

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.

Xamarin compat issues with netstandard

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

Compare netstandard with older PCL profiles

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.

AppDomain apis not applicable for single domain

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.

Remove ArgIterator/TypedReference

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.

System.Web.HttpUtility

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?

BinaryFormatter remoting dependencies

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?

SecurityPermissionAttribute removal as part of CAS

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.

Clarify direction of COM Interop

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.

IsolatedStorage members removed because of CAS

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.

TypeLib APIs

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) (

//REFEMIT System.Reflection.Emit.AssemblyBuilder ConvertTypeLibToAssembly(object typeLib, string asmFileName, int flags, System.Runtime.InteropServices.ITypeLibImporterNotifySink notifySink, byte[] publicKey, System.Reflection.StrongNameKeyPair keyPair, bool unsafeInterfaces);
)

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.

AppDomain APIs

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.

remove UriLdnScope

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.

Remove ResourceSet.Table, and ResourceManager.ResourceSets.

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.

Marshal type

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

Remove SmtpClient.ServicePoint

  • 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).

apisof.net does not work

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.

SecurityException members removed because of CAS

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.

Make casing of csproj and assemblies consistent

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

image

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

Not sure the ubiquity of (c)il comes across fully

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

Investigate ACL APIs

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.

FAQ: Show code examples

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)

crypto api's

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.

Will the Data contract and xml element attributes be added?

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.

Why is there no System.Data in netstandard20?

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.

IDataContractSurrogate

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?

.NET Standard 2.0 vs. .NET Framework 4.6.1

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?

Abstraction for json serialization

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

LambdaExpression.Compile is essential

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 ?

MarshalByRefObject

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.

Recommend no System.Security.Cryptography.CryptoAPITransform and RijndaelManagedTransform

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.