What is the last version of nhibernate that supports .Net Framework 2 ? and is there a big difference between dealing with it and dealing with last version that supports .Net 3.5 ?
Note:
The series NH2.1.x is the last whose
target is .NET2.0
NHibernate 3 Alpha (full .NET Framework 3.5 support):
With the 3.0.0 release, NHibernate
includes support for LINQ, along with
additional features such as:
Along with a long list of bug fixes
and improvements, it has several new
features including a new strongly
typed criteria API called QueryOver;
lazy loading of columns; alias
delimiting in generated SQL; and
support for DetachedCriteria within
IStatelessSession. The new release
also brings improved support for LINQ,
overcoming the HQL limitations of the
previous provider.
Upgrading users should be aware that
one of the fixes means that null
values in dictionaries are no longer
silently ignored, which has the
potential to break existing
application code.
Related
I'm writing a Windows Phone framework with Windows 8 in mind. That means I'm creating a Portable Class Library (PCL) to be used in both platforms.
Right now my PCL is targeting .NET 4.5, Windows Phone 8 and Windows Store apps, as you can see in the project properties.
In that project I need to use Path.DirectorySeparatorChar but I get the following error from the compiler:
System.IO.Path' does not contain a definition for 'DirectorySeparatorChar'
I understand that that particular char might be different in the different targeted OS (I really don't know if they are) but why is the compiler complaining about it? I mean, the property help doc says it is supported by .net framework 4.5, am I targeting the right framework? Is the PCL really targeting the full .net framework 4.5?
With respect to Path.DirectorySeparatorChar:
As far as I remember we've removed it from Windows Store in order to discourage manual parsing of paths. In general you should use Path.Combine() for assembling paths and Path.GetDirectoryName() for splitting them up. In order to check for invalid chars, there is another method that allows retrieving those.
So practically speaking, what do you need the property for?
Update: To answer your original question around understanding profiles: The profiles represent API intersections between the platforms you've selected in the PCL dialog. Generally speaking, the fewer platforms you target and the more recent the versions, the more APIs you get. Checking all platforms in the oldest version basically gives you the lowest common denominator.
Since you've targeted .NET 4.5 and .NET Windows Store, you can't access Path.DirectorySeparatorChar because that property isn't included in Windows Store.
So, here's the actual answer to this question taken from the MSDN forum.
When you are creating a PCL, you can only have a subset of API-s that are defined in that particular profile. A profile is a list of API-s visible in all platforms.
Now, even if some API exists in both individiual platforms, this doesn't mean that it will automatically be in the PCL profile. Why is it missing is anyone's guess, but you cannot infer those reasons yourself.
If you take a look at the official documentation on MSDN (Cross-Platform Development with the .NET Framework), you'll notice that there are several constraints on what can be shared. I guess that that particular property doesn't satisfy those constraints.
And a good way of knowing is a particular method is supported relies on the icons of the documentation
Your PCL can use .NET methods which are available to all of its targets. Since PathDirectorySeparator isn't available to Windows Store apps it isn't available in PCLs targeting Windows Store apps. You can see that it doesn't have the green shopping bag marker for store support at http://msdn.microsoft.com/en-us/library/system.io.path.aspx
We're using NH 2 and need some features from NH 3 (JOIN ...AND (...)). It's quite easy to copy them from sources. So I wonder if there can be any unexpected errors in application after recompiling NH 2 and using instead of the one compiled by developers of NH.
Problems may occur if you have other pre-built assemblies which reference a specific NH version. In that case you may need to do an assembly binding redirect. Personally, I would try to upgrade everything to NH 3 if I wanted a feature from it because that way I don't have to concern with managing a forked version of an assembly.
I would like to get all 3 of these libraries working together but have a version problem.
Latest version of Linq To Hibernate (1.0) came out on 2009-07-26 and works with NHibernate 2.1.0 afaik. Fluent NHibernate's oldest release on the other hand is for NHibernate 2.1.2.
Google search yielded this zip file of binaries compiled together but it's somewhat outdated (2009-07-19). I'm not sure downloading the latest source code of each project and trying to build them together will work or not, I'd rather not to go that way unless I have to.
I guess the weakest link in this combination is Linq To NHibernate and maybe I should think of leaving it outside if there isn't an active community effort.
In short: Does anyone use these libraries together and if so, how did you solve this issue? Do you build it all yourself?
Note:
Looks like a duplicate of this question but it has been 1 year since it's answered, and the links given in the accepted answer don't work anymore.
NHibernate ver 3 has been released which already has the linq libraries. Download the latest binaries.
I don't think Fluent has been updated to use 3 yet so download the latest source for fluent and replace the NHibernate assemblies with the new NHibernate version 3 assemblies. You will need to tweak the source ever so slightly so that it compiles. Compile it in release mode and grab the output from the project bin folder.
It has been working fine for us.
EDIT
As Kohan pointed out you can download the latest version of Fluent 1.2 with the latest version of NHibernate 3 from the link to Fluent NHibernate I provided earlier.
The ECMA standard for the .NET Common Intermediate Language has been updated three times. I haven't been able to find a version history that would make clear the changes between the versions. Are there any substantial differences between the four, e.g. new opcodes etc.?
Also: Is the same true for MSIL?
Thank you!
Yes, the first two editions didn't have generics - that's by far the biggest change.
The third edition has a list of major changes in the foreword.
I don't know about the differences between 1/2 and 3/4... I suspect those were very minor changes.
(I also don't know whether the ECMA C# spec will ever catch up with the Microsoft version... the current ECMA version is C# 2.0 basically.)
I'm migrating the data layer of our application to NH version 2.1.0 (from 2.0.1) and noticed the use of LinFu. I discovered that framework and want to use it in other pieces of the application, especially I want to use the LinFu.Reflection.dll, which requires a reference to LinFu.DynamicProxy and here comes the trouble, the 1.0 final version of LinFu that I can find on google.code is not the same version used by NHibernate itself. Do I need to rebuild NHibernate.ByteCode.LinFu.dll changing the reference to the available version? If not, what else?
I have faced the same problem a few days ago. There's a tool named ILMERGE that merges .NET DLL-files, and that way you should be able to have several versions of the same DLL in your application.
Unfortunately I haven't tested the tool yet, I didn't get around to it, but I'll test in the next week.
But Rhino Mocks for example, has a binary with all dependencies included: http://ayende.com/projects/rhino-mocks/downloads.aspx, so it seems doable.