[WIP] NH-3807 Support for .NET Core 1.0 #504
Conversation
|
Great work. Would it make sense to factor NHibernate's functionality into smaller components (assemblies) so that some components may run on netstandard while others would only run on a full framework? |
|
The most obvious part that could be sliced off is the Most likely an alternative approach will have to be made where the NHibernate hbm2ddl functionality, that is schema synchronization, knows how to talk to the database meta-tables instead of relying on the driver to do it. This may be easier if it is already refactored into a separate library. For example, Entity Framework Core talks to each kind of database through SQL commands to get the database metadata: /Microsoft.EntityFrameworkCore.Sqlite.Design/Internal/SqliteDatabaseModelFactory.cs. Another part that is a possibility, is how the various database drivers are demand loaded through reflection. I don't know if they will all be consistent over to the .Net Core world and it might make sense to have each type of database support refactored out into separate libraries. The database support libraries could then link for real with their respective drivers and pull them down from NuGet as dependencies. I hope you can join in and see what can be done. |
Microsoft has recently stated that they are adding back the full data API of .NET Framework for .NET Standard 2.0, so these scenarios will certainly be supported again in the first half of 2017. |
|
@mattzink Yes, they seem to be adding serialization back in, but that is the least of NHibernates problems. There has been no commitment to bringing I think the path forward is to get at least some of the tests running without requiring dynamic schema generation, and then start working on pulling each database schema in implementation specific ways instead of relying on ADO.Net. Any thoughts on this? Would any database's schema and hbm2ddl methods benefit by being more database specific rather than relying on ADO.Net providers? |
|
Right now it looks like many of the dialects rely on AbstractDatabaseSchema to do most of the work of getting the schema. Would it be possible to have that class expose utility methods for querying INFORMATION_SCHEMA? |
|
Microsoft has announced their direction on .NET Standard 2.0. Basically, they are adding back
What is NHibernate's position for the future going to be? I've heard from companies I work with that they liked NHibernate in the past, but are moving to Entity Framework because it runs on .NET Core. How is NHibernate going to stay relevant? |
|
By doing the same, I would say. /G 2016-09-29 16:08 GMT+02:00 Nathan Brown [email protected]:
|
|
can we resue Microsoft.Data? |
|
@hazzik It's not so much as there is a library to re-use, but that Entity Framework itself implements whatever it needs to that was missing. |
|
Do I understand correctly that with .NETStandard 2.0 only the minimal work will be required? |
|
I'm having an issue with Antlr3.Runtime being compatible with .Net Standard 1.6.. how do you get it compile? Did you just include "dnx451"? I want to get it to work cross platform, do we need to upgrade to antlr4.runtime (which seems to be compatible with aspnet core)? |
|
@ssinno28 I used It's from my own branch https://github.com/ngbrown/antlrcs/tree/fix-version which is mostly just fixes to the |
|
Any follow-up? |
|
Adding the nuget package URL worked.. Since VS 2017 RC came out I've been having issues with the new way they are using the .csproj... For whatever reason it is refusing to build.. going to wait until the nhibernate team decides to convert it to .Net core which is when .Net standard 2.0 is getting released.. |
…ly replacing NET_2_0's SecurityPermissionAttribute
…String. FormatterConverter has been removed from CoreClr.
So we don't have to #if #endif around every single usage. Adds minimal implementation of: DesignerCategoryAttribute IntrospectionExtensions NonSerializedAttribute SerializableAttribute RuntimeReflectionExtensions IntrospectionExtensions InvalidExpressionException
ApplicationException has been removed from CoreClr.
Array.ConvertAll has been removed from CoreClr.
…verride in CoreCli. Instead of Close on DbDataReader, enclose in using() blocks.
…rectory instead of AppDomain.CurrentDomain.BaseDirectory. Added shim for easier use with .NET 4.0.
…ll and implementations of ITableMetaData.
…lt to NonBatchingBatcherFactory on CoreClr.
|
@ngbrown I'm going to rebase your changes on top of master (it means drop some of the commits) and migrate to VS2017 format. |
|
Rebased on top of master & converted to VS2017 (.NET SDK 1.0.1) |
|
Closing this for now. Thanks for the great work, @ngbrown. |
|
@DarkLx no. This PR was targeting .NET Core 1.0. NHibernate is going to support .NET Core 2.0 and the work required is hardly intersected with this PR (most of this is not required). |
|
@hazzik |
|
I don't think that you can even compile this version:) So, - no.
…On Mon, 1 May 2017 at 4:53 PM, lx ***@***.***> wrote:
@hazzik <https://github.com/hazzik>
Okay,Thanks for the great work !
Should we use this .NET Core 1.0 version NHibernate on production ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#504 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAI1l7FVPDEV2udLOnv3UmxoXqKDM7G7ks5r1WU3gaJpZM4JpaPY>
.
|
|
@hazzik |
Link to the NH-3807 issue in Jira
This is currently a work in progress. It does compile and I have ran simple programs against it.
A majority of the changes were done to the mainline .NET version so all the mainline tests could be used during development. There are no tests ported to .NET Core yet, and this may be difficult without the dynamic schema support.
By necessity, it includes
#241/NH-3431 - Replace System.Data with System.Data.Common andNH-3853 - Switch binary-serialization to an implementation that is supported by CoreClr.There are a number of compromises that have to take place on .NET Core, chief among them is that there is no
GetSchemaTable(). Without this, none of the dynamic schema generation or updates works. The tests, when implemented, will need a static schema checked into the repository for database restoration.I think that NHibernate has a number of great features above what Entity Framework is providing and this prevents the choice of .NET Core as being the deciding factor against NHibernate.
Please try this branch out and work to help make it a reality.
Conditional Compilation Symbols
(source for table)
The following conditional compilation symbols (vertical) are currently defined for each of the build configurations (horizontal):
FEATURE_ADONET_SQLCOMMANDSETFEATURE_APPDOMAINFEATURE_ASSEMBLYBUILDER_SAVEFEATURE_BINDINGLISTFEATURE_CODEDOMFEATURE_DATA_CLOSEFEATURE_DATA_GETCOLUMNSCHEMAFEATURE_DATA_GETSCHEMATABLEFEATURE_DBPROVIDERFACTORIESFEATURE_INTERNALIZE_IESIFEATURE_NETCORE_ICLONEABLE_APIFEATURE_NETCORE_REFLECTION_APIFEATURE_ODBC_OLEDBFEATURE_REFLECTEDTYPEFEATURE_REMOTINGFEATURE_SECURITY_PERMISSIONSFEATURE_SERIALIZATIONFEATURE_STRING_INTERNFEATURE_SYSTEM_CONFIGURATIONFEATURE_SYSTEM_SERVICEMODELFEATURE_SYSTEM_TRANSACTIONSFEATURE_WEB_SESSION_CONTEXTFEATURE_XML_SCHEMASFEATURE_XML_VALIDATIONEVENTHANDLERNET_4_0NETSTANDARDFEATURE_ADONET_SQLCOMMANDSET- enables support for accessing the internal SqlCommandSet for batching. Otherwise, no batching is enabled.FEATURE_APPDOMAIN- enables support for features that make use of an AppDomain in the host.FEATURE_ASSEMBLYBUILDER_SAVE- enabled support for saving the dynamically generated proxy assembly.FEATURE_BINDINGLIST- enables support features that make use of System.ComponentModel.BindingList.FEATURE_CODEDOM- enables support for CodeDom providers such as CSharpCodeProvider.FEATURE_DATA_CLOSE- enables support for DbDataReader.Close(). .NET Core doesn't have thisFEATURE_DATA_GETCOLUMNSCHEMA- .NET Core has IDbColumnSchemaGenerator.GetDbColumnSchema on the DbDataReader implementations.FEATURE_DATA_GETSCHEMATABLE- DbConnection has GetSchema implementation and DbDataReader has GetSchemaTable. .NET Core has IDbColumnSchemaGenerator.GetDbColumnSchema on the DbDataReader implementations.FEATURE_DBPROVIDERFACTORIES- Has DbProviderFactories with globally registered DB providers. Otherwise needs driver assembly with specific name.FEATURE_INTERNALIZE_IESI- Since NHibernate 4.0, only LinkedHashSet has been used from Iesi.Collections. We can internalize this and not refer to an external assembly.FEATURE_LEGACY_REFLECTION_API- provides a shim for .NET 4.0 that emulates theTypeInfoAPI available in .NET 4.5+ and .NET Core.FEATURE_NETCORE_ICLONEABLE_API- provides shims for missing ICloneable interfaceFEATURE_NETCORE_REFLECTION_API- provides shims to implement missing functionality in .NET Core that has no alternatives.FEATURE_ODBC_OLEDB- enables support for features that make use of System.Data.Odbc or System.Data.OleDb.FEATURE_REFLECTEDTYPE- Get more precise information from what type a MemberInfo was retreived. Used in MapByCode, but not available in .NET Core.FEATURE_REMOTING- supports remoting on various types including inheriting from MarshalByRefObject. Both System.Runtime.Remoting and WCF System.ServiceModel.FEATURE_SECURITY_PERMISSIONS- enables the use of CAS and Security[Critical|SafeCritical|Transparent].FEATURE_SERIALIZATION- enables support for serialization of dynamic proxies and other types.FEATURE_STRING_INTERN- enables support for string.Intern()FEATURE_SYSTEM_CONFIGURATION- enables features that use System.Configuration and the ConfigurationManager.FEATURE_SYSTEM_SERVICEMODELenables features that use System.ServiceModel such as WCF and OperationContext.FEATURE_SYSTEM_TRANSACTIONS- enables features that use System.Transactions.FEATURE_WEB_SESSION_CONTEXT- enables WebSessionContext and relies on System.Web.HttpContext.FEATURE_XML_SCHEMAS- enables features around XmlSchema including XmlSchemaSetFEATURE_XML_VALIDATIONEVENTHANDLER- enables handling ValidationEventHandler events.