I got from https://github.com/dotnet/corefx/issues/3633, that XSD Schema Validation now is not yet supported, and planned in .Net Core 1.2.0 whose release date is Spring, 2017.
However it's one of the key features of our product, so it somehow has to be supported. Now .Net Standard doesn't even have System.Xml.Schema when we thought to temporarily use full .net core, yet doesn't help.
Before v1.2.0, is there any workaround to do the xsd schema validation?
If you need some functionality that needs to be run in .Net Core library, you may try to port your product with portable library workaround.
However, it's nearly the .NET Core 2.0 Preview time, so you may basically wait for it.
Related
Does OxyPlot.Wpf work on .NET Core?
My application uses .NET Framework 4.8. I am considering switching to .NET Core 3.1.5 which was released in 2020 June.
Note OxyPlot has an assembly called OxyPlot.Core but it has nothing to do with .NET Core from what information I have gathered. OxyPlot.Core is "the core library... you also need to add a platform-specific OxyPlot package". This makes it seem that OxyPlot.Wpf depends upon OxyPlot.Core and in fact if you try to uninstall OxyPlot.Core the error will be "unable to uninstall OxyPlot.Core.2.0.0 because OxyPlot.Wpf.2.0.0 depends on it". The online documentation does not seem to tell you this but fortunately NuGet will prevent the uninstall.
This means OxyPlot.Core is the core of OxyPlot and its existence does not necessarily tell you anything explicit about .NET compatibility.
I'd say yes it is compatible. Based on the nuget link https://www.nuget.org/packages/OxyPlot.Wpf
Think you Will find OxyPlot works fine with Wpf .NET Core .. but I cannot say the same for a Winforms .NET Core project I have; at the present time I am having (the usual) enormous difficulty in making it work
My project is completely designed with. NetCore 2.2 and. Netstandards2.0. I need to refer
Microsoft.Xrm.SDK. But Microsoft.Xrm.SDK supported by full framework. I have tried to. NetCore 3.1 also no luck. I have gone through many articles, every one saying now only they start releasing the alpha version. There is only a roadmap so far.
As you already found, the .NET Core version is in Alpha release.
This is an update article to the right packages to use:
https://colinvermander.com/2020/02/13/net-core-cds-sdk-alpha-availability/
Regarding your project, you can eventually include all the calls to Dynamics 365 to a separate project/assembly so the rest of the project can be compatible with .NET Core and only that specific project/assembly to the full .NET
Entity Framework Core does not support spatial data, which I need to use in my app.
Can I use Entity Framework 6 in .net core? If so, how can I register DatabaseContext in Startup.cs?
Update
You can now use EF 6.3 with .NET Core 3.0:
https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0-and-ef-6-3-general-availability/#what-s-new-in-ef-6-3
Below is an excerpt. However, EF Core has come a long way these days and it's worth giving it another go before going back to something that's reaching end-of-life soon. Specifically for your issue, EF Core supports mapping to spatial data types using the NetTopologySuite spatial library since version 2.2.
What’s new in EF 6.3
Support for .NET Core 3.0
The EntityFramework package now targets .NET Standard 2.1 in addition to .NET Framework 4.x.
This means that EF 6.3 is cross-platform and supported on other operating systems besides Windows, like Linux and macOS.
The migrations commands have been rewritten to execute out of process and work with SDK-style projects.
Support for SQL Server HierarchyId.
Improved compatibility with Roslyn and NuGet PackageReference.
Added ef6.exe utility for enabling, adding, scripting, and applying migrations from assemblies. This replaces migrate.exe.
There are certain limitations when using EF 6.3 in .NET Core. For example:
Data providers need to be also ported to .NET Core. We only ported the SQL Server provider, which is included in the EF 6.3 package.
Spatial support won’t be enabled with SQL Server because the spatial types aren’t enabled to work with .NET Core.
Note that this limitation applies to EF 6.3 but not to EF Core 3.0. The latter continues to support spatial using the NetTopologySuite
library.
There’s currently no support for using the EF designer directly on .NET Core or .NET Standard projects.
Original Answer
It isn’t ready yet, but starting with .NET Core 3.0, you will be able to.
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/
Similarly, EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6.
https://youtu.be/GN54OV5cCBM?t=1146
But there's also EF6, which we've already announced is going to be ported to work on .NET Core...
UPDATE: Yes, EF6 has been cross-platform since version 6.3. https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0-and-ef-6-3-general-availability/#what-s-new-in-ef-6-3
ORIGINAL ANSWER THAT IS NOW INVALID: No, you can not directly, because EF6 doesn't support .NET Core.
But, you can create another project, that compiles against full .NET framework and use it as a reference.
MS has actually made a decent tutorial for this:
https://learn.microsoft.com/en-us/aspnet/core/data/entity-framework-6#reference-full-framework-and-ef6-in-the-asp-net-core-project
UPDATE: Yes, EF6 has been cross-platform since version 6.3. https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0-and-ef-6-3-general-availability/#what-s-new-in-ef-6-3
ORIGINAL ANSWER THAT IS NOW INVALID: Like #Niko said, you cannot directly with EF6 but there is a fork that allows it.
Disclaimer: I'm the owner of the project Entity Framework Classic
Entity Framework Classic is an EF6 fork. It's everything you like about EF6, but with better performance, must-have features, .NET Core support, and more.
There is a FREE Community version that includes pretty much everything and an Enterprise version that include additional features.
Actually, I want to update old 'nhibernate' version used in my ASP .Net project to its latest stable version i.e. 4.0.0.4000.
However, in this process, I am facing problem.
Currently, Target .Net Framework of my project is .Net 3.5 and with that nhibernate 2.1.2.4000 is used.
For updating the same, I have simply replaced the NHibernate.dll assembly with its 4.0.0.4000 version(downloaded from SourceForge).
However, with .Net 3.5 target framework and nhibernate 4.0.0.4000, I am receiving a number of errors related with missing definition of Type/Namespace like Criterion, Engine, SqlCommand, Type, Cfg, Impl, Metadata etc.
Also, on changing Target Framework to .Net 4.0 or higher and nhibernate 4.0.0.4000, almost all the errors gets removed.
So, it seems that nhibernate 4.0.0.4000 is not compatible with .Net 3.5 Framework. Am I correct?
If so, which max version of nhibernate can be used with .Net 3.5 Framework?
If not, please confirm what could possibly causing these errors and how it can be evited.
Also, please confirm the min .Net framework required for using nhibernate 4.0.0.4000. Let me know if there is any other information I needs to be aware of.
Lastly, please confirm if process of updating nhiberate is correct or not?
Thanks in advance.
Regards,
Shubham
Yes, that's right: NHibernate 4 only targets .NET 4. You can see that in the release notes: https://github.com/nhibernate/nhibernate-core/blob/master/releasenotes.txt.
I've seen videos introducing ASP.NET vNext and been keeping up with the recent announcement blog posts, but detailed information on what's been stripped from the full framework appears slim. Here's what I think I know so far:
It's much smaller (11MB vs >200MB): http://davidzych.com/2014/05/24/getting-started-with-asp-net-vnext/
Strong naming is gone: http://jeremydmiller.com/2014/06/09/final-thoughts-on-nuget/
It's dumped System.Web
It includes a merged MVC and WebAPI (however I don't believe this is part of the framework itself but rather dependencies that can be specified)
Dependencies are completely managed through project.json, to the extent that the base
Are we basically looking at a framework that basically includes nothing more than what's in mscorlib in the full framework, with all else delivered via package management? And if this is the case, why would one need to target the framework specifically, as described here? http://blogs.msdn.com/b/webdev/archive/2014/06/17/dependency-injection-in-asp-net-vnext.aspx
The reason they specifically target NET45 in the link you supplied is because AutoFac is built for and has a dependency on .NET 4.5. Without NET45 the code wouldn't compile.
My assumption is that once vNext gets closer and closer to release the Autofac (and StructureMap, and Castle Windsor, and ...) will release a version that targets the cloud optimized framework to remove the dependency.
As far as I understand, .Net Framework is the fully framework we know and love with all the Windows implementations and lots of code we don't normally use, like they explain in some videos an XML parser.
In .NET Core they removed all the unneeded implementations/dependecies and only left the basic ones. which also enables cross platform (not yet), so in the future one could think as the only framework : CORE Framework, and run on any device. Their february community standup give a lots of information and insight on their objectives and goals.
I see this as a transition, when some features are available only on the full Framework while in the futures one might expect to see all features available for .NET Core.
From a Microsoft perspective, if they want to release lets say Entity Framework for mobile (EF7 is aiming at that) they must get rid of all the windows implementations, on EF and it's dependencies (Framework). So they created a non-windows dependency on the framework, which also helps the multiple framework install and remove some problems with updating the framework by having them mostly isolated from the system, lying in the application. New problems will come like multiple copies of the same framework on one machine per application, that's why they are working on something called Smart Sharing.
This post may help you and give you some insight specially this part :
The structure of .NET Core is comprised of two major components which
add to and extend the capabilities of the .NET Framework as follows:
Runtime:
Built on the same codebase as the .Net Framework CLR. Includes the
same GC and JIT (RyuJIT) Does not include features like Application
Domains or Code Access Security. The runtime is delivered on NuGet
(Microsoft.CoreCLR package)
Base class libraries:
Are the same code as the .Net Framework class libraries but do not
contain dependencies so have a smaller footprint. Available on NuGet
(System.* package)
and I guess you already read Introducing .NET Core from Microsoft.
Regarding your concern about specifying a specific framework is because right now, not everything works on Core CLR so you must choose which one to use, or you can target both and use different implementations.
As of right now, CORE only runs on Windows; the mono framework doesn't have a SQLLite provider for entity framework but it does on Core, so you can use an InMemory or Azure EF provider for example, and choose depending on the enviroment your application is running.
As Scott Gu says on the community standup, they envision a future where there's no mono framework or full framework, there's just Core, but that will take time if it ever happens.
I can't find an original source other than a comment by David Fowler (I believe) on a presentation from NDC, but CoreCLR used by the K Runtime is actually a reincarnation of the CLR used by Silverlight 2. It was used because it's small and designed to be cross platform. There is some additional information here: https://stackoverflow.com/a/25720160/113225