there is a project using nhibernate v2.1 and i have been wondering whether v3 is backwards comatible with 2.1?
I mean if i drop v2.1 dll and replace it with v3 dll would all code work?
thnx for your opinion.
Just made the move recently. There were no "out of the way" breaking changes unlike when having to upgrade from 1.2 to 2.0. In fact we didnt have to change anything in our code when we upgraded from 2.1.2 GA to 3.0
However there are some breaking changes that can be seen in the release notes that accompany the downloads.
In relation to the question you asked with the NHibernate dll:
NHibernate depends on log4net, Castle, Iesi.Collections etc so when you upgrade ensure that these dlls are correct also - We cater for this easily by positioning downlaoded NHibernate binaries in a "lib" repository and all projects that need NHibernate reference the NHibernate.dll in the NHibernate "lib" folder. This then solves the dependency issue as all other necessary NHibernate dependencies are in situ already in the same folder as the NHibernate.dll by default.
It is almost compatible. If you didn't use linq. Read realease info, there is list of breaking changes.
Related
After allowing Nuget to update ImageResizer 3.1.5 to version 3.2.1 my compiles are failing with multiple errors (all same type):
Error 5 Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'
Apparently this is the result of an assembly version mismatch. Deleting all ImageResizer references in the project allows an error-free compile.
Reverting to ImageResizer 3.1.5 also allows a successful compilation.
My project is a simple MVC3 application targeting .NET4 - both ImageResizer 3.1.5 and 3.2.1 are targeting v2.0.50727
Any ideas on how this could be fixed?
Thanks in anticipation!
Update (Jun 20th 2012): The best solution is for the project to roll back extension method support. ImageResizer 3.2.2 will no longer offer extension methods, but some of the functionality will be duplicated in the ResizeSettings and Instructions classes to minimize breakage for those who have already coded against the new alpha APIs.
ImageResizer V4 will most likely require .NET 3.5, and will re-introduce the missing features.
Update: please see this question instead if you have any solutions to this catch-22.
I apologize for the issues.
I'm still trying to gather data and discover a long-term solution, but this is what I have so far:
Workaround A:
In Solution Explorer, expand the References folder in your project, select ImageResizer, and go to Properties. Change the Aliases field from 'global' to 'ir'.
Workaround B:
Set your project to use .NET 2.0, save, then revert it back to using .NET 3.5 or .NET 4.
Workaround C:
Manually remove your System.Core reference and add the correct one back. (The usual culprit is an upgraded project with a System.Core 3.0 reference in a 3.5 project). On ASP.NET, you can do this in web.config.
Workaround D:
Revert to 3.2.0, but only if you're using C#.
Why this is happening
VisualStudio/MSBuild find multiple definitions of System.Runtime.CompilerServices.ExtensionAttribute in the project during compilation, but instead of picking the public copy defined in System.Core, the compiler decides to use the internal, assembly-local copy defined in ImageResizer.dll. Then it complains because other assemblies can't reach it. Inane.
What should happen
Microsoft has used this technique several times in the past without issues, and it's widely documented. The compiler is supposed to pick the public instance for project-wide use, but instead it's picking the 'internal' copy. And this isn't affecting many developers; and only a few can reproduce it with a new project.
Public vs. Internal
V2.3.0 defined ExtensionAttribute as public instead of internal. This caused a compile-timer error in VB projects, but not in C# projects. I immediately released 2.3.1 with it marked internal, but I'm now seeing problems with C# projects instead. Catch-22 here.
It works for other people... and Microsoft! Why me?
http://www.danielmoth.com/Blog/Using-Extension-Methods-In-Fx-20-Projects.aspx
http://www.codethinked.com/using-extension-methods-in-net-20
http://kohari.org/2008/04/04/extension-methods-in-net-20/
Using extension methods in .NET 2.0?
The 'hack' was even featured in MSDN magazine.
How you can help
I need more data to completely figure this out. If you're experiencing the issue, please e-mail a .zip file of the project to support#imageresizing.net, and include your VisualStudio/.NET version numbers (Go to Visual Studio, Help, About, and click Copy Info, then paste it into the e-mail).
Hopefully I'll be able to find the exact circumstance(s) that trigger the problem.
Update - just found this article which implies the only solution is creating multiple versions of the assembly. But Microsoft didn't! What am I missing? Also, NuGet doesn't support 2.0 vs 3.5 versioning, so unless I can find a single-assembly solution I might have to drop 2.0 support.
I have a project by NHibernate (version 2.1). For upgrade to NHibernate 3.2, what should I do?
Do I need that upgrade following dll?
Antlr3.Runtime
Castle.Core
Castle.DynamicProxy2
NHibernate.ByteCode.Castle
I could not find those dll in NHibernate 3.2. Now what should I do?
They are not needed any more. Just delete all dlls that are not there any more (except maybe log4net, that's now optional but without it there won't be any logging).
You might also get errors in your hibernate.cfg.xml, just remove the deleted elements like ProxyFactoryFactory.
I have a project using NHibernate (version 2.2). For upgrade to NHibernate 3.2 , What should I do?
Do I need that upgrade following dlls?
NHibernate.Linq.dll
Iesi.Collections.dll
Castle.Core.dll
Castle.DynamicProxy2.dll
Log4net.dll
Do I need that upgrade hbm files? Do I need that upgrade hibernate.cfg.xml file?
When upgrading to NH 3.2 you don't need NHibernate.Linq.dll anymore, but method name that is used to get LINQ support is not Linq<T> - its Query<T> now
You don't need to change hbm files
You will need to update Iesi.Collections assembly
You don't need castle.dynamic proxy dll (you still can use it, but its not required anymore)
Log4Net is not required anymore
You will probably need to change your cfg file in order to change dynamic proxy settings
The easiest way to get latest version of NH with all required assemblies is to use Nuget
upgrade the dlls and test your program, normally this should be enough
As of the today, the Nuget release of NHibernate Validator is 1.3.1.4000 and says it has a dependency >= NHibernate 3.1.0.4000, which implies it should work with latest NHib 3.2.
But NHib 3.2 now has its own ProxyFactory, so running the two gets the following error:
System.TypeLoadException : Could not load type 'NHibernate.Bytecode.ProxyFactoryFactoryNotConfiguredException' from assembly 'NHibernate, Version=3.2.0.2001, Culture=neutral, PublicKeyToken=aa95f207798dfdb4'
I do not really need anything in NHib 3.2 now, although my preference would be to make the two work together.
Alternatively, I suppose I could drop down to NHib 3.1, but my solution has 16 projects, which where Nuget comes in. This post suggests how to get and install an older package release, but NHib 3.1 doesn't seem to be available stand alone from Nuget.
Installing Validator alone using Nuget will install the NHib 3.1 as a dependency. I have some projects that don't use Validator but do use NHib alone, and I guess I could install Validator just to get the correct dependency but that isn't a very satisfying solution.
Has anyone got the latest NHib (3.2) working with the latest NHib Validator? Suggestions?
Cheers,
Berryl
If you feel OK about using NHib 3.1 you can first add the Validator + its dependency on NHib 3.1 to the projects that require validation. Afterwards, referencing the NHib package in other projects can be done at the solution level (introduced in NuGet 1.4)
I'm using the latest stable build of Fluent NHibernate ver 1.1. Now in the application I'm also using castle.core for dependency injection. Now the problem is using them together. In Visual Studio castle.core says ver. 2.5.1.0 but in Windows Explorer "details" for the same DLL file it says 2.5.1.2121. I have tried both numbers in assembly binding in the web.config, to switch away from ver. 1.1.0.0 which the Fluent NHibernate castle.core references, but not with much luck.
Any suggestions to solve this issue? I do not want to build any of the assemblies myself.
The only solution I came across with this was to get the nhibernate.bytecode.castle source and build it against the latest source for castle.core - alternatively you could use a nhibernate.bytecode.linfu instead.
I rebuilt Fluent NHibernate against the latest Castle Project core and Fluent NHibernate beta2. Now it works.
I just found the solution. I used the MVC contrib project and this was the source to the problem, the Windsor controller factory. I wrote my own and removed the reference, only a few lines of code, problem solved.