.NET Standard 2.0 is final #439
Comments
|
Is Visual Studio 15.3 RTM to be released in tandem? |
Only 15.3 preview available now. And if you read 15.3 preview release notes:
Sounds like at this time we can produce .NET Standard 2.0 libraries for internal tests only. |
|
The warning is standard boilerplate for unsupported previews and doesn't apply to the production of .NET Standard libraries. We're using this version of VS to build our stable bits too, so I wouldn't worry about it in this particular context. |
To quote Ron Gilbert "Soon. On the 17th of soon" 😄 |
|
FYI .NET Core 2 will be released on the 18th or 19th of September live during DEVintersection Europe. Source: |
|
Awesome! Great job guys! |
|
Is it OK now to use it for XF? |
|
Nice, good job yall! One question though, if I look at the diff between 1.6 and 2.0 I see quite at the top: + public sealed class AppDomain : MarshalByRefObject {
+ public string BaseDirectory { get; }
+ public static AppDomain CurrentDomain { get; }
+ public string DynamicDirectory { get; }
// etc...Did I miss some announcement about AppDomain getting back in there? A typical search still yields mostly info on that it will not be there. Using a ""previous month" search doesn't give much more. The SO post about it also still suggests it's out. I'm sure that I'm missing something obvious, and I hope this is the correct place to ask about this. Any input welcome. |
|
@jeroenheijmans yes the AppDomain class is in .NET Standard 2.0 (excluding some members snipped because they had problematic dependencies: remoting, CAS, ref emit). Also yes .NET Core does not support secondary AppDomains so it's implementation of .NET Standard 2.0 will throw PlatformNotSupportedException or similar for some members. Generally where a platform declares support for .NET Standard x it should fully implement it since this is the purpose of making a standard: and this is true in the vast majority of cases but there are always platform specific limitations such as secondary appdomains in the case of .NET Core that will bleed through the API in a few cases. |
It's listed in our FAQ for quite some time.
Yes, this is the right place to ask about all things .NET Standard. |
|
@danmosemsft Thx for the answer! @terrajobst Also thx for the link. As I mentioned, I was already afraid that I had missed that. Apologies for not reading the FAQ first, I shouldn't have relied only on a Google search turning up that info. |
Is there anything special you have to do to get this to work? I have a project targeting 461 and netcoreapp2.0 and have not been able to reference 3 different nuget libraries that I've tested so far. |
|
No worries. It's a fast moving world on GitHub and following us can be confusing for sure :-) |
|
What tool are you using? Both VS and CLI should work, assuming you're running the latest versions (VS 15.3 and .NET Core 2.0 Preview 2). What's the error you're getting? |
|
@terrajobst VS 2017. Tried installing
|
|
Is there any way of opting out of the compatibility shim? What If I want it to be netstandard all the way down the dependencies, without the risk of pulling in a 461 dependency that isn't actually compatible? Currently, the fact that I can happily reference and build with packages that aren't actually supported makes the process of building netstandard projects worse, not better for me. Previously (in < 2.0 days) I could reference a package, and if it wasn't supported, I'd get an error. Now, with the compat shim, I have to spend all my time trawling around nuget.org to check the dependencies, and see if each package I reference has a netstandard version (and hope that their dependencies don't rely on the compat shim and some unsupported api). On top of that, the inclusion of Overall, 2.0 is great, especially if I can disable the compat shim (potentially selectively). But the incompatibilities between platforms will makes a concept that many people are already having some difficult understanding even harder to fathom. |
|
The implicit .NET 4.6.1 package compatibility can be turned off by setting this property in your project file (inside of a <DisableImplicitAssetTargetFallback>true</DisableImplicitAssetTargetFallback> |
|
The behavior you observe is correct and the compat shim is working as designed. Whenever you use NuGet packages that go through the compat shim you'll get a warning like this:
We've made sure you get this warning every time you build (rather only during package restore) to ensure you don't accidentally overlook it. The idea here is that we have no way of knowing whether the .NET Framework binary will actually work. For example, it might depend on WinForms. To make sure you don't waste your time troubleshooting something that cannot work, we let you know that you're potentially going off the rails. Of course, warnings you have to overlook are annoying. Thus, we recommend that you test your application/library and if you're convinced everything is working fine, you suppress the warning:
In the project file this looks as follows: <ItemGroup>
<PackageReference Include="Huitian.PowerCollections" Version="1.0.0" NoWarn="NU1701" />
</ItemGroup>Note that the suppression isn't global but per package reference. This ensures that just using one library through the compat shim doesn't result in a free ride for all future references. If you install another library that goes through the compat shim, you'll get another warning. |
See my comment above; we make sure to tell you when you're consuming a library through the compat shim. I wouldn't bother turning it off and rather follow good hygiene and ensure you build with zero warnings. |
|
@terrajobst Great. I guess I incorrectly assumed that the warning meant it just wasn't going to work. Glad to know. :) |
|
I am a little confused as to why the .NET Framework 4.7.1 Preview announcement https://blogs.msdn.microsoft.com/dotnet/2017/08/07/welcome-to-the-net-framework-4-7-1-early-access/ lists ".NET Framework support for .NET Standard 2.0" as a feature if it's already supported by .NET Framework 4.6.1. Can someone clarify what this means? |
Great question. Here is the deal: .NET Framework 4.6.1 has shipped before we built .NET Standard 2.0. While .NET Framework 4.6.1 supports the API surface of .NET Standard 2.0, it does require extra DLLs that need to be deployed by the application. This includes, for instance, |
|
@terrajobst That makes sense. Thank you for the explanation. |
@terrajobst What does that mean for UWP? Would we be limited to accessing .net standard 2.0 libraries from UWP apps targeting Fall Creators Update? Or would we be able to also target Anniversary Update? |
|
AFAIR .NET Standard 2.0 will only be available for FCU and up. Reason being that we needed OS changes to make the added API surface work. |
|
@terrajobst is correct. |
|
@terrajobst / @danmosemsft And backported to mobile "feature2"? Or will the combo of Win10M and .NET standard be a no-go? |
|
We're trying to get an answer. Stay tuned. |
|
Lynda - Building Web APIs with ASP NET Core_Chris_Wodruff |
|
Also what is your Visual Studio version if you go to help->about? |
|
I dont have access to that training. Can you paste the contents of your project file here so I can see what you are doing? |
|
Also what is your Visual Studio version if you go to help->about? 15.40 |
|
sorry 15.4.0 |
|
Ok, that should be good with the .NET Core 2.0 SDK installed. Then if you do File->New Project and choose and ASP.NET Web API, can you build that app successfully? |
|
dotnet new console |
|
|
|
Ok your advice is to switch to ASP.NET Web API insted of core. |
|
I wasn't meaning to get off of .NET Core. I should have said ASP.NET Core Web API. I'm wondering if your NuGet cache somehow got corrupted. Can you try
Definitely looks like something is going on with restore. Something else that is weird is the errors you are getting. There are references to System.Windows.Forms which would not exist in a normal ASP.NET project at all. That doesn't look right at all. I'm not sure how you created that project. Did you copy it from somewhere or was it through Visual Studio? |
|
from command line i try from NuGet Package Manager >> Package manager console |
|
dotnet nuget locals all –clear |
|
Even webapi template work with dotnet cli thank yooooooooooou very much :) :) :) |
|
Ah great! That is a nasty bug in NuGet that I've seen numerous people hitting. Glad you are fixed now! |
|
FYI - I think is this bug but may not be exactly that issue. NuGet/Home#5995 |
|
Petermarcu I do not know how to thank you ! |
|
Regarding the guidance @terrajobst for using Results in this view: |
|
How can I use .net standard 2.0 in UWP that allows targeting Win10 mobile? With FCU as target and minimum I get this message:
Changing Min version to 15063 breaks .net standard 2.0 support:
🤷♂️ |
|
@MagicAndre1981 been waiting for an answer from the .NET team for about 4 months now. Crickets... so I think we need to draw our own conclusions here :-( |
|
@GeertvanHorrik ok, so we can wait forever 🤦♂️ |
|
@MagicAndre1981 unfortunately .NET Standard 2.0 requires a minimum of 10.0.16299 (see https://blogs.msdn.microsoft.com/dotnet/2017/10/10/announcing-uwp-support-for-net-standard-2-0/), and you need to be running that version of the OS in order to deploy and run that version of an application. @GeertvanHorrik sorry about not getting an answer, I don't have enough context to provide a full answer for that because I don't know how Win10M and UWP connect. Assuming Win10M is a target for UWP 16299 then .NET Standard will be available otherwise I don't believe it will support it. |
|
@weshaggard Thanks for trying to answer the question. Win10M is on a separate "feature" (what a name) branch and stuck on 10.0.15254.x. There were rumors about backporting newer API to at least make it possible to use .NET Standard 2.0 / keep targeting mobile users as well. I, as one of the users that are targeting Microsoft products because marketing told us to do so would like to know whether we should stop investing in Win 10 Mobile (and maybe UWP in general, for me personally it makes no sense to do anything in UWP if mobile is not part of the equation). Thanks! |
Not to say there isn't but I'm not aware of any work to make .NET Standard 2.0 work there. |
|
@GeertvanHorrik the wired thing is that Microsoft does have a full 16xxx Build targeting the phone, but they simply want to f*ck up with all users and never want to release it to the public: https://www.youtube.com/watch?v=YNxtMtlrm6U This was captured last year, when MS accidental released Build 16212.1001 for Fast Ring mobile users. The user got it working on the HP Elite x3 and you see a UI that is like the full Windows 10 and has better Continuum support by providing Windows support on Continuum, which is much better compared to current full screen only. So there are 3 ways this issue continues:
|
|
Without Windows 10 Mobile this is still a no go for me. What is right now the best configurations (and version numbers) for supporting Android and Windows 10 Mobile (15063) in a Xamarin.Forms app? Otherwise this whole thing does not make sense for me anymore. :-( |
|
use old PCL and MinVersion to Build 15063 (because last is mobile is 15254.Patchlevel). Strange thing is, under C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\Microsoft.NETCore.UniversalWindowsPlatform\6.1.5\ref\uap10.0.15138 I see a netstandard.dll version 2.0 and this build number is lower than last Win10 mobile feature2 versions, so it could have .net standard 2.0 support. Xamarin also plays with this 15138 |
Does the same warning show up if the library is referenced not as Nuget package but via |
and others
Summary
.NET Standard 2.0 is final.
You can now start producing .NET Standard 2.0 libraries and NuGet packages. Please use the latest .NET Core 2.0 Preview 2 as it contains many improvements that were necessary to provide a good experience.
Details
Bigger API Surface: We have more than doubled the set of available APIs from 13k in .NET Standard 1.6 to 32k in .NET Standard 2.0. Most of the added APIs are .NET Framework APIs. These additions make it much easier to port existing code to .NET Standard, and, by extension, to any .NET implementation of .NET Standard, such as .NET Core 2.0 and the upcoming version of UWP.
.NET Framework compatibility mode: The vast majority of NuGet packages are currently still targeting .NET Framework. Many projects are currently blocked from moving to .NET Standard because not all their dependencies are targeting .NET Standard yet. That's why we added a compatibility mode that allows .NET Standard projects to depend on .NET Framework libraries as if they were compiled for .NET Standard. Of course, this may not work in all cases (for instance, if the .NET Framework binaries uses WPF), but we found that 70% of all NuGet packages on nuget.org are API compatible with .NET Standard 2.0, so in practice it unblocks many projects.
Tooling Prerequisites
In general, make sure you run the latest version of the tooling:
dotnet) for building packages, so if you only want to use the CLI, you can stop here.Learn more by reading the .NET Standard FAQ.
The text was updated successfully, but these errors were encountered: