I'm hoping I can get some help from the community on this issue which has been driving me bonkers for some time now.
We're using the Multi-Node Tree Picker in our site build. It works fine when developing on our local instance, but once the site is deployed to the testing server via a CI build process, it stops working.
When looking through the network requests, I've noticed that there is an error when the site is trying to request the WebResource.axd file which is supplying the JavaScript for the control via an embedded resource. The server returns a 404 page not found error. This causes the control to fail.
I've tried to change permissions on all files in the bin folder to give the user running the site full control but it doesn't make a difference. I've also checked that all files in the bin folder are being deployed and they're all there. The only thing that fixes it is to manually copy all the files from the local dev site's bin folder to the test site's bin folder.
We are running Umbraco 4.9 on IIS 7.5 on Windows Server 2008 R2 standard 64-bit.
Any help or suggestions would be greatly appreciated.
Which version of MNTP are you using? The core/default one or the uComponents version? (ref: MNTP moved from uComponents to Umbraco core in v4.8)
... and a chance question, but feel like I have to ask - are you running a custom build of Umbraco core? My complete guess would be that the embedded resource isn't being exposed as a WebResource attribute. (Ignore this if you aren't running a custom build)
Hmmm ok. Try comparing the "umbraco.editorControls.dll" on both your local dev and test environments - specifically the version numbers (right-click > Properties > Details tab). Gut feeling is that they are different - for whatever reason. ;-)
Multi-Node Tree Pickers breaks after site deploy
Hi,
I'm hoping I can get some help from the community on this issue which has been driving me bonkers for some time now.
We're using the Multi-Node Tree Picker in our site build. It works fine when developing on our local instance, but once the site is deployed to the testing server via a CI build process, it stops working.
When looking through the network requests, I've noticed that there is an error when the site is trying to request the WebResource.axd file which is supplying the JavaScript for the control via an embedded resource. The server returns a 404 page not found error. This causes the control to fail.
I've tried to change permissions on all files in the bin folder to give the user running the site full control but it doesn't make a difference. I've also checked that all files in the bin folder are being deployed and they're all there. The only thing that fixes it is to manually copy all the files from the local dev site's bin folder to the test site's bin folder.
We are running Umbraco 4.9 on IIS 7.5 on Windows Server 2008 R2 standard 64-bit.
Any help or suggestions would be greatly appreciated.
Many thanks,
Dan.
Hi Dan,
Couple of questions about your set-up.
Which version of MNTP are you using? The core/default one or the uComponents version? (ref: MNTP moved from uComponents to Umbraco core in v4.8)
... and a chance question, but feel like I have to ask - are you running a custom build of Umbraco core? My complete guess would be that the embedded resource isn't being exposed as a WebResource attribute. (Ignore this if you aren't running a custom build)
Cheers, Lee.
Hi Lee,
We're using the core / default MNTP and we're using the stock build of Umbraco - no customisation.
Cheers,
Dan.
Thanks Dan.
OK, just to confirm, is the WebResource.axd returning a 404 or 500 error?
A 404 suggests that the resource requests doesn't exist - as in it's not embedded within the assembly/DLL.
If it's a 500 - are you able to post the exception message? (obviously removing any sensitive info)
Cheers, Lee.
Hi Lee,
It's definitely a 404 error.
Cheers,
Dan.
Hmmm ok. Try comparing the "umbraco.editorControls.dll" on both your local dev and test environments - specifically the version numbers (right-click > Properties > Details tab). Gut feeling is that they are different - for whatever reason. ;-)
Cheers, Lee.
Hi Lee,
You wouldn't believe it, but we haven't been able to replicate the issue since your last post, so I haven't been able to check the DLLs.
If it happens again I will check and let you know.
Thanks for your help!
Dan.
is working on a reply...