Will there be sufficient tooling to highlight APIs that are not part of the .NET standard? Historically tooling has always been slow, but it would be ideal to highlight areas that are not compatible and hand hold developers into making in .NET standard worthy.

As a library author which version of .NET Standard should I target? (seemed an item missed out)

What are the plans and timelines for supporting creation of .NET Standard libraries and ASP.NET core applications using VB.NET.

Will the tooling have warnings regarding netstandard1.5/1.6?

Perhaps just completely removing them as options from all UI tooling. Also, a warning would be nice when uploading to NuGet. Oh, and it's good that you're reaching out to the half-dozen users today, but a permanent warning system / (web)hook for future libraries targeting these would be nice, too.

(It's my impression that those are practically deprecated, though the post stopped short of claiming that)

@benaadams The lowest you can. Except not 1.5/1.6.

Which brings up another good point: a lot of netstandard usage appears to be "just target the highest - it's the latest version so it's the best", instead of the proper mentality of "target the lowest, since it has the widest platform reach".

It would be great if there was some proactive tooling - perhaps an info- or warning-level message when building a netstandard nupkg - that determines the actual required netstandard version and says something if the target is artificially high.

I have concerns about diamond dependencies, strong naming, versioning and multiple versions in same process. Is there going to be some guidance on this that is easy to follow?
My specific scenario involves dynamically loading different ISV assemblies that will often have dependencies on different versions of the same library (say JSON.net, or other popular libraries) in the same process. Thanks.

.NET Standard 1.5/1.6/1.7+ are not compatible with 2.0; however I assume will be compatible with a 2.x version - how will that sub-version compatibility/non-compatibility be handled and communicated?

e.g.
could be numerically 1.5 =>2.5, 1.6 =>2.6, 1.7 => 2.7
could be tooling
could be docs etc

@terrajobst Your new table is a lot better than the previous one. Could you please add a legend to these tables? Specifically, a table legend should describe the meaning of the "→" and " * " symbols. I know what they are now, but take a look here: https://docs.microsoft.com/en-us/dotnet/articles/standard/library#net-platforms-support

When I first started out with .NET Core, the missing table legend drove me absolutely crazy when trying to understand the table with these arrow and star symbols. Others are having the same issue.

Will MarshalByRefObject be part of standard?

@bchavez I gave this feedback to @terrajobst when writing the blog post because I saw the comments on our article. I can update the table in the docs.

I've opened an issue to track this update: dotnet/docs#1093

How do you reference a NETStandard-based library from a desktop application and not break anything? (like System.Net.Http and System.IO.Compression)

Is netstandard1.0-1.6 API fixed? If new features be implemented in net core, will they be able to go to lower netstandard versions or they will be only in 2.0+? For example, BinaryFormatter, is there a chance that it will be available on Netstandard 1.3 too, not only Netstandard 2.0.

I use APIs removed from netstandard2.0 that are present in 1.6, when can i expect a netstandard2.1 that bring them back? - Will they ship at the same time, just like netstandard1.0-1.5 did?

We have a .Net Framework system compiled against .Net Framework 4.6.2, using internally-built .Net Framework 4.6.1 DLLs that are incorporated as true library components. If the library builders switch to targeting .Net Standard in their next version, what standard should they support (so that when we take them for our host system everything is hunk-dory)?

It's not fully clear to me what's in an out, would you publish a summary page of the APIs included?

Also, where does WCF fits here? Would you adopt other RPC-style frameworks such as gRPC or NATS?

Thanks!

Will tools continue to download most of .NET standard when they reference libraries, or will runtimes ship with those libraries pre-downloaded?

When will .NET Core support the creation of .NET Standard nugets? If it already does, where are the docs?

When will Xamarin support creating .NET Standard libraries?

I would love to see a diagram following the type forwarders path from a usage over the netstandard down to the actual clr implementation ... For each platform and especially .NET Core.

I would love seeing the standalone publishing result of a netstandard assembly based app on .NET Core. Wondering in regards of the unused types.

Also more details about the build of an App which uses typeforwarding assemblies like netstandard.dll. Additionally I wonder how the platforms are built. You are not doing black magic here (massive typeforwarding and automatic facade generation), however many steps are far beyond a normal dev usage.

Also see my related question https://github.com/dotnet/corefx/issues/11155 and https://github.com/dotnet/corefx/issues/4373

@terrajobst assuming I have a library that targets both .NET Standard 1.4 and .NET Standard 1.6, will a .NET Standard 2.0 library be able to reference it and use the netstandard1.4 implementation?

FWIW, here's a concrete case where I needed to target netstandard1.6: aspnet-contrib/AspNet.Security.OpenIdConnect.Server#325.

New apis that are added to corefx that don't have a run-time dependency shouldn't rev the version they are compatible on?

i.e. not sure why System.Collections is now netstandard1.7 shouldn't it also be netstandard1.3?

So if I wanted to use the new Queue.TryDequeue as its only an il change and could happily run on any platform; any reason why this isn't still netstandard1.3? Or is it because it itself is part of the standard and thus needs to be part of a version change to the standard?

Or is it because it itself is part of the standard and thus needs to be part of a version change to the standard?

You nailed it.

How does .NET standard compare with .NET framework and .NET core? Do they sit side-by-side? Are they a superset? Or are they a subset? I only develop software for the Windows 10 store, will .NET framework still be supported or are you looking at replacing it?

@ZeroInfinite see if this helps https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7

@davidfowl That's very nice.

BTW on a stack overflow article you replied to someone saying AppDomains were dead in .Net Core, and referred the reader to a replacement system, pointing to an example on GitHub. Hut:

• the link is dead
• AppDomain is in .Net Standard 2.0

I have a very simple question that I am finding impossible to get the answer to. In our app we use AppDomain.CreateDomain and AppDomainCreateInstanceAndUnwrap. Will we be able to do this in .Net Core? If not is there an alternative?

System.Runtime.Loader.AssemblyLoadContext.Default?

@Mattacks I'd suggest you watch the recent On.NET show with Immo where AppDomains are discussed (around 43:30): https://channel9.msdn.com/Shows/On-NET/Immo-Landwerth-Net-Standard

To summarize: even though AppDomain.CreateDomain() is in the standard, it'll just throw a not supported exception on .NET Core.