Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support NetStandard 2.0 #12
I updated the target to netstandard2.0 for the NHibernate.Mapping.Attributes.csproj. All the tests pass. I also added a license file and updated the pack.cmd script to use dotnet pack. I wasn't sure about what to do with the teamcity.build stuff.
There's a package available on our MyGet feed:
Some undue additions have sneaked in, please remove them. (See comments + NuGet.exe.) Licence is quite unrelated too but well, why not.
There are also some adjustments to do.
So you choosed to supply only a netstandard 2.0 build. Why not, but I (or another contributor) have to check if this may have any downside for usage with full .Net framework.
About the TeamCIty build, well, it is broken since quite some time, so I do not think anything should be done about it in this PR.
Well, one likely downside is for user of older VS, which may not handle correctly adding netstandard dependencies in a netFx framework. So the project should provide a multi-target instead.
The test project csproj format would also have to be migrated to the new csproj format in such case, in order to have test both net461 attribute build by targeting net461, and netstandard build by targeting netcoreapp2.0.
There seems to be an issue that relates to the project system and nuget: dotnet/sdk#1561
It appears there is issues when a multi-targeted library is used by another multi-targeted library when more than one satisfies the query. This is causing issues for folks who want to multi-target their testing library. It also causes an issue for any multi-targeted library referencing another multi-targeted library.
FWIW, VS2015 supports netStandard2.0: dotnet/cli#6739. Net461 requires VS2015 anyway (to use C#6 features). Tooling below VS2017 is no longer supported by Microsoft.
Targeting netstandard2.0;net461 feels a bit redundant, since net461 is an implementation of the netstandard2.0 spec and attributes doesn't need to toggle features based on the target like nhibernate did (ie binary serialization). As you said, the only hangup might be older tooling, but net461 requires VS2015 and VS2015 supports referencing netstandard2.0 libraries, so we're really not supporting older tooling by targeting netstandard2.0 and net461. Anyone using NHibernate 5.1 most likely will not be using anything older than VS2015 since nhibernate also requires net461+.
Microsoft themselves only targets netstandard2.0 for libraries that support net461+ and netcoreapp2.0+. The only time you really see multi-targeting is if you need to support net45 and netstandard2.0 for example.
I'll target both if you really want. It just feels like it's going to cause more issues than it's going to solve. Just targeting the netstandard2.0 keeps everything else much simpler--testing, build/release automation, etc.
Nuget.exe was already there, just a very old version (2.6). The new csproj format requires Nuget.exe >=4.3.0 and >=4.1.0 is required to publish to nuget.org, so I upgraded it as part of the solution supporting core.
Alternatively, we could just delete the nuget and teamcity stuff all together and clean up the solution. If you want, I can host an automated build/release in my company's Visual Studio Online account and integrate it with Github.
The linked issue dotnet/sdk#1561 is about being able to test all targets of the dependent library. We do not have this trouble with a multi-target of just one netFx and one netStandard, and it can be tested without issues, as done in NHibernate-Caches currently. NHibernate-Core targets furthermore netcoreapp, and so yes, it does not test netstandard indeed. We just accept this.
Can you provide precise example for us to check if this may apply to our case here?
This does not prevent using the 4.6.1 framework in VS2013 or 2012, and I know of many companies which do. Of course if some guy works with a newer VS and commits C#6/7 syntax, he will causes troubles to his colleagues, but generally that will be the guy not using the expected tooling in the company that will be blamed.
Quite wrong. The latest update of the tooling must be checked in this site, not the "All edition".
No, definitely wrong. Many corporate organizations are still using older VS than 2015 while using NHibernate and net461.
It keeps things simpler for contributors, but it will likely deny the library usage to many developers working at companies having perpetual licences of VS 2013 or older. Those companies are understandably quite reluctant to upgrade their tooling.
My bad for NuGet. I am used to other projects like NHibernate-Caches or NHibernate-Core where it is downloaded by the build scripts. So ok for its update.
Thanks for the proposition, but better do this as an AppVeyor build by example, which can be bound to NHibernate GitHub organization, instead of being bound to a third party account. I can activate AppVeyor for NHibernate.Mapping.Attributes if you wish to handle this (but please do it within another PR in such case).
Thanks by the way for your work, it is in any case appreciated.
The HbmWriter behaves a little differently in corefx. Because there is no GAC, type string returned from
I wanted to test that the resulting mapping document is still valid, but
Well now that I had a look on sources, it looks to me like
And at the start of the domain file:
/*\ * The mapping used in the following classes has no meaning for NHibernate; * it is here for the sole purpose of testing NHibernate.Mapping.Attributes * in all possible usage cases. \*/
So fixing that
I think the test trouble just need to be fixed by adding
Yeah, that was my sense... the mapping doesn't actually work in NHibernate. I will create a Core version of the reference for testing serialization.
I also have an RI for DDD with NHibernate that has some common scenarios. I want to test the core version with that project just to make sure the resulting doc actually works. I'm sure it does, I just want to be sure.
Since I am done with porting Caches to Core (and even Validator), I can spare some time to finish the work on Attributes, if this suits you. But I believe you have already done some additional work without pushing it there. So let me know if you wish me to finish this PR or not, from its current state or after some additional pushes from you.
I committed some changes. The tests fail under core, but it's more of how the tests are written.
I tested an actual domain library from one of our applications, and it seems to work so far--at least our unit tests pass. So, I think the library is good, we just need to figure out how to properly test it.