Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
Okay this might be a doozy
My company intranet is based on a dead old umbraco version 126.96.36.199 which they wanted to upgrade to the latest version, and that task was given to me.
I have never tried upgrading umbraco before but non the less, i upgraded it to 188.8.131.52 without much trouble (used this guide as reference http://our.umbraco.org/wiki/install-and-setup/upgrading-an-umbraco-installation )
From that version i tried to upgrade to 4.8.1, following the guide and trying to be as sensible as i could be when upgrading. Just a note, we made a copy of the installation and database to upgrade on.
After copying the files etc. i switched the web site on the IIS 6 server from .NET 2 to .NET 4.
Anyway, in short regardless of what i do i always get a 404. No matter which url, nothing happens.
I know this might be pretty vague, but is there something else not written in the upgrade instructions i should be aware of? Is there an IIS setting i missed? Note i am forced to use IIS 6 so no integrated pipeline mode.
I can also post the web.config or other config files if requested.
Thank you in advance.
Normally it's recommended to upgrade to each major version incrementally (-> 184.108.40.206 -> 4.5.0 -> 4.6.1 -> 4.7.0 -> 4.8.1). I usually also upgrade to the highest patch release in each step, although it may not be necessary (ie 4.5.0 -> 4.5.2, 4.7.0 -> 4.7.2).
Not sure if you're able to start over, or if we might be able to get the above working. Is your app pool running in Integrated mode (it should be)? Is only the frontend giving 404's, are you able to access the backend at all (ie http://site/umbraco/)? What about static files like an image, are they returning 404 also?
Thank you for your reply.
Yeah afterwards i thought about doing incremental upgrades. Makes sense really. It is possible to start over, as the installation i am upgrading is a clone of the intranet so i can damage it as much as i want to, and replace it.
The app pool can not run in integrated mode, since it is running on IIS 6 which is purely "classic". No way to change it, sadly.
I cant access any page at all, but images load like http://intranet.mycompany.com/media/182/somepicture.jpg.
I also tried to upgrade umbraco from 220.127.116.11 to 4.8.1 and I had some problems after the instalation. I didn't have the 404 problem, however I have this error:
Descripción: Error durante el procesamiento de un archivo de configuración requerido para dar servicio a esta solicitud. Revise los detalles de error específicos siguientes y modifique el archivo de configuración en consecuencia.
Mensaje de error del analizador: Atributo 'fileDependencyExtensions' no reconocido. Tenga en cuenta que en los nombres de atributo se distinguen mayúsculas y minúsculas.
Error de código fuente:
Línea 11: * A new version will invalidate both client and server cache and create new persisted files
Línea 12: -->
Línea 13: <clientDependency version="1" fileDependencyExtensions=".js,.css">
Línea 15: <fileRegistration defaultProvider="LoaderControlProvider">
Has anyone know about what could happends? I've read that in Umbraco 4.8 the fileDependencyExtensions instruction must be to the root <clientDependency element as I have.
Albert, i think you need to create a seperate thread.
Anyway, i rolled back the umbraco installation to version 18.104.22.168 and made sure it worked. Then i upgraded to version 4.5.0 and i ran into the same problem as initially described. When i switch the .NET version on the server to .NET 4.0 it gives error 404 as described before. When i switch back to 2.0/3.5 it gives off an error saying it doesnt recognize some parts of the web.config (because they are .NET 4.0 only).
I am at a loss. Any suggestions?
Found the solution! Turns out that .NET 4.0 was restricted on the IIS 6 server. After setting it to "allowed" it worked. Now i just need to iron out the upgrading bugs, like an empty content tree.
Okay, rebumping so i am sure my new questions is seen: As i wrote above, the problems with IIS is now fixed, and it upgraded umbraco. Now all tree's in the backend is empty, in all sections and on the site itself all XSLT gives off a parsing error. I made sure that "use legacy xslt" is set to "true", also republished everything with this command /umbraco/dialogs/republish.aspx?xml=true Yet nothing changed. Odd indeed.
Glad you got it working!
For the empty trees: this is almost always permission related. When you changed to .NET 4 did you also switch the app pool, perhaps to one using a different identity/user account? If so you should add write permissions for that user. Or if it's the same pool/user try double-checking your permissions. You can also try using Fiddler or similar inspectors to see if you get any errors that might have a clue. Usually you'll see a 500 error on something like DependencyHandler.axd, and checking the Raw data might give you the actual error.
You might also try clearing the ClientDependency cache - delete /App_Data/ClientDependency/TEMP/* or /App_Data/TEMP/ClientDependency/*, bump the version number in /config/clientDependency.config, and touch the web.config file.
For the XSLT error, try adding ?umbdebugshowtrace=1 to your page, scroll down and look for the error in red. It might give more insight into where the problem is.
Have you tried overwriting your ClientDependency.config with the one that comes in the 4.8 install? If not you might want to create a separate thread with the details and we'll see what we can find out :)
Hi tom, thanks for the answer. Finally I only copied tree and application config from the config folder and I could upgrade my Umbraco perfectly.
Thank you Tom
I rechecked permissions for the website and app pool and everything seemed to be in order. I checked for the clientdepency cache but there wasnt even a temp folder. Might this be it?
I also tried fiddler when accessing the backend and it gave a http 304 error on two files, /umbraco/webservices/legacyAjaxCalls.asmx/js and /umbraco/webservices/nodeSorter.asmx/js . Those two files exist, but since it has "/js" at the end, it might be looking for something more? I read up on what error 304 means, but cant really think of the connection, though the names of the files seems to be the cause.
Also, ?umbDebugShowTrace=true doesnt work in the backend, dont know if thats in purpose or an error.
Speaking of stracktrace, the error with the xslt files is related to an old version of uComment. Even though the xslt's that are not parsing have nothing to do with ucomment, that was the only error. Seems reasonable since that version is .NET 2.0 and i forgot to upgrade. Though all the names are garbled when i download the new package since its supposed to be installed through umbraco.
If this installation is completely shot to death and not possible to upgrade, i will just give up and convince the boss it is not possible :p Though it would be nice to get it to work. Oh well, i will give it a few more tries before stopping.
Upgraded to ucomment 1.1.1, it fixed xslt parsing issues. I rechecked the backend with fiddler, and now everything returns with http 200. Tree's are still empty. I am at a loss...
Glad you got that part figured out.
So Fiddler is no longer showing any 500 errors when loading the trees?
Let's try looking again for ClientDependency - the folder changed in one of the versions, it's either /App_Data/ClientDependency or /App_Data/TEMP/ClientDependency - do you have either of those? Maybe it's even in the /data/ folder on the older versions? Just delete everything inside, bump the version number in /config/clientDependency.config, touch the web.config, and maybe clear your browser cache for good measure.
Just to confirm about permissions, did you change to a new app pool with the 4.0 switch or use the existing one? Did the new one have a new user?
Thank you very much for your time Tom!
No, fiddler didnt give any 500 errors. Only 304 errors that was fixed.
I looked around for the clientdependency files, deleted them as you instructed, nothing at all. I did everything you mentioned but still nothing, even changed app pools. Nothing.
I was just about to go out of my mind, when i realized that a bunch of old dll's still existed in the bin folder (that i initially didnt give any thought, because i figured there werent used anymore by umbraco), so i deleted everything except the dll's from the plug-ins, and copied everything over from a "pure" 4.5.0 bin folder. I then loaded up the website and it complaing about the global asax dll, which i then deleted, and reloaded the page. Everything was displayed correctly. So far so good. I entered the back-end and lo and behold! It works! Phew! I was just about to give up on this for good.
To be honest, i have no idea what the exact cause was, maybe it was a stray dll, maybe it was everything in combination, i dont know.
(Sidenote: Its strange, because i overwrote every file in the bin folder when copying the upgrade, so they should all have been updated. But how is it possible for old leftovers to cause a commotion?)
I will now proceeed to tidy everything up, and make sure this upgrade is rock solid before moving on to the next version.
Thank you again Tom for your help, and the fantastic umbraco community!
wish me luck for the next upgrades.
Awesome, glad you got it working!
In some upgrades they require you to remove DLLs, but I don't think 4.5 was one of them. However it just dawned on me, in 4.5 they changed the way context menu items work, and any packages/DLLs that registered them in the old way would cause the trees to disappear.
So perhaps you had a DLL from an old package (or maybe even an Umbraco DLL?) that was doing this.
Anyway, great detective work and glad everything is working :)
Thanks, i have now succesfully upgraded from 22.214.171.124 to 4.9.0. Phew, what a ride! And so far everything looks good. Biggest problem was ucomment refused to work at version 4.7 even when i used the latest ucomment made for that version. Debug trace says its because it cant find the xslt extension, even tough i tripple checked everything. Well, it is disabled for now since it isnt critical.
So for anyone else upgrading from such a low version: As Tom Fulton suggests, do it in steps! Go up one version at a time, make sure it works 100% before moving on. Make a copy of the current working installation each time before moving on in case you screw up. Oh and keep track of your plug-ins, as they would have to be updated manually each time, and that is what causes the biggest headaches.
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted