Browser ‘Back’ Button Mystery

Time for another post after long hiatus. It’s not like I didn’t have anything to share since last time I shared a post but all this time I did not struggle much with the problem until I got this one. So I named it as “Browser Back Button Mystery” and trust me It was a real mystery for me up until I found the solution to it.


One of our client reported a problem that whenever they fill the form with the required information and click on ‘Next’ button. They get to the next webpage with all the required calculations done based on the input and NOW when they hit browser ‘Back’ button, browser takes them to the previous page and all the data entered by the user is now lost. Users are frustrated because they have to enter all the information again. I assume here that users only needs to change few things on the full-page length form.

I also agree to the fact that relying on the browser back button to populate all the previous input values is not the right thing to do rather web application itself must have some ‘Back’ button for such purpose. Our client is reluctant to have such button on the web page. They also mentioned that this started to happen since we deployed an update to the portal recently.


I did the first thing first which is ‘Replicating the Issue’. Bang. I can replicate the issue in Internet Explorer (Yes, they are still using internet explorer). As I’m a chrome fan just like any other developer, I tried replicating this in Chrome and sadly as expected everything worked smoothly. Data was indeed populated. It was kind of mystery to me to see same thing behaving differently in different browser. I completely understand the fact all the browsers out there are written differently, hence, work differently. I always assumed that doesn’t matter which browser you use, basic functionality always remains the same and work the same way. Before blaming Internet explorer, I thought of giving this a go within Firefox and Safari, two other widely used browsers. It was working fine in Safari but not in Firefox. I knew why I got two groups here. This is because both Chrome and Safari are based on Web-kit whereas Internet Explorer and Firefox are not. All this investigation did nothing other than building more complex situation here.

After unsuccessful Googling and digging in StackOverflow forums, I thought there is some bug in Internet Explorer and Firefox which is causing this to happen but then I realized that Client mentioned something about the recent update to the portal.

So, I decided to compare two versions of the code, one before the update and other after the update. I couldn’t figure out anything that could have changed this behaviour. I also knew that this is working to perfection in Chrome and Safari, so code is not the problem. Situation got worse. No Idea what’s causing this strange thing to happen – Browser or the Code.


Then I had a kind of intuition that I should also match the references and specially their versions and Bang!!!!

“AjaxControlToolkit” was updated by NuGet to version 7.725.0 from 4.1.51116. This update has also added “AjaxMin” and “HtmlAgilityPack” as the new AjaxControlToolkit update is dependent on these two. When I updated these last time, I thought it will be by default support everything that version 4.1.51116 supports and will include more enhancements and fixes.

After realising that these reference libraries are updated, I rolled back to the version 4.1.51116 using the following command in Library Manager Console:

PM> Install-Package AjaxControlToolkit -Version 4.1.51116

The above command will fetch the specified version of the AjaxControlToolkit library from NuGet repository. This will also includes “AntiXSSLibrary”, “HtmlSanitizationLibrary” and “SanitizerProviders”.

Doing this resolved the issue and the Back button is working as expected back again. Everyone is happy but still I need to check change log of AjaxControlToolkit to see what’s been changed between versions.

Note: I still couldn’t figure out why the AjaxControlToolkit version 7.725.0 is not working as expected in Internet Explorer whereas version 4.1.51116 is working fine. I will always have some level of working expectation considering AjaxControlToolkit and Internet Explorer are both from Microsoft.

Tagged , , ,

Readonly Textbox Postback Issue in ASP.Net v2.0

Just discovered, if the Textbox has readonly property set to true in the design mode, postback won’t load the data back into the textbox in order to prevent the malicious user from changing text value that is read-only.

But it happens sometimes you don’t want to let user type in in the textbox like Date of birth. The alternative to that is as follows:

In the code behind on the page_load event add the following line.

if (!Page.IsPostBack)

txtDate.Attributes.Add(“readonly”, “readonly”);

This will do the trick and you can use the readonly textbox easily without losing value at the postback and let the use select the date using calender control.


Finding existing connections to the database and closing them

So like my case, you also find SQL Server not following you instructions :-). If you have any existing connections to your database, SQL Server will not let you rename or do any Alter Database operations because it cannot get an exclusive lock on the DB until all connections are dropped or closed or in worse case KILLED.

1. To find all the existing connections to your database. Do the following.

  • Go to SQL Server Management Studio
  • Open up Query editor and type ‘Exec sp_who’ or ‘Exec sp_who2’. This will display all the processes/connections that SQL server is serving at that moment. These two are the system stored procedures within the master database. Also note that these two stored procedure uses [master].[sys].[sysprocesses] system view to retrieve necessary information. For details on the processes/connections you can directly retrieve records from this view by writing SELECT statement.

Execution of stored procedure will display something like below:

2. Now, Take the value of ‘spid’ against the database (dbname). Don’t forget to check the login and hostname, just in case you’re killing the right connection. Suppose I want to kill the connection associated with ‘tempdb’ database then the spid will be 10. Also, remember you can only delete user process not the system processes. tempdb is taken here only for the sake of example.

3. Now, you’ve the spid of the process/connection you want to kill. Now go to query editor and write ‘KILL <spid>’. In our case, it should be ‘KILL 10’. This will kill the process with spid 10.

While killing the process, if you get an error saying ‘Cannot use KILL to kill your own process.’ then make sure the status of the process is not ‘runnable’ when you executed the sp_who.

If you have number of connections to kill and you don’t want to go one-by-one then you can certainly write a script to do that for you.


Configuring WCF Service with netTcpBinding

Apart from other bindings supported by WCF, I found netTcpBinding as more complex to configure than its other peers and less (rather scattered) information about the same over internet. I thought of putting it all together from the very first step at one place in order to make it easier for everyone including myself to use it as reference in future. So lets get started.

Remember : netTcpBinding hosting on IIS is only supported by IIS7 and later versions. I’m using Microsoft Visual Studio 2010 and IIS7.5 for this demo.

Step 1:

By default, IIS only supports HTTP or HTTPS. In order to let IIS support netTcpBinding, we first need to enable/activate WCF non-HTTP activation. To do that, Go to control panel > Program and Features > Turn Windows features on or off and then look for ‘Microsoft .NET Framework 3.5.1’ . You will see something like below:

Make sure you select both options. This will enable IIS to support HTTP, HTTPS, net.tcp, net.pipe, net.msmq, msmq.formatname.

Remember : After windows finish enabling these features, it will unregisters ASP.NET from the machine.

Step 2:

As this has unregisters the ASP.NET from the machine. So, next step is to register ASP.NET with IIS. To do this,go to Visual Studio Command Prompt and then type ‘aspnet_regiis -i’. This will register the ASP.NET with the IIS and you will be able to host your web application again.

Step 3:

Now next step is to check if you have required windows service running. Go to Administrative tools > Services and check the following service if they running, if not start them.

These three service ensures that IIS is able to listen to TCP request and also enable the port sharing.

Step 4:

As you machine is now configured to support netTcp, next step is to configure IIS to enable a website to use net.tcp port which is 808 by default. You can also change it any other port you want. Make sure you don’t configure net.tcp to port 80 because it is being used by HTTP and you cannot have two protocols running on the same port. Alternative, either change HTTP port to something else other than 80 (only if you want to use net.tcp on port 80, BUT it is not a recommended approach).

Now time to configure IIS. Open IIS and then go to your WebSite (‘Default Web Site’) and right click on it and then go to ‘Edit Bindings’. You will see the following:

Did you notice that you got whole list of protocols other than HTTP and HTTPS. This is because we have enable WCF non-HTTP activation in step 1.

Now select net.tcp from the drop down and you will have something like following:

In the ‘Binding information’ text box, you need to specify which port you want to use for netTCP connection. As I mentioned earlier, 808 is default but you can have any other port as well. Format is ‘port:ipaddress’ so I entered ‘808:*’ and then click ok.

Now you website is configured to listen TCP connection request on port 808. Remember if you have multiple website where you need to setup TCP then you have to do the same for all the websites.

Step 5:

Next step is to enable net.tcp protocol for your application in the IIS. To do that right click on your application in the IIS and then click on ‘Advanced Settings’ and look for property ‘Enabled Protocols’ and there enter ‘net.tcp’. List of enabled protocol is a comma-separated list so you can enable multiple protocols by separating them with a comma.

Now your website is fully configured to use netTcp binding. Next step is to configure your project to have WCF service on TCP port 808.

Step 6:

Open Visual Studio Project where you have your WCF service and then right click on the project and then go to project ‘Properties’. You should have something like below. Select ‘Web’ tab from left and change servers to be local IIS web server instead of Visual Studio Development Server and change Project URL and point it to your IIS application.

The reason we have changed Server to be Local IIS Web Server instead of Visual Studio Development Server is that you can configure IIS Web Server to support net.tcp but you cannot configure the same for Visual Studio Development Server. This is because, Visual Studio Development Server only supports HTTP.

Now the next step is to configure your web.config of the project to support netTcpBinding for the WCF Service.

Step 7:

Our last step is to configure web.config to use netTcpBinding for the WCF Service. Following the sample of web.config on how it should for a WCF service using netTcpBinding.

Now there are few points to note:

– ‘httpGetEnabled’ attribute of ‘serviceMetadata’ must be set to ‘false’. This will allow to discover WCF service metadata over non-HTTP protocol.

– Note we are using ‘mexTcpBinding’ for the mex endpoint. You can also use ‘mexHttpBinding’ but then you have to set ‘httpGetEnabled’ attribute to ‘True’ and you should be able to locate your WCF Service using http address instead of net.tcp.

–  Its important that you specify the baseAddress for your endpoint. This will help IIS to let find your WCF Service. It will then know where to look for.

Step 8:

Next and final step is try and find your WCF Service in the browser.

Please note: you will only be able to discover service metadata in browser if you have set httpGetEnabled to True and have used mexHttpBinding instead of mexTcpBinding in the web.config. This is because, web browser only supports HTTP and HTTPs. Oterwise it will only be discoverable from within visual studio itself (see screenshot one after the below).

And now try using Add Service Reference option where you want to add the reference to this WCF Service.

Thats it and your ready to go.

Following are the errors you can encounter if you skipped or didn’t do any step properly.

Issue 1:


– Check if you have correctly enabled the protocols for the application in the IIS (Step 5).

– Check if you have mentioned proper baseAddress in the web.config (Step 7).

Issue 2:


– Perform Step 2.

Tagged , ,