You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chris_x created an issue — 7th July 2015, 9:52:17:
I'm pretty sure this has already been discussed internally, but I can't find it anywhere on JIRA.
I think it would make a lot of sense if NHibernate were to support .NET Core as target platform in the foreseeable future to enable cross-platform development. I understand that this might be a huge task involving even more aggressive cleanup of legacy code and possibly (probably) some breaking changes, but would go a long way to keep NH relevant. EF 7 will support it (duh), which will definitely give it an edge over NH...
I for one am certainly considering making the switch over to EF 7 for new projects just for that reason, even though NH is still much more powerful and flexible (and I have experience with it).
Johannes Rauber added a comment — 27th February 2016, 19:50:04:
Current dependencies are Antlr3 and Remption.Linq or did i miss some?
PCL Profiles in the current nuget Packages:
Alexander Zaytsev added a comment — 27th February 2016, 21:32:29:
<~jrauber> We will update relinq to 2.0 by the version 5 of NHibernate. But anyway these packages are inlined, with some plans to make relinq external via nuget.
Johannes Rauber added a comment — 28th February 2016, 1:17:53:
If i understood it right the PCL Profiles above are compatible, so going down this route and creating an "old" PCL-Project for an nhibernate port would have been an option. As the Summary shows that the netcore45 and wpa81 would impose some higher degree of needed changes the direct move seems to be the better option. As the dependencies are already targeting compatible profiles both are not blocking the port, so a switch to relinq 2.0 is not mandatory. Whats your point of view?
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Either 1) Delete Serialization info from exceptions (since this can't be remoted) or 2) Use a different serialization technology if not for exceptions.
Currently there is no workaround, but we are working on it. Please check back.
T:System.Reflection.MemberTypes
T:System.Reflection.MemberTypes
NHibernate
Not supported
"Use typeof(), ""is FieldInfo"", ""is PropertyInfo"" to reason about the Member's type. Example: if (membertype == membertypes.Field) --> if (member is FieldInfo)."
T:System.Xml.Schema.XmlSchemaSet
T:System.Xml.Schema.XmlSchemaSet
NHibernate
Not supported
Currently there is no workaround, but we are working on it. Please check back.
T:System.Xml.Schema.XmlSchemaSet
M:System.Xml.Schema.XmlSchemaSet.#ctor
NHibernate
Not supported
Currently there is no workaround, but we are working on it. Please check back.
Currently there is no workaround, but we are working on it. Please check back.
T:System.Environment
M:System.Environment.get_Version
NHibernate
Not supported
Use System.Runtime.InteropServices.FrameworkDescription instead
T:System.IO.Stream
M:System.IO.Stream.Close
NHibernate
Not supported
Use Dispose() instead.
T:System.Reflection.MemberInfo
M:System.Reflection.MemberInfo.get_MemberType
NHibernate
Not supported
"Use typeof(), ""is FieldInfo"", ""is PropertyInfo"" to reason about the Member's type. Example: if (membertype == membertypes.Field) --> if (member is FieldInfo)."
T:System.Reflection.MemberInfo
M:System.Reflection.MemberInfo.get_ReflectedType
NHibernate
Not supported
Remove usage: As CAS is not supported in newer frameworks, this property no longer has meaning.
Use a different constructor that does not take ExpressionType. Then override NodeType and Type properties to provide the values that would be specified to this constructor.
Ricardo Peres added a comment — 28th February 2016, 15:23:52:
Guys, I don't think this will ever happen. .NET Core misses lots of stuff, and some, it will probably always miss.
Alexander Zaytsev added a comment — 29th February 2016, 6:48:27:
<jrauber> I saw this. Thanks
[rjperes] it is not possible to do through PCL, but still doable through .NET Core itself.
Johannes Rauber added a comment — 29th February 2016, 13:31:30:
I created the following Tasks NH-3853, NH-3854 and NH-3855 which structure the major findings I had when looking through the output of api-port. Could you please link them to this Feature?
Alexander Zaytsev added a comment — 29th February 2016, 13:38:55:
<~jrauber> done
Ricardo Peres added a comment — 29th February 2016, 13:56:03:
<~hazzik>: .NET Core will never, at least, in the foreseeable future, have ADO.NET/System.Data, so it will never be possible to port NHibernate.
chris_x added a comment — 29th February 2016, 17:34:08:
<~rjperes> How about porting NH to System.Data.Common (NH-3431)? I see you have spoken in favor of it yourself.
Alexander Zaytsev added a comment — 29th February 2016, 20:41:10:
<rjperes>, Chris is correct. Indeed .NET Core does not support System.Data IDb interfaces (IDbCommand, IDbConnection, IDb..., these are ADO.NET 1.0, and they are sealed as you can not change interface definitions), but does support counterpart abstract classes from System.Data.Common. We will do the NH-3431 task anyway for the introduction of async/await support.
Another thing which is not supported is DataSet/DataTable/DataView, which we have dependencies on. There are some hard debates between <fransbouma> (for his own benefit of LLBLGen Pro) and .NET Core team to reintroduce these classes back to the framework in some form.
Frans Bouma added a comment — 29th February 2016, 21:01:47:
MS recently added the IDb* interfaces to .NET core (will be there in RC2), and a stub for DataTable. They're planning to add DataTable later on, and have added an API for schema retrieval on datareader, so it's something ;) Still .NET core isn't really usable for a full ORM without a lot of compromises at v1.0
FB
chris_x added a comment — 29th February 2016, 22:40:41:
<~fransbouma> What kind of compromises? I understand porting won't be easy, but your statement seems a little vague to me. Besides, EF 7 supports CoreFX, and that is a "full" ORM too (for whatever that means).
And no, the (de facto deprecated) DataSet stuff is not a necessity for a "full" ORM. It's just hard to refactor existing code that depends on it.
Frans Bouma added a comment — 29th February 2016, 22:55:48:
micro vs. full, I hope I don't have to create a long list of things to illustrate the difference? ;)
Compromises: it's not that hard to materialize entities from a datareader, nor create some queries, but a lot of the services in full ORMs are built on functionality that's not there (yet) and thus needs to be written differently or to be cut out, which means you need to do a lot of work to add a lot of #ifdef's to make your code compile (and your tests run). I mean, which ADO.NET provider do you want to use with no ADO.NET provider available besides SQL Server and a stripped down npgsql 'alpha' built?
I didn't say that dataset is necessary, I think? For metadata retrieval / schema information regarding resultsets, you do need datatable though or at least a replacement api on datareader. This is 'being worked on', but not there yet.
Anyway, I'm just replying here because someone included me in the thread and I saw some remarks which were spreading outdated info (but as MS is vague and has recently updated things, you guys likely didn't know this, so no blame there, I just happened to know a few bits) and have no intention to participate in NHibernate discussions as in the past they weren't very pleasant so I don't tend to stick around here longer than absolutely necessary.
Cheers,
Frans
Alexander Zaytsev added a comment — 29th February 2016, 23:30:27:
<~fransbouma> sorry for casting you in, indeed I did not read all your conversations with MS about the problem, I just noticed that you was the first to rise the very valid points about absence of some of crucial classes. So I brought you in, as the person who knows something more about the state of these items.
I can see that they have added IDb interfaces just 6 days ago.
Also, I'm very sorry, that you had had bad experience with NH community before. But we have changed and do not want to be so rude as we was before.
.
Frans Bouma added a comment — 1st March 2016, 16:23:30:
Hey Alexander,
Sorry about that, it's not fair of me to judge current management by looking at the previous management ;)
Anyway, here's what I know:
ADO.NET is owned by the SQL Server team. They're not really doing OSS (yet), and there are only 2 (!) team members on github doing work there, communicating with us outsiders, and that's of course a cumbersome process. It's not that they're not willing to change things or listen, (although it looks like that), it's that the current way of how they do things over there is pretty limited. There's a lot of push within MS to change this, so let's hope these people get their way and things open up more. Another annoying problem is that ADO.NET is designed from the PoV of SQL Server, and I've addressed this with MS personell and they've assured me this is something they try to avoid with the new bits, so let's hope they succeed.
For v1.0, things are pretty limited, with respect to ADO.NET, although interfaces are in. E.g. DbProviderFactory isn't implemented yet (although the class is there, there's no system designed how to get it working!). Basically what EF7 needs at v1 is in, the rest is on the back burner or is hastly added due to pressure from the community (e.g. by stackoverflow). This e.g. led to the addition of a proper API to DbDataReader for resultset schema retrieval, as there's no DataTable. (although they're looking at adding that, in a cutdown version as it's tied to databinding crap in .net full)
Rule of thumbs seems to be: use Interfaces (the ones added a couple of days ago) for code that also has to run on .net full, and use the base classes for code that's specific for .net core.
I'm currently waiting for v1.0 RTM tooling before I start porting one of the ORMs I manage as I hate working with a truckload of files scattered all over the place instead of letting an IDE do that work.
Cheers,
Frans
Ricardo Peres added a comment — 1st March 2016, 17:01:04:
Hi, <~fransbouma>!
You are right; I've been trying to tell the other guys: don't expect ADO.NET (as we know it) to be available any time soon in .NET Core. There have been recently - yesterday - discussions in the Microsoft mailing lists about this, and that was the general idea.
Johannes Rauber added a comment — 1st March 2016, 22:55:09:
Thanks to <~fransbouma> there is movement that might be enough to port. Currently DataTable is only used in conjunction with the Meta-Data-Retrieval for example in AbstractDataBaseSchema.cs or OracleMetaData.cs.
Mathieu Decelles St-Pierre added a comment — 21st July 2016, 0:26:54:
Please ignore Readme.txt attached file. My mistake.
Oskar Berggren added a comment — 21st July 2016, 8:58:49:
Bogus attachment Readme.md removed.
Nathan Brown added a comment — 6th August 2016, 22:56:46:
Antlr4 has an (antlr/antlr4#1142) to make the runtime compatible with .NET Core. Something similar would have to be done for Antlr3. Or would upgrading to Antlr4 be preferable?
Nathan Brown added a comment — 21st August 2016, 22:49:27:
I've submitted a pull request to get this effort started: #504
It's a work in progress, but shows what's possible and what sort of compromises need to be taken.
Input from the development team will be needed, especially around how to proceed with the unit test and lack of Schema support.
Nathan Brown added a comment — 24th August 2016, 13:16:17:
I responded to a comment on the (#504), and am cross-posting it here for the core developers. The question was if there was any opportunity to refactor some of NHibernate into separate libraries.
The most obvious part that could be sliced off is the NHibernate.Tool.hbm2ddl namespace and the associated NHibernate.Dialect.Schema namespaces. These areas currently do not work as written with .Net Core and it's questionable if they ever will. See <dotnet/corefx#3423>(https://github.com/dotnet/corefx/issues/3423] and [dotnet/corefx#5024|https://github.com/dotnet/corefx/issues/5024).
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.
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.
Nathan Brown added a comment — 29th September 2016, 14:08:21:
Microsoft has announced their direction on <.NET Standard 2.0>(https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/). Basically, they are adding back BinaryFormatter for serialization, but appear to be totally removing System.Data. NHibernate worked with serialization, but didn't really depend on it for any major functionality. It does however heavily depend on System.Data.
Entity Framework has pulled everything it needs out of System.Data and put it into Microsoft.Data. See <dotnet/efcore#2665>(dotnet/efcore#2665).
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?
hidegh added a comment — 28th November 2016, 15:59:43:
There were 2 issues to solve with NH 4.0 on asp.net core (targetting full .NET framework):
session context for web
distributed transactions
session context for web
Easy to solve, create a class like defined below.
Make sure NH is configured to use this new MapBasedSessionContext.
Ensure IHttpContextAccessor is initialized inside web, with code
The fluent configuration in this comment (last code block) refers to this class via string: sessionContextType.AssemblyQualifiedName
namespaceMyProject.Domain.Persistence.Patch
{
/// <summary>/// NOTE: I've tried to instantiate HttpContextAccessor here, directly (so not from the AspNetCore.Startup) and that just did not worked.../// </summary>publicclassAspNetCoreWebSessionContextConfiguration
{
privatestaticIHttpContextAccessor_httpContextAccessor;
publicstaticIHttpContextAccessorHttpContextAccessor
{
get { return_httpContextAccessor; }
set
{
if (_httpContextAccessor != null)
thrownewException("AspNetCoreWebSessionContextConfiguration.HttpContextAccessor was already set!");
_httpContextAccessor = value;
}
}
}
/// <summary>/// Provides a <see cref="ISessionFactory.GetCurrentSession()">current session</see> for each System.Web.HttpContext. Works only with web applications./// Fix applied from: http://stackoverflow.com/questions/35440413/mvc6-dnx451-nhibernate-nullreferenceexception-on-hasbind/35521257/// </summary>
<Serializable>
publicclassAspNetCoreWebSessionContext : MapBasedSessionContext
{
privateconststringSessionFactoryMapKey = "NHibernate.Context.WebSessionContext.SessionFactoryMapKey";
publicAspNetCoreWebSessionContext(ISessionFactoryImplementorfactory) : base(factory) { }
protectedoverrideIDictionaryGetMap()
{
returnAspNetCoreWebSessionContextConfiguration.HttpContextAccessor.HttpContext.Items<SessionFactoryMapKey> asIDictionary;
}
protectedoverridevoidSetMap(IDictionaryvalue)
{
AspNetCoreWebSessionContextConfiguration.HttpContextAccessor.HttpContext.Items<SessionFactoryMapKey> = value;
}
}
}
The distributed transaction issues
There's a flushing problem in NH4.0 than is addressed in NH4.1, so even with this fix in NH4.0 I always flushed before promoted my transaction to distributed one. Anyhow, the DTC problem was solved by using the AdoNetTransactionFactory.
Configuring (fluently of course)
_configuration = Fluently.Configure()
.Database(persistenceConfigurer)
.Mappings(m =>
{
// add conventionsm.FluentMappings.Conventions
.SpecialRegistrationFromAssemblyOf<TableNameConvention>(
namespaceToDbSchemaConvertor ?? newNamespaceToDbSchemaConvertor())
.Add(DefaultCascade.SaveUpdate());
// add our fluently mapped entitiesm.FluentMappings.AddFromAssemblyOf<IMappingContainer>();
// we can export the hbm.xml generated from our fluent configuration to a directory// (directory must exists and be writable)if (!string.IsNullOrWhiteSpace(hbmXmlExportDirectory))
m.FluentMappings.ExportTo(hbmXmlExportDirectory);
})
.CurrentSessionContext(sessionContextType.AssemblyQualifiedName)
.ExposeConfiguration(c =>
{
// TO make DTC work while using TransactionScope and NHibernate...c.SetProperty(NHibernate.Cfg.Environment.TransactionStrategy, "NHibernate.Transaction.AdoNetTransactionFactory");
Hope this helps.
Nathan Brown added a comment — 4th December 2016, 4:30:11:
<~hidegh> Are you referring running code from the NH-3807 branch, or from the main-line NHibernate releases on Asp.Net Core?
If you are trying to say that you got standard NHibernate running on Asp.Net Core, with minimal modifications, than you are almost certainly running on the full-fat .NET Framework. It's not until .Net Core -1.2- 2.0 comes out in 2017 that NHibernate will be easily ported an the .Net Core framework. This will mean the ability to run on Windows Server Core, Linux, and MacOS.
Nathan Brown added a comment — 4th December 2016, 4:43:55:
.Net Standard 2.0 and .Net Core -1.2- 2.0 will be adding almost all the APIs missing from earlier versions of the .Net Core efforts back in. This means most of my earlier work will be negated and the port will be much more straightforward.
<^ApiPortAnalysis.html>
You can see the portability report attached. The summary is that there are still a few APIs that are not going to be portable. These include the ConfigurationManager, ConnectionStringSettings, IConfigurationSectionHandler, System.Runtime.Remoting.Messaging.CallContext, some reflection emit create type stuff, anything OleDb (being retired anyways), OdbcConnection, OdbcCommand, and DbProviderFactories.
With NHibernate version 5 now targeting 4.6.2, any .Net Core conversion should be fully compatible, so we should work to split this functionality off into separate assemblies instead of multiple configurations with #ifdef.
It looks like good candidates would be an Xml/AppConfig configuration adapter and database specific clients instead of generically using DbProviderFactories.
By having an assembly per supported database client, we can also pull in those client assemblies through NuGet and have straightforward dependency management.
Thoughts?
Alexander Zaytsev added a comment — 17th April 2017, 4:35:42:
Retarget to .NET Core 2.0
Jon Miller added a comment — 26th April 2017, 21:04:18:
So, DbProviderFactories is not being ported to .NET Core by Microsoft? Anyone know why this is? I have no idea why Microsoft always tries to push people into using the DBMS specific classes (other than vendor lock-in that is). It seems kind of dumb to me that they would drop support for this.
Nathan Brown added a comment — 3rd May 2017, 3:39:54:
So the preview release for .NET Core 2.0 is on <May 10th>(https://github.com/dotnet/corefx/issues/17619]. Has anyone tried the [daily builds|https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md) with NHibernate?
I think that between the preview and release is the most viable time to get in and hope to make any significant tweaks that NHibernate may need.
Should there a branch set aside for .NET Core 2.0 work? Or is the idea that it will be on master?
Alexander Zaytsev added a comment — 3rd May 2017, 3:48:09:
I tried. The problem that BuildTools do not want to build our project without full version of VS.
Alexander Zaytsev added a comment — 3rd May 2017, 3:52:59:
So basically the exercises is like following:
Convert projects to new shiny VS2017 format (except NHibernate.Test.VisualBasic, as VB is not yet supported). One failed attempt is here: #605
Make the build working
Replace net461 with netcoreapp2.0;net461
Guard all red code with #if !NETCOREAPP_20
Alexander Zaytsev added a comment — 3rd May 2017, 3:56:26:
Should there a branch set aside for .NET Core 2.0 work? Or is the idea that it will be on master?
We'll do it through the normal PR model. Then eventually merge to master.
Nathan Brown added a comment — 3rd May 2017, 3:56:47:
I assume you mean it's not working with VS 2017 Community? I haven't tried .NET 2.0 yet, and would normally use Enterprise, but I'll download and try it with Community.
Alexander Zaytsev added a comment — 3rd May 2017, 3:59:44:
Nathan Brown added a comment — 3rd May 2017, 4:15:23:
Hmmm. It's not like BuildTools is a tiny download either. AppVeyor doesn't seem to have a problem having the full Visual Studio installed on their build agents.
For Antr3 in the .NET Core 1,0 version, I had my own custom build, but if the upstream project is supporting it now, hopefully they can get the tooling fixed up.
Alexander Zaytsev added a comment — 3rd May 2017, 6:16:07:
Nathan Brown added a comment — 29th May 2017, 0:07:22:
I think we are close with pull request <#633>(#633). It's currently passing 5,073 of 5,385 tests on Linux. If it could be reviewed and any commits/contributions made to help close the gap, we should be able to have something solid by the time .NET Core 2.0 is released.
aaaa ddd added a comment — 31st July 2017, 12:54:25:
not right place to ask - sorry for that mistake, i'll post in the right repo!
The text was updated successfully, but these errors were encountered:
Hi, when is it expected to release a .NET Standard / .NET Core compliant version of NHibernate? I can see you're actively working on it but couldn't find any information about planned future releases.
chris_x created an issue — 7th July 2015, 9:52:17:
Johannes Rauber added a comment — 27th February 2016, 19:50:04:
Alexander Zaytsev added a comment — 27th February 2016, 21:32:29:
Johannes Rauber added a comment — 28th February 2016, 1:17:53:
Alexander Zaytsev added a comment — 28th February 2016, 4:22:22:
Johannes Rauber added a comment — 28th February 2016, 13:14:06:
Johannes Rauber added a comment — 28th February 2016, 13:15:03:
Ricardo Peres added a comment — 28th February 2016, 15:23:52:
Alexander Zaytsev added a comment — 29th February 2016, 6:48:27:
Johannes Rauber added a comment — 29th February 2016, 13:31:30:
Alexander Zaytsev added a comment — 29th February 2016, 13:38:55:
Ricardo Peres added a comment — 29th February 2016, 13:56:03:
chris_x added a comment — 29th February 2016, 17:34:08:
Alexander Zaytsev added a comment — 29th February 2016, 20:41:10:
Frans Bouma added a comment — 29th February 2016, 21:01:47:
chris_x added a comment — 29th February 2016, 22:40:41:
Frans Bouma added a comment — 29th February 2016, 22:55:48:
Alexander Zaytsev added a comment — 29th February 2016, 23:30:27:
Frans Bouma added a comment — 1st March 2016, 16:23:30:
Ricardo Peres added a comment — 1st March 2016, 17:01:04:
Johannes Rauber added a comment — 1st March 2016, 22:55:09:
Mathieu Decelles St-Pierre added a comment — 21st July 2016, 0:26:54:
Oskar Berggren added a comment — 21st July 2016, 8:58:49:
Nathan Brown added a comment — 6th August 2016, 22:56:46:
Nathan Brown added a comment — 21st August 2016, 22:49:27:
Nathan Brown added a comment — 24th August 2016, 13:16:17:
Nathan Brown added a comment — 29th September 2016, 14:08:21:
hidegh added a comment — 28th November 2016, 15:59:43:
Nathan Brown added a comment — 4th December 2016, 4:30:11:
Nathan Brown added a comment — 4th December 2016, 4:43:55:
Alexander Zaytsev added a comment — 17th April 2017, 4:35:42:
Jon Miller added a comment — 26th April 2017, 21:04:18:
Nathan Brown added a comment — 3rd May 2017, 3:39:54:
Alexander Zaytsev added a comment — 3rd May 2017, 3:48:09:
Alexander Zaytsev added a comment — 3rd May 2017, 3:52:59:
Alexander Zaytsev added a comment — 3rd May 2017, 3:56:26:
Nathan Brown added a comment — 3rd May 2017, 3:56:47:
Alexander Zaytsev added a comment — 3rd May 2017, 3:59:44:
Nathan Brown added a comment — 3rd May 2017, 4:15:23:
Alexander Zaytsev added a comment — 3rd May 2017, 6:16:07:
Nathan Brown added a comment — 29th May 2017, 0:07:22:
aaaa ddd added a comment — 31st July 2017, 12:54:25:
The text was updated successfully, but these errors were encountered: