Port 443 - Configure your firewall

Dot .Net Dilemmas
We were having some issues recently where a client could not register our software.
We got an email from them asking if we "used any any ports other than Port 80 or 8080 during the registration process?"
It turned out that they were behind a firewall where all ports were 'locked down' unless the firewall was specifically configured to allow them access. This meant that their firewall was blocking access to one of our web services but they weren't sure why. They had configured it to enable access to Port 80 and Port 8080 and assumed that this was all that they needed to do.

As part of our registration we use Port 443 for HTTPS calls (note the 'S' at the end.) Using a HTTPS URL indicated that HTTP is to be used but with a different default TCP Port - Port 443. Port 443 an additional encryption/authentication layer between the HTTP and TCP and is widely used for security-sensitive communication such as payment transactions and corporate information systems. Port 80 is typically used for unsecured HTTP calls. They configured their firewall to enable communication through Port 443 and so far so good, all registrations have gone through.

You can check the Ports used by opening IIS and clicking on 'Web Sites'. The Ports will be displayed against your various web sites in the right hand pane.

How do you show "<" and ">" on your blog page?

Dot .Net Dilemmas
In yesterday's blog I was trying to show an entry in a web.config file and I couldn't get the "<" to be displayed correctly so, my output was displayed as:
compilation defaultlanguage="c#" debug="false"

when of course I wanted to display it as:
<compilation defaultlanguage="c#" debug="false">

Turns out to be very simple (once you know how)
&lt; = <
&gt; = >

So
&lt;compilation defaultlanguage="c#" debug="false"&gt;
Would display as
<compilation defaultlanguage="c#" debug="false">
That's it.

Another you might need to use is:
&quot; = "

And while I'm at it, if you want to actually display &lt; and not < etc. on your blog:
Use &amp; before the &lt;

Making HTTP 'appear' more reliable.

Dot .Net Dilemmas
I was listening to the .NET Rocks episode 'Udi Dahan Scales Web Applications!' (date 12/08/2008) and about 1/3 of the way through it they discuss something that is, what I consider, very important and seldom discussed issue regarding making HTTP 'appear' more reliable and give our users a better and more confidence building experience while using our web sites or services.
(Some of what is written below is from notes that I have taken while listening to the .NET episode so I am not claiming this to be an original idea.)

Something that I have always struggled with is, what to do when I am on a web site purchasing something and I go to make a payment by clicking the ‘Submit’ button and hey-presto; nothing happens?
I think that it has been drilled into us over the years NOT to hit that submit button again as it could mean multiple payments on our credit card. If you are like me, you simply click the little ‘X’ button at the top of the page or browser and keep an eye on your card transactions over the next month. So, how do we stop this happening when we are designing our own sites where we want to instill some customer confidence and not lose customer business?

I came across what at the early stages sounds like a pretty good and clean solution to this problem but as yet, I have not tried to implement it.

Basically HTTP is inherently unreliable and there is not much in the broader sense of the internet that we can do about this. However, there are a number of steps we can take to lessen the impact of this shortcoming.
Basically we design a retry protocol in such a way that if we send a request from the browser to the server we don’t get a satisfactory response back from the server in a reasonable time (for any action on data where we need to ensure it remains consistent), we resend the request again.
We would also need to ensure that server side code is designed in such away that, even is the request is sent any number of times, it is only processed once. One way we could do this is to tag a GUID (Globally Unique IDentifier ) onto the request. The same GUID would be also tagged onto the response and in this way, it wouldn’t matter if the first request got lost or the first response got lost we can be pretty sure that the data that was sent was received and processed. From the user’s perspective they don't see any of this as it is all under the hood. Until that point where we say ‘yeah, we got your data’, we can ensure that our service is fairly reliable on top of an fairly unreliable protocol (HTTP).

As I’m sure you can see, this sounds a very promising solution to what is, from what I can see, a pretty universal problem for any web site that has to ensure data persistence. I am going to try and implement this on some of the web applications that I use to take customer payments over and I will update my blog on how I got on and problems that I had to overcome but for now, as I am off to Uluru for the weekend, I’ll simply post this as a reminder.

Unable to start debugging... - Part 2.

Dot .Net Dilemmas
Ok, I just got over the hump of trying to run a project developed in VS2003 with .NET 1.1 in VS2008 with .NET 2.0 or 3.0 when I get the 'Unable to start debugging on the web server' message AGAIN but with a different twist.

"Unable to start debugging on the web server. The web server is not configured correctly. See help for common configuration errors. Running the web page outside of the debugger may provide further information."

One thing that you can check first is that you have debug enabled in your web.config file. I know that this sounds obvious but it has caught me and others out on more than one occasion.

Step 1: Open the web.config
Step 2: If debug is set to "false" change it to "true".

Example:
In the web.config there will be a line similar:
<compilation defaultlanguage="c#" debug="false">

Change this to:
<compilation defaultlanguage="c#" debug="true">

(Don't forget to set this back to 'false' before you promote the code to production)

If this doesn't work, as the message says, It usually means that the web server is not configured correctly but, have you ever looked at the list that Microsoft recommend that you check to try and get it working?
I have spent hours and hours trying to implement all these 'checks' and it still didn't work. All I want to be able to do is debug the application so that I can finish me work. So, one of the great things about VS since 2005 is the ability to use the Visual Studio Development Server to run and debug your web based .NET work without the need for IIS.

The steps:
1. Right click on your project in VS2005/2008.
2. Click on Properties
3. Click on Web tab
4. Under Servers, click on the radio button Use Visual Studio Development Server
5. Check Auto Assign Port radio button
6. Uncheck NTLM Authentication and Enable Edit and Continue

Unable to Start Debugging on the Web Server.

Dot .Net Dilemmas.
"Unable to start debugging on the web server. Debugging failed because integrated Windows authentication is not enabled."

Two possible solutions that have worked for me in the past:

Solution 1:
Start --> Control Panel --> Programs And Features --> Turn Windows features on or off



Select
Internet Information Server --> World Wide Web Services --> Security
Check
Windows Authentication


Be warned, this can take a LONG time to complete and you may think your PC has hung but stay with it.

Solution 2:

1. Open IIS 7. Click "Default web sites"
2. Under 'IIS' Click "Authentication"

3. Ensure that “Anonymous Authentication” and “Windows Authentication” are 'Enabled'.

ASP.NET "Could not load file or assembly App_Web..." Error

Dot .Net Dilemmas.
God, I spent a lot of time over the last few months looking for a proper solution for this one and at the end of the day, the best solution I found was to delete all temporary ASP.NET files, by removing the folders under

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

I closed down all instances of VS before doing this just to ensure that all the files were released so that they could be deleted.