Speaking of which... : Bugs

Using IE6 With Visual Studio 2008

JohanS — Wed, 26 Mar 2008 19:04:08 GMT

Here's a little scenario I came across the other day. I've forwarded the information to development, so it's pending further investigation. I still thought it would be a good idea to publish the scenario though.

Visual Studio 2008 + FTP = Possible trouble

It seems like there might be a bug in Visual Studio 2008 when it comes to projects that you access via FTP. I don't know how common it is to use FTP to access & deploy your projects. It would be really interesting to see some genuine statistics, but since FTP is highly insecure I guess it is very rarely used. This, I guess, is probably the reason why this little glitch slipped through in the first place.

File change notification works fine...

Consider the following scenario:

You're working on a web project using FTP
You've downloaded a file to your local cache and you're doing some changes.
Another client changes the file
You attempt to save the file, but the original file on the server has changed so it no longer matches the one in your local cache.

This causes a warning to pop up with the following information:

A more recent version of the file [File Name] has been saved to the web on '[Date]' . Do you want to replace the server file with your local file?

...overwriting the file doesn't

Clicking Yes you'd now expect Visual Studio to simply overwrite the file on the server. Unfortunately this is where the glitch rears it's ugly head. Instead of overwriting the file it gives you the following error message:

Cannot save the file [File Name] to the Webserver. The file [File Name] has been modified by (unknown) on [Date] [Time Zone].

Continuous attempts at saving will have no effect. The error pattern will repeat, displaying the two dialogue boxes over and over again.

Alternative solution

My customer originally fixed this by selecting everything in the editor, copying it to Notepad, canceling the operation in Visual Studio, reopening the connection, pasting the contents from Notepad into the document and saving. Fortunately there's an easier way to resolve it.

Simply click the Refresh-button in the Project Explorer window. Visual Studio will then ask you if you wish to update your cached version of the files you've edited. This may sound like you're going to perform a revert-to-save operation on the pages you've edited, undoing all the changes, but it's actually not the case. Visual Studio will simply refresh the files in the cache, not the ones in the editor. When Visual Studio has finished refreshing the cache it will notice the inconsistency between the files asking you if you want to update the file in the editor as well. At this point you should answer "No", unless you want all your changes undone.

My thoughts about this

Obviously this shouldn't happen. You shouldn't have to refresh the cache in order to overwrite the files. Still, as I mentioned before I believe there are two reasons why this problem managed to slip through the cracks.

FTP is unsafe. Even the password is sent as clear text and can be intercepted by anyone. For this reason I would assume that FTP is quite rarely used.
In order for the problem to occur you need to trigger a file change notification on the file in question. For normal scenarios this would mean that another client accesses the FTP-site at the same time and changes the file as you're working on it. This type of on-the fly editing without any form of source-control would be highly risky in a production environment and you'd most likely use some other means of connection while in development.

Visual Studio 2008 + FTP + Internet Explorer 6 = More trouble

Unfortunately the problem doesn't end there.

It turns out that if you are using Visual Studio 2008, are working on a web project using FTP and have IE6 on your machine, then IE will act as if a file change notification has occurred after 90 seconds wether this is true or not. This means that after 90 seconds all your attempts to save will trigger the behavior described above. The refresh cache-approach still works, but it will quickly become quite tedious.

According to the prerequisites for Visual Studio 2008, Internet Explorer 6 is a minimum requirement, so there is nothing documented on IE7 being a necessity in order to run Visual Studio 2008.

Alternative solution

So far I only know of one way to resolve this. Install IE7. You'll still encounter the first potential problem if you have more than one client working simultaneously on the same application, but as I've already mentioned, this sounds like a very unlikely scenario.

/ Johan

Aspnet_state.exe crashing on Xp

JohanS — Fri, 21 Dec 2007 18:35:07 GMT

I ran across an interesting situation with a customer today.

He had a workstation running Windows Xp Professional. He'd previously been running Framework 1.1 and had been using the ASP.NET State Service. He had now upgraded to framework 2.0. and upon shutdown he now received the following error:

aspnet_state.exe. Application Error. The instruction at "0x6a2a2fec" referenced memory at "0x0000000c". The memory could not be "read".

To make a long story short it turned out this was due to an access violation upon shutdown. We did the following and resolved the situation:

Start Regedit.
Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_2.0.50727 key.
Right-click "Names" and select Permissions on the context menu.
Click Add and enter NETWORK SERVICE, click "Check Names" and click Ok.
With NETWORK SERVICE highlighted in the "Groups or User Names" list click "Advanced".
On the "Advanced Security Settings for Names" dialogue highlight NETWORK SERVICE and click "Edit".
In the "Permission entry for Names" dialogue check the "Name" box is showing "NETWORK SERVICE" and put check marks against "Query Value", "Set Value", "Create Subkey", "Enumerate Subkeys", "Notify" and "Read Control".
Click Ok on all the dialogues and close Regedit.

As I assisted him it turned out my customer had searched the web for a solution and had found quite a few people experiencing the same problem. I guess most of you are working with Windows 2003 / Vista, so this information might be a bit obsolete. But I thought I should share the knowledge anyway.

Happy Holidays! / Johan

I've upgraded and now my application doesn't work anymore

JohanS — Tue, 23 Jan 2007 19:09:47 GMT

Scenario:

A quite common scenario when working in the support industry is a call along theese lines:

"My application worked just fine, but now that I've upgraded to IE7, IIS6, Vista, etc. it doesn't work any more. This has got to be a bug! This new version of the software obviously isn't any good, so when are you going to fix it?"

Is it a bug?

Well, possibly. But most likely the bug doesn't lie within IE, IIS or the operating system. Instead you should look at your code to make sure you did everything following the recommended guidelines. Chances are that you didn't do things the right way originally, and for some reasons the previous version of the software was more forgiving.

Example

A little while ago I had the following scenario on my hands:

A customer had just upgraded their webservers from Windows 2000 to Windows 2003. After the upgrade certain requests just "vanished" into thin air. The response never reached the clients. We managed to track down the problem to the following lines of code:

this.Page.Response.ClearContent();
this.Page.Response.Write(TextToWrite);
this.Page.Response.Flush();
this.Page.Response.Close();

Okay, so you probably see what is strange here. Why are they calling Response.Flush() and Response.Close()?

If we remove theese two lines and replace them with Response.End() then everything works fine:

this.Page.Response.ClearContent();
this.Page.Response.Write(TextToWrite);
this.Page.Response.End();

Okay, so this is the proper way to do it. Response.End() will call actually call Response.Flush() and then gracefully end execution of the page, while Response.Close() will simply "cut the cord". But how come it worked in IIS5 and not IIS6? Does this mean that IIS6 is a bad product? - Not at all!

One of the things that changed with IIS6 is that it now processes responses asynchronously. This means that in IIS5 all execution will be paused until the page has been sent, while in IIS6 the response will be put in a send-buffer, allowing IIS to immediately continue execution. This is one of the reasons why IIS6 is both faster and more secure than IIS5. The thread executing the page does not have to take the connection speed of the client into consideration. It can execute the page and move on to the next. In IIS5 all execution on the thread would be stopped until the client had downloaded every last bit. This made the server more vulnerable to Denial of Service (DOS) -attacks, and something as trivial as a bunch of clients with poor modem connections could impair the performance of the server.

In brief, here’s what happened with the old code:

IIS5:

Response.Flush sends data to client
Thread waits until data has been sent
Response.Close closes client connection

IIS6:

Response.Flush puts the data in a send buffer and immediately moves to the next line of code
Response.Close closes the client connection before the data has been sent

Here’s what happens with the new code:

IIS5:

Response.End is called

The data is sent to the client
IIS gracefully ends all further execution of the page

IIS6:

Response.End is called

The data is transferred to the send buffer
IIS gracefully ends all further execution of the page

Summary:

The old code was incorrect, but worked anyway due to the synchronous design of IIS5. As IIS6 switched to an asynchronous response model this stopped working. I can sympathize with anyone that feels that this is a bug/mistake, but in reality it isn't. In fact it is a very concious choice made to further improve performance and reliability.

/ Johan