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!

I recently stumbled upon a not very well documented "design feature" that took me a couple of hours to track down.

If you are defining a custom delete function for an ObjectDataSource you must also remember to define the DataKeyNames property of the GridView you are working with. If you do not remember to do this, the object’s value passed to your delete function will be null.

You can read more about the ObjectDataSource delete issue here.

Hope this helps!

When you need to dynamically create a control or use another page's code in your code behind use the reference directive ->

http://msdn.microsoft.com/en-us/library/w70c655a.aspx

Note that you can sometimes get away with only registering the control. But expect to experience some odd compilation problems especially when dependent code is changed...

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.

If you are trying to debug ASP.NET applications on Vista you might run into the following problem:

localhost is not accessible through your browser and the error that is displayed is "Internet Explorer cannot display the webpage".

After some googling I ran across a reference to the same problem.

The problem has to do with the fact that there are 2 entries for local host in the hosts file ([Windows directory]\System32\drivers\etc\hosts).

One for ipv4 and one for ipv6.

Example:

127.0.0.1 localhost
::1 localhost

To solve the problem you can remark one of them. The example below remarks the ipv6 entry.

127.0.0.1 localhost
# Causes problems when using localhost ->
#::1 localhost

Note that you might not be able to modify the hosts file even if you are running as an administrator.

The following Microsoft KB explains how to change the hosts file:

http://support.microsoft.com/default.aspx?scid=kb;en-us;923947

Hope this helps...
 

Sometimes it is useful to get the base URL of a given URL.

For some reason there is no built in function in the URI class to do that.

A simple implementation of a function to get the base URL from a given URI would be:

As a usage example if we call extractBaseURLFromURL and supply the following URL

http://msdn2.microsoft.com/en-us/netframework/default.aspx

The function will return the following URL 

http://msdn2.microsoft.com

----------

 Update:

Example:

Below is a simple code snippet to redirect from a non secure HTTP URL to a secure HTTPS URL using C# and ASP.NET.

The code checks if we are using a secure connection and if not it redirects to the same requested URL changing the protocol from HTTP to HTTPS.

// Check if we are using https and if not redirect

If you are trying to access an ASP.NET Session object from inside a static function you will encounter error CS0120:

"An object reference is required for non static field, method, or property... "

The problem is that the Session object is a non static member of the Page/Control class you are using.

When you are inside a static function you do not have access to non static members of your class.

Example:

// this function is ok inside a page or control

void testFunc()

{

The solution to the problem is to access the Session object from another static object/function that has access to the current Session object.

Enter  HttpContext.Current.Session -> http://msdn2.microsoft.com/en-us/library/system.web.httpcontext_members.aspx

The Session object obtained from HttpContext can be used from inside a static function since HttpContext.Current is a static property.

Here is an example of how to use it:

// this function is ok inside a page or control

I don't know if this is a new Microsoft trend or not but for the second time in the past week  I came across an important, missing or hard to find download link for a Microsoft product.

This time around the missing download is AJAX 1.0 Extensions for ASP.NET 2.0.

Normally you should be able to find the file at http://www.asp.net/ajax/ but for some reason it disappeared and only AJAX version 3.5 download links exist over there.

Could that be because Microsoft is trying to aggressively push ASP.NET 3.5. which includes AJAX version 3.5?

In any case the name of the installation file is ASPAJAXExtSetup.msi and you can find the download link at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=ca9d90fa-e8c9-42e3-aa19-08e2c027f5d6&displaylang=en

If you are trying to use an ASP.NET web custom control and you receive the above error.

Make sure that you specify the name of the assembly and not the complete or partial path to the assembly in the register directive.

Example:

Lets assume you have a name space called MyNameSpace and a dll file called MyNameSpace.dll that contains that name space.

The following 2 variations will produce this error:

The problem is that you must not use the path or file name of the dll in the assembly property of the register directive.

To solve the problem only specify the assembly name in the assembly property of the register directive: