DependencyHandler.axd Using Old Domain Instead Of New One?
While I was building out my new blog I had it on a sub domain (new.mydomain.co.uk) and everything was working as it should.
I then made the blog live and changed the bindings in IIS to be (www.) instead of (new.) and again the site loaded fine as you would expect. But then I logged into the umbraco admin and noticed nearly all the background images were missing?
I checked the source and found the DependencyHandler.axd is still referencing the old domain in the code - See below??
Any ideas why it would be doing this? Its been like it for weeks now?
I've been having a similar problem. Mine was related to upgrading from 4 to 4.5.1 and missing out some web.config settings. Have you also tried deleting the ClientDependency folder in the App_Data directory?
Client Dependency does an in-memory cache (reloaded on app pool recycle), a file system cache (which is a physical version of the in-memory version) and the original unmodified files.
When Client Dependency receives a request it does:
Does the requested dependency set exist in memory? If yes, return it from memory.
If no, does it exist on the file system? If yes, load into memory and return it from memory.
If still no, combine the files in the request, save it to the file system and add it to the memory cache and return it.
You should never copy the Client Dependency files across environments, only the original CSS and JavaScript files, Client Dependency can make dependency sets itself. The "problem" is expected behavior, and by design.
I'm in a position where we move a site to a new domain once development is finished. I'm a designer, not a programmer or server guy so please forgive my ignorance here. Are you saying it's good practice to delete the contents of the client dependency folder when we move a site to live?
I am having a similar problem, though it is not due to copying over an existing Umbraco site to a new domain. I made a change to web.config to support a custom 404 page, and this resulted somehow, in the DependencyHandler.axd URL values no longer being valid. This means JQuery doesn't get loaded and I cannot use the Umbraco admin interface since it is messed up without JQuery. I rolled back my change to web.config but DependencyHandler.axd still isn't working.
I changed the version number in the ClientDependency config, deleted the ClientDependency folder from App_Data (in 4.5 it is App_Data/TEMP/ClientDependency), and also changed <compilationdebug="true"> in web.config. This works until I change <compilation debug="false"> again. Then I get the same errors about JQuery not being found (though fewer of them). I posted in another forum on this but haven't got an answer that works yet. Since you all experienced this problem, I'm hoping you'll have some further ideas for me to try. I think that all I need to do is get the client dependency cache fully removed and then fully reconstructed but I can't seem to find a way to do this.
I apologize, it turns out that my web.config was totally screwed up and this is what caused the problem. Setting up a custom 404 page was done through my hosting company's control panel, which heavily modified my web.config in ways I did not anticipate. Once I corrected the web.config line by line, all was well.
DependencyHandler.axd Using Old Domain Instead Of New One?
While I was building out my new blog I had it on a sub domain (new.mydomain.co.uk) and everything was working as it should.
I then made the blog live and changed the bindings in IIS to be (www.) instead of (new.) and again the site loaded fine as you would expect. But then I logged into the umbraco admin and noticed nearly all the background images were missing?
I checked the source and found the DependencyHandler.axd is still referencing the old domain in the code - See below??
Any ideas why it would be doing this? Its been like it for weeks now?
I've been having a similar problem. Mine was related to upgrading from 4 to 4.5.1 and missing out some web.config settings. Have you also tried deleting the ClientDependency folder in the App_Data directory?
Cheers
Rich
Nope but I'm going to try deleting it now :)
It dies if you remove that folder...
Odd, it didn't die when I removed mine I came across this post when I ran into the issues (http://our.umbraco.org/forum/core/general/11644-BUG-DependencyHandler-using-old-(dead)-absolute-path-to-objects). Does an App pool restart kick it back into life?
Try looking at the documentation here for how to clear the cache: http://clientdependency.codeplex.com/documentation
It does sound a lot like this problem: http://our.umbraco.org/forum/core/general/11644-BUG-DependencyHandler-using-old-(dead)-absolute-path-to-objects
Doh... Thanks Ove, I needed to change debug to true first
<compilation debug="true">Then I deleted the ClientDependency folder in the App_Data directory and it was fine, set debug back to false and everything is fine :)
Thanks
Client Dependency does an in-memory cache (reloaded on app pool recycle), a file system cache (which is a physical version of the in-memory version) and the original unmodified files.
When Client Dependency receives a request it does:
Does the requested dependency set exist in memory? If yes, return it from memory.
If no, does it exist on the file system? If yes, load into memory and return it from memory.
If still no, combine the files in the request, save it to the file system and add it to the memory cache and return it.
You should never copy the Client Dependency files across environments, only the original CSS and JavaScript files, Client Dependency can make dependency sets itself.
The "problem" is expected behavior, and by design.
Slace,
I'm in a position where we move a site to a new domain once development is finished. I'm a designer, not a programmer or server guy so please forgive my ignorance here. Are you saying it's good practice to delete the contents of the client dependency folder when we move a site to live?
thanks for the clarification.
Just don't copy that folder or its contents
I am having a similar problem, though it is not due to copying over an existing Umbraco site to a new domain. I made a change to web.config to support a custom 404 page, and this resulted somehow, in the DependencyHandler.axd URL values no longer being valid. This means JQuery doesn't get loaded and I cannot use the Umbraco admin interface since it is messed up without JQuery. I rolled back my change to web.config but DependencyHandler.axd still isn't working.
I changed the version number in the ClientDependency config, deleted the ClientDependency folder from App_Data (in 4.5 it is App_Data/TEMP/ClientDependency), and also changed <compilation debug="true"> in web.config. This works until I change <compilation debug="false"> again. Then I get the same errors about JQuery not being found (though fewer of them). I posted in another forum on this but haven't got an answer that works yet. Since you all experienced this problem, I'm hoping you'll have some further ideas for me to try. I think that all I need to do is get the client dependency cache fully removed and then fully reconstructed but I can't seem to find a way to do this.
Thanks for any suggestions,
-NorthK
I apologize, it turns out that my web.config was totally screwed up and this is what caused the problem. Setting up a custom 404 page was done through my hosting company's control panel, which heavily modified my web.config in ways I did not anticipate. Once I corrected the web.config line by line, all was well.
Thanks,
-NorthK
is working on a reply...