We have moved to GitHub Issues
Created by Sebastiaan Janssen 14 Nov 2014, 14:30:25 Updated by Shannon Deminick 28 Aug 2015, 10:25:47
Subtask of: U4-5423
Core should be released with the secure version.
Fixed in b20fc225775810aabc45559c2fc69da089d50a42 and merged into 7.2.0.
In the end we could not apply this fix as it would 100% fail on computers that do not have this windows update installed yet and there's no way of working around it as the version in the GAC is taken first (so if the update isn't applied, 184.108.40.206 from GAC will be used instead of 220.127.116.11 in the bin folder). This meant that code depending on 18.104.22.168 would just YSOD, and since we build against that version, it would alsways YSOD. The good news is that as soon as the computer DOES get 22.214.171.124 in the GAC all is well and the secure version is used automatically.
I'll have to setup a VM or something, it just doesn't seem like it should fail or be possible to fail. If it's in your /bin then it will load, just like the way we can ship anything in the /bin and it will load. If they have it installed in the GAC then the GAC version will be used but that is fine as well.
The rule is that if the versions match exactly, then the GAC one will be used, otherwise if it doesn't exist in the GAC the /bin one will be used. If people didn't copy in all of the assemblies we provider in our build output like the MVC ones, then it would definitely fail. I'd be interested to know how these upgrades were done to cause this to fail, any chance you know?
Nope, I can't remember exactly. Maybe we didn't ship the dlls properly? I remember it being an issue when just starting Umbraco from a fresh unzip and/or NuGet install. Which reminds me: you need to update the NuSpec to use the new version as well! (maybe that was the whole problem.. hmmm).
Ah no, that can't have been the problem, the nuspec was updated in the changeset above.
Hrm, it certainly seems very strange. If the dlls are in the /bin they'll defo be used. I'll spin up a vm without the patch (if i can) and see what happens
Here's what I've tested:
Next, I deleted that site and installed MVC 126.96.36.199 into the GAC, then:
I'm not sure what was going wrong with any previous tests, but having MVC 188.8.131.52 in the /bin with the assembly redirect definitely works regardless of what is in the GAC (which is expected since that is how .Net works). However I do realize this is a little intrusive for a patch release update. So lets leave out the MVC update for 7.2.5 and make the update in the core and our nuspec dependency to the 184.108.40.206 version for 7.3. @sebastiaan Sounds ok?
Assignee: Shannon Deminick
Backwards Compatible: True
Due in version: 7.3.0