COU-362 - Update NHibernate

Created by Umbraco 04 Jul 2016, 11:48:46 Updated by Claus Jensen 27 Sep 2016, 08:39:08

Subtask of: COU-384

to latest 3.x


Shannon Deminick 01 Aug 2016, 09:11:25

Part of the larger review for 3.0.0 release -

For testing, we need to see if we need to do assembly redirect bindings, by default we will ship with a few less DLLs so need to see if the existing DLLs like the castle ones will cause issues with the new NH dlls.

Sebastiaan Janssen 20 Sep 2016, 15:49:12

We need the assembly redirect.. and unfortunately we have no good way of adding it (we don't have NuGet and doing it in a package action will be too late because by the time the backoffice reloads it will already be throwing YSODs so we can't apply a transform then), so it will have to be in manual upgrade instructions.

For UaaS the transform should be as follows:


Shannon Deminick 20 Sep 2016, 15:59:21

We have another option - it's the hack that @claus also used so that we can update AutoMapper in the core, it's basically like putting in an assembly redirect into code. Only thing is that we need to test it to ensure that the actualy assembly override (if it exists) in the web.config supercedes the code that we will use to redirect.

I'll put back into reopened

Sebastiaan Janssen 20 Sep 2016, 16:35:31

That would just mean that nobody can update their own nhibernate version. Which I now realize is also a big problem of that core autonapper update. Let's discuss tomorrow.

Shannon Deminick 20 Sep 2016, 16:41:18

That's precisely what I mean by ensuring that the web.config assembly redirects take precedent over the code that performs the redirect ... which i also discussed with claus about the automapper thing so I'm pretty sure he's tested that.

Shannon Deminick 22 Sep 2016, 13:31:25

This is updated in rev: 8268098805685b87fc1887e19c7b74eac9a9c742

We should defo put the assembly bindings in for uaas and document that people should also do that but this will make sure that it will still work if they dont

Claus Jensen 27 Sep 2016, 08:39:00

Yep - I did a bunch of testing on this hack while working on the AutoMapper issue .. it will only apply if everything else fails, so web.config will always be prioritized over this. Fixed this: but apart from that it looks good to me.

Priority: Normal

Type: Task

State: Fixed




Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version: 3.0.0

Sprint: Sprint 43

Story Points: