With our old Umbraco 4.x installations, with their webform master page templates, the standard way of debugging reluctant Razor macros was to suffix the Url with umbDebugShowTrace=yes.
I've just started working on a new Umbraco 7.4 project, where I've opted to use MVC (my first proper MVC site - I may be slightly behind the curve!). The first time I needed to debug an error in a View, I tried http://localhost/?umbDebugShowTrace=yes and ... nothing happened.
Although I'm sure that by building the project in Visual Studio (which I did) there are ways to debug properly. However, sometimes it's still useful to use these tried and tested familiar methods - especially if you need to discover why a page that works fine on your development machine, for some reason doesn't work on the live server. Thankfully there is a work-around:
I've just started working on a new Umbraco 7.4 project, where I've opted to use MVC (my first proper MVC site - I may be slightly behind the curve!). The first time I needed to debug an error in a View, I tried http://localhost/?umbDebugShowTrace=yes and ... nothing happened.
Although I'm sure that by building the project in Visual Studio (which I did) there are ways to debug properly. However, sometimes it's still useful to use these tried and tested familiar methods - especially if you need to discover why a page that works fine on your development machine, for some reason doesn't work on the live server. Thankfully there is a work-around:
- In web.config, modify the <trace> element so enabled is set to "true".
- After viewing the page with the error, use http://localhost/trace.axd to view a list of the last 10 Urls that were accessed
- Clicking on "View details" link next to a Url, will reveal the full trace.
If you're debugging on the live server, don't forget to revert <trace> back to enabled="false" after you've finished.
Comments
Post a Comment