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.
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.
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.