After years of deploying web site files using custom FTP, Remote Desktop File Transfer etc. We decided to give VS 2010 Publish Web FTP a try.

It worked flawlessly the first couple of times until we started receiving errors on the staging/deployment server that were not reproducible on the development machines.

After doing some digging around, we found out that the web publish process was the culprit.

It turns out some files were not being replaced/updated when their versions changed on the development machines.

In our case they were web server controls sitting under one of the web site sub folders.

For some reason the web publish process did not detect changes even though earlier file versions were previously deployed correctly. It seems like there is a bug in the file change detection algorithm inside the FTP publish web process.

To solve the problem we had to force the publish web process to detect changes by deleting all the old files before deploying a new version.

To do this make sure you check the “Delete All Existing Files Prior to Publish” option in the Publish Web dialog/FTP publish options:

It makes deployment slower but at least you know you get the latest version of the files each time you publish.

Good luck!

This is the second time I had to find the solution to install self assigned SSL certificates on IIS so I am writing this down for posterity.

In many cases it is desirable to create your own SSL certificate when working with IIS.

For example when developing/testing SSL secure web sites, when using a custom web application in a local intranet or for a closed  group of users to name a few.

It should have been easy to create your own SSL cert and instruct IIS to use it.

Microsoft delivered a tool to do just that. It was a part of the IIS 6.0 Resource Kit and it was called SelfSSL. But alas because of a bug in the SelfSSL tool you will run into problems if you try to use multiple certificates on a server.

Apparently Microsoft decided not to release a patch for the resource kit but instead released another tool that can be used to create self SSL certificates called SSL Diagnostics.

The tool is very easy to use. There is a nice tutorial on how to use the SSL Diagnostics tool to create an SSL certificate by Revindex.

Another option you might want to explore is using the open source alternative called OpenSSL. There is a nice tutorial on how to use OpenSSL with IIS by Dylan Beattie.

Best of luck!

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.