Setting up Umbraco in Visual Studio

In the time I’ve worked with Umbraco I’ve seen two types of project setups (in Visual Studio) – one simply places the project on top of the actual Umbraco installation, and then excludes some folders, where as the other uses Visual Studio build events to copy your project output into a separate “clean” version of Umbraco.
This link describes the latter “copy-over” approach: http://our.umbraco.org/wiki/how-tos/getting-started-with-umbraco-what-is-next-after-you-install/setting-up-your-project-in-visual-studio and this link (amongst other things) describes the first mentioned “in-place” approach: http://www.aaron-powell.com/how-i-developer-umbraco.

On balance I prefer the “in-place” approach. The “copy-over” is nice, in that it keeps your project small, and allows you to keep the Umbraco solution completely out of Visual Studio. However, as you project grows the build time will increase either way, and what will really (really) get your goat, is the time it takes to even make little CSS or HTML changes. You make these and you have to do a full build, which will copy over all configs, binaries etc – which will in turn trigger the app pool to recycle and on a large project, you can easily end up waiting more than 30 secs for even the smallest updates.
I’ve worked around this before by configuring different build configurations in visual studio and then only copying say HTML, js and CSS for the “Frontend” build – but it still gets slow.

The “in-place” approach seems messy to start with, but actually it works very well. Once you exclude your items from Visual Studio it’s much like working with the “copy-over” solution, but you have much faster build times.

Happy Umbraco’ing whatever you go with!

The Path to Happy Cookie Deletion

Recently ran into an issue trying to remove a cookie.
Using the web developer tool this was clearly visible in client, and in the ASP.NET code behind this also showed up nicely in the Request.Cookies collection.
So used code like this: http://msdn.microsoft.com/en-us/library/ms178195.aspx to try and delete it.
But amazingly did not work.
Turns out that the path of the cookie was set. This limits it to pages below that path – however, in the Request.Cookies collection the path just came through as “/” – so using the above MSDN code did not clear this.
Copying the cookie from the collection, setting the Path property to the same value displayed in the Web Developer Toolbar, and only then setting the Expires to yesteryear and adding to the Response.Cookies collection – made this work.

Cookie Based (forms) Authentication Not Working in IE Iframe

Recently spent some time troubleshooting a 3rd party vendor being integrated into our site via an IFrame. Not really a great idea in the first place, with overflow:hidden and what have you – but the real issue came around their authentication process.
We were sending through an encrypted identifier on the iframe src querystring, which they succesfully matched to approved users on their system, however, after authenticating, the subsequent redirect would show that the user was no long logged in… so what was going on?
Turned out, after a lot of calls and testing, that this was the issue: http://stackoverflow.com/questions/389456/cookie-blocked-not-saved-in-iframe-in-internet-explorer.
Good old IE – never fails to provide useful features.

So essentially IE has a setting (thas is on, even on medium-low security) which says cookies served from a different domain than the current (in our case from within an iframe) are blocked, unless the remote server at that domain provides a “privacy policy”.

In some way this is a sensible enough approach – but unfortunately the solutions is (despite all the waffling about lawsuits in the StackOverflow post) as simple as adding this header to every response sent from the server:

'P3P: CP="NOI ADM DEV COM NAV OUR STP"'

So if you’re a reputable company, you’re likely to be in compliance with that anyway, if you’re not – then you probably haven’t got your full postal address on whois anyway… so one questions the value added from this IE safety net.
But it’s there, and it created some work hours for us.

Umbraco UI Performance Increase with IIS Cache Headers

A quick and substantial performance gain on the Umbraco admin UI:
http://umbraco.org/follow-us/blog-archive/2007/12/14/dec-10-dramatic-performance-increase-in-two-minutes

This will add IIS content caching on the /umbraco_client folder. Especially in older version of IE limited to two connections per domain this will give a significant boost.

Maintaining Session State in .NET Web Services

Very informative article on this here: http://msdn.microsoft.com/en-us/library/aa480509.aspx and a step by step of the client side implementation here: http://support.microsoft.com/kb/816637

The short of the long is:

• The web service must be marked with the EnableSession=true attribute.
• On the consuming client, you must use an instance of the CookieContainer class to store the session cookie (with the unique session ID created on your first request
• You must then re-use this instance of the CookieContainer for each subsequent call in order to maintain session state on the web service host – a logical way to do this is to add the CookieContainer instance to session state on your client (so do a get property with “session bag” null check logic

Configuring Umbraco in Load Balance/Multiple Dev Environment

Details of this here, towards the end: http://forum.umbraco.org/yaf_postst1061_LoadBalanced-servers-are-not-updating-on-publish.aspx

Mainly this involves changes to the /config/umbracoSettings.config file. This works of an Umbraco webservice – as the post states you do not need to enable the general webservices setting in the umbracoSettings.config, just enable the distributed calls.