I've seen the following frameworks listed in project.json:
dotnet5.4
net451
dnx451
net46
Which framework do I use for creating a new class library which makes use of the new latest EntityFramework (version 7)?
I've noticed some of these actually break the project and I get some errors so I'm not sure how the NuGet packages relate to which framework.
You may want to read .NET Platform Standard to see where everything is headed.
dotnet5.4 will be replaced by netstandard1.3 which you can think of as portable-net46+uap10.0+CoreCLR+etc.
dnx451 is going away. If you want to target .NET Framework 4.5.1, use net451.
Related
i am currently using Restclient to send request via web api for xamarin, it works well with windows and ios but i doesnt work for andriod , i searched and found a nuget package that will help, called ModernHttpClient,so it changes my code from var httpclient = new HttpClient(); to var httpClient = new HttpClient(new NativeMessageHandler()); but when i install it for the web application i keep getting an error stating the package is not compatible with the project. but it installs ok in android,ios and windows. i tried uninstalling it from the web application but i doesnt work in the code unless it appears in all the project.
so i want to find the reason why the package is not compatible with the web appication or a solution to the Restclient request not working on android .
Unfortunately the product page for modernhttpclient on nuget.org doesn't list any dependencies, but changing the domain name of the URL to use fuget.org instead of nuget.org lists monoandroid, monotouch, portable-net45+winrt45+wp8+wpa81, and xamarin.ios10. Therefore, these are the target frameworks that the package supports.
Another way to check what TFMs (target framework monikers) a package supports is to find/download the nupkg and then open it as a zip file, or use NuGet Package Explorer to look for subfolders under lib/.
You didn't say what target framework your web app is using, but this is where things start getting very complicated and I don't understand it very well. .NET Framework TFMs are compatible with other .NET Framework TFMs of lower versions. Similarly .NET Core TFMs are compatiable with other .NET Core TFMs of lower versions. .NET Standard is a whole other complication. NuGet also supports fallback or alternate TFM compatibility, to allow .NET Core apps to use libraries targetting .NET Framework, but it's a best guess and might fail at runtime (maybe it's even possible to fail to compile, I'm not sure, but restore will succeed with a warning). Given you're not getting the warning, but instead an error, it suggests to me that portable-net45 is not compatible with net45 and therefore probably isn't compatible with whatever target framework you're using with your web app (unless your web app is targetting net40 or earlier).
Having said all that, when I was looking at the package to see which frameworks it targets, I saw that the whole point of the package is to use the platform native HTTP stack, instead of Xamerin's HTTP stack on the mobile platforms. Your web app isn't running on a mobile platform, it's running on either .NET Core or .NET Framework, so you shouldn't need the package. I suggest you use #if, #else and #endif to use NativeMessageHandler only on Android and IOS, and then use the default HTTPClient constructor (or use HttpMessageHandler) on other platforms.
I'm porting a full-framework project to target .NET Core 2.0. It has a call to
var builder = SqlClientFactory.Instance.CreateCommandBuilder();
...
So I've created a new .NET Core project and added a reference to System.Data.SqlClient 4.4.0. Unfortunately it seems that DbProviderFactory.CreateCommandBuilder has not been overriden, so that the call to CreateCommandBuilder always returns null.
I've tried to check if this API was officially available, and on the first sight it seemed so. Because that page says:
Platform: .NET Core
Version: 2.0
Assembly: System.Data.SqlClient, Version=4.3.1.0, PublicKeyToken=b03f5f7f11d50a3a
and I'm using System.Data.SqlClient 4.4.0 which is higher than 4.3.1.
However, to my next surprise I've found out that typeof(SqlClientFactory).Assembly said System.Data.SqlClient 4.2.0.. I had to learn that assembly and package versions are allowed to be inconsistent. I'm unsure then, why https://apisof.net is telling me Core 2.0. It seems it cannot be trusted.
So, I went to the .NET API Browser who correctly does not list CreateCommandBuilder for SqlClientFactory.
My question is, how can I get the before-mentioned System.Data.SqlClient, Version=4.3.1 assembly? The 4.4 nuget I'm using seems to be the latest one by the time of writing.
The only thing I can think of is to compile my own corefx checkout in order to get a working CreateCommandBuilder. Or start copying bits and pieces like the SqlCommandBuilder. But I don't know if that is a good idea.
Suppose I have a class library which I want to target netstandard1.3, but also use BigInteger. Here's a trivial example - the sole source file is Adder.cs:
using System;
using System.Numerics;
namespace Calculator
{
public class Adder
{
public static BigInteger Add(int x, int y)
=> new BigInteger(x) + new BigInteger(y);
}
}
Back in the world of project.json, I would target netstandard1.3 in the frameworks section, and have an explicit dependency on System.Runtime.Numerics, e.g. version 4.0.1. The nuget package I create will list just that dependency.
In the brave new world of csproj-based dotnet tooling (I'm using v1.0.1 of the command-line tools) there's an implicit metapackage package reference to NETStandard.Library 1.6.1 when targeting netstandard1.3. This means that my project file is really small, because it doesn't need the explicit dependency:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.3</TargetFramework>
</PropertyGroup>
</Project>
... but the nuget package produced has a dependency on NETStandard.Library, which suggests that in order to use my small library, you need everything there.
It turns out I can disable that functionality using DisableImplicitFrameworkReferences, then add in the dependency manually again:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.3</TargetFramework>
<DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Runtime.Numerics" Version="4.0.1" />
</ItemGroup>
</Project>
Now my NuGet package says exactly what it depends on. Intuitively, this feels like a "leaner" package.
So what's the exact difference for a consumer of my library? If someone tries to use it in a UWP application, does the second, "trimmed" form of dependencies mean that the resulting application will be smaller?
By not documenting DisableImplicitFrameworkReferences clearly (as far as I've seen; I read about it in an issue) and by making the implicit dependency the default when creating a project, Microsoft are encouraging users to just depend on the metapackage - but how can I be sure that doesn't have disadvantages when I'm producing a class library package?
In the past, we've given developers the recommendation to not reference the meta
package (NETStandard.Library) from NuGet packages but instead reference
individual packages, like System.Runtime and System.Collections. The
rationale was that we thought of the meta package as a shorthand for a bunch of
packages that were the actual atomic building blocks of the .NET platform. The
assumption was: we might end up creating another .NET platform that only
supports some of these atomic blocks but not all of them. Hence, the fewer packages you reference, the more portable you'd be. There were also concerns regarding how our tooling deals with large package graphs.
Moving forward, we'll simplify this:
.NET Standard is an atomic building block. In other words, new platforms
aren't allowed to subset .NET Standard -- they have to implement all of it.
We're moving away from using packages to describe our platforms,
including .NET Standard.
This means, you'll not have to reference any NuGet packages for .NET Standard
anymore. You expressed your dependency with the lib folder, which is exactly how
it has worked for all other .NET platforms, in particular .NET Framework.
However, right now our tooling will still burn in the reference to
NETStandard.Library. There is no harm in that either, it will just become
redundant moving forward.
I'll update the FAQ on the .NET Standard repo to include this question.
Update: This question is now part of the FAQ.
The team used to recommend figuring out what the slimmest package set was. They no longer do this, and recommend people just bring in NETStandard.Library instead (in the case of an SDK-style project, this will be done automatically for you).
I've never gotten a totally straight forward answer as to why that was, so allow me to make some educated guesses.
The primary reason is likely to be that it allows them to hide the differences in versions of the dependent libraries that you would otherwise be required to track yourself when changing target frameworks. It's also a much more user friendly system with the SDK-based project files, because you frankly don't need any references to get a decent chunk of the platform (just like you used to with the default references in Desktop-land, especially mscorlib).
By pushing the meta-definition of what it means to be a netstandard library, or a netcoreapp application into the appropriate NuGet package, they don't have to build any special knowledge into the definition of those things as Visual Studio (or dotnet new) sees them.
Static analysis could be used during publishing to limit the shipped DLLs, which is something they do today when doing native compilation for UWP (albeit with some caveats). They don't do that today for .NET Core, but I presume it's an optimization they've considered (as well as supporting native code).
There's nothing stopping you from being very selective, if you so choose. I believe you'll find that you're nearly the only one doing it, which also defeats the purpose (since it'll be assumed everybody is bringing in NETStandard.Library or Microsoft.NETCore.App).
You shouldn't need to disable the implicit reference. All platforms that the library will be able to run on will already have the assemblies that the NETStandard.Library dependency would require.
The .NET Standard Library is a specification, a set of reference assemblies that you compile against that provides a set of APIs that are guaranteed to exist on a know set of platforms and versions of platforms, such as .NET Core or the .NET Framework. It is not an implementation of these assemblies, just enough of the API shape to allow the compiler to successfully build your code.
The implementation for these APIs are provided by a target platform, such as .NET Core, Mono or .NET Framework. They ship with the platform, because they are an essential part of the platform. So there is no need to specify a smaller dependency set - everything's already there, you won't change that.
The NETStandard.Library package provides these reference assemblies. One point of confusion is the version number - the package is version 1.6.1, but this does not mean ".NET Standard 1.6". It's just the version of the package.
The version of the .NET Standard you're targeting comes from the target framework you specify in your project.
If you're creating a library and want it to run on .NET Standard 1.3, you'd reference the NETStandard.Library package, currently at version 1.6.1. But more importantly, your project file would target netstandard1.3.
The NETStandard.Library package will give you a different set of reference assemblies depending on your target framework moniker (I'm simplifying for brevity, but think lib\netstandard1.0, lib\netstandard1.1 and dependency groups). So if your project targets netstandard1.3, you'll get the 1.3 reference assemblies. If you target netstandard1.6, you'll get the 1.6 reference assemblies.
If you're creating an application, you can't target the .NET Standard. It doesn't make sense - you can't run on a specification. Instead, you target concrete platforms, such as net452 or netcoreapp1.1. NuGet knows the mapping between these platforms and the netstandard target framework monikers, so knows which lib\netstandardX.X folders are compatible with your target platform. It also knows that the dependencies of NETStandard.Library are satisfied by the target platform, so won't pull in any other assemblies.
Similarly, when creating a standalone .NET Core app, the .NET Standard implementation assemblies are copied with your app. The reference to NETStandard.Library does not bring in any other new apps.
Note that dotnet publish will create a standalone application, but it won't doesn't currently do trimming, and will publish all assemblies. This will be handled automatically by tooling, so again, trimming dependencies in your library won't help here.
The only place I can imagine where it might help to remove the NETStandard.Library reference is if you are targeting a platform that doesn't support the .NET Standard, and you can find a package from the .NET Standard where all of the transitive dependencies can run on your target platform. I suspect there aren't many packages that would fit that bill.
I am working a new project - and I want to do it using the latest .NET Core.
Reading through the documentation, I came across the comparison between Entity Framework Core and Entity Framework 6.x Comparison. Here
Some of the features that I require like: Spatial Data Type is NOT supported by EF Core. So I CAN'T use it, because Spatial Data Type is required in the Project.
Going through the documentation again, I came across this link on How to use EF 6.x with .NET Core: Here
In the article it mentions (Here):
Before you start, make sure that you compile against full .NET
Framework in your project.json as Entity Framework 6 does not support
.NET Core. If you need cross platform features you will need to
upgrade to Entity Framework Core.
I don't really need my project to be cross platform.
The article is not very clear on how to use EF6 with ASP.NET Core.
I created a new ASP.NET Core Web Application
then I installed EF6 using Nuget Package Manager, and got the following error
I went and removed the netcoreapp1.0 from the frameworks in project.json and added net46 as framework, which removed the error for EF, but now I am getting another error.
So how do I use EF6 with ASP.NET core?
When I use EF6 I have to remove all references to .NET Core, does
this mean I am not using .NET Core? What are the disadvantages of this other than it can't run cross platform?
To stop the second error you need to remove the following from the dependencies section of your project.json:
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
}
For reference, the documentation for referencing the full .NET Framework and Entity Framework 6 from an ASP.NET Core project has a full project.json example.
Removing references to .NET Core does not mean you are not using ASP.NET Core. You are only changing the target runtime platform that your ASP.NET Core project will execute on.
Using ASP.NET Core with the full .NET Framework, you get the benefits of the new project structure and unified story for building web UI and web APIs (e.g. unified Controller class), and you also gain access to the mature, fully-featured .NET Framework, enable use of dependencies and NuGet packages which haven't been ported to .NET Core, for example Entity Framework 6.
I'm trying to create a Breeze Web API controller and I'm wondering if it is possible with the default MVC/Web API project template that comes with Visual Studio 2013. Updating everything through the Nuget packet manager installs Entity Framework 6.0.1. Attempting to installing Breeze after that results in an error as it attempts to install EF 5 as a dependency, which is not possible given the fact that other parts of the template depend on EF6.
Do we have to wait for a new version of Breeze that works with EF6?
Edit: I want to do this the "breeze way" using [BreezeController] and Odata.
I just wanted to add that even without EF6.1, the MVC 5 updates released today with VS2013 also break breeze. It's hard to separate the pieces to determine which new piece is responsible. It could be MVC or the new odata. In any case, we anxiously anticipate the new version.
Updated 10/29/13
As of now, Breeze 1.4.5 has support for Microsoft's ASP.NET WebApi 2 and Entity Framework 6. Please see http://www.breezejs.com/documentation/download.
Older post:
We don't yet support EF6 but it is coming ... soon...
There is a new package called Breeze.WebApi2 that is compatible with Web API2 and EntityFramework 6. It makes some of the existing Breeze packages obsolete. See http://www.breezejs.com/documentation/start-nuget for details.