I have an app that uses both NHibernate and Crystal Reports, NHibernate.dll reference Log4Net 1.2.10.0 (PublicKeyToken=aa95f207798dfdb4)
After upgrading Crystal to ver 13.0.2000 we now have a problem, crystaldecisions.shared.dll now references Log4Net 1.2.10.0 as well, but it seems that the good folk at Crystal Decisions have made the "interesting" decision to recompile 1.2.10.0 leaving the version number the same, but giving it a new public key (692fbea5521e1304) and installed it into the GAC.
So my question is...How to install these log4net assemblies side by side? or trick one of the other assemblies (NHibernate or Crystal) into using the other one.
You should be able to install the standard log4net into the GAC as well. This will allow both versions to be loaded by the assembly loader. Alternately you could recompile NHibernate to use the version crystal does, but you'd have to do that from now on moving forward, so I wouldn't recommend it.
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 am building a SharePoint project and using TFS2010 for my builds. I have used the TFS community build extensions to successfully implement assembly version incrementing which I am happy with.
However, as my assembly is going into the GAC I need to update my ASPX/ASCX files to reference the assembly with the correct version.
Is there a "proper" or easy way to do this?
The markup in ASPX/ASCX files can have tokenized references so it shouldn't be an issue.
<%# Assembly Name="$SharePoint.Project.AssemblyFullName$" %>
Where you have to careful is with web parts and workflows. In both cases the fully qualified name of the assembly that implements the web part or workflow is stored in the content database.
My suggestion is that you do not update the assembly version number unless you plan on running the new version and the old version side-by-side. In the case where you are making changes that will effect currently deployed assets, you should change the assembly file version instead. You'll still be able to distinguish between assemblies but you won't break assembly references.
See Configuring Versioning of Assemblies in SharePoint Automated Build for more discussion on the subject.
I'm trying to upgrade my WinForms app to the latest versions of NHibernate and Fluent NHibernate, but now I get the SQLite exception "Callback routine requested an abort" on the call to BuildSessionFactory.
I have a working sample project that uses the new versions. I attempted to upgrade my real app by replacing the old NHibernate, FluentNHibernate, and System.Data.SQLite references with the new ones, but that caused the problem.
New versions I'm using:
NHibernate 3.2.0.4000
FluentNHibernate 1.3.0.0
System.Data.SQLite 1.0.76.0
VS 2008 9.0.30729.1 SP
Windows XP SP3 (32 bit)
I eventually traced the problem to having the wrong type of System.Data.SqLite DLL.
Turns out they've added a new version that is not a single DLL deployment - it has dependencies on other DLLs.
This is not clearly explained on the SQLite download page. Also, they use exactly the same names and version numbers, which led to me downloading the wrong one.
Problem went away when I downloaded and referenced the "mixed-mode" assembly.
See my answer to the question New SQLite Mixed Assemblies for more details on how to get the "right" one.
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
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.