views:

385

answers:

3

We have an old Classic ASP application that we have been using Visual Studio 6 to maintain. This has worked fine, but we're ready to step out of the stone age and I'd like to see if I can use Visual Studio 2008 (SP1) to maintain the application.

In the past, multiple developers could work on the application and it was under source control. We had FrontPage Server Extensions (FSE) installed on the web server and there was some sort of three-way integration between Visual Interdev on the client, FSE on the web server, and the SourceSafe database that let us check files in and out through Interdev. Files were checked out to the web server, not to the client. And when checking a file back in through Interdev, we could press a "Diff" button to review the changes to the file before checking it in.

Now I have installed Visual Studio 2008 (SP1) and I'm trying to get the same functionality. I used File/Open Web Site/Remote Site to bring the project up. This works fine and I am able to check files in and out. However, the option to view the differences is disabled. Also, when I enter a comment on the Check-In dialog window, the comment gets ignored. In other words, if you use the SourceSafe standalone client to look at the history of the file, the file gets checked in properly, but there is no comment.

In VS2008 after I check out a file, when I right-click on it, the "Compare" and "View History" options are disabled. Also, if I click on the Check-In option, the Compare Versions button in the Check-in dialog is disabled. Is there any trick to enabling the Compare option?

A: 

Make sure your solution is bound to source control correctly (File -> Source Control). Also check the Source control settings in the options dialog, making sure the correct provider is selected.

If you create a new project (.NET) and add it to source control, do the functions work?

Robert Wagner
A: 

Good question (about adding a new project to see how that works). I created a new ASP.NET web site but Visual Studio told me that it couldn't add the web site to source control because you need to do this through FrontPage Server Extensions on the web server. I ran the IIS Manager on the web server and added the web site to SourceSafe. Then the next time I opened the project in VS2008, it showed up under source control. However, the View History and Compare options were still disabled.

So, I guess this problem has nothing to do with my old classic ASP site. Perhaps it is just a limitation that exists when you use Visual Studio 2008 against a remote web server running FrontPage Server Extensions 2002. Is there a newer version of FPSE? Also, does it matter that I do not have ASP.NET 3.5 enabled under IIS on the remote server? Right now it only has ASP.NET 2.0 enabled.

CowherPower
Please use add comments to respond to specific answer, edit your question to add further details. Only add an answer if you have an actual answer to the question. SO is not the same as Forum or a newsgroup, sort by votes is the most common view making a mess of any sequential responses.
AnthonyWJones
ASP.NET 3.5 is an additional set of DLLs on top of ASP.NET 2.0. Your web site will still be running under the ASP.NET 2.0 framework.
Zhaph - Ben Duguid
Thanks for the responses guys. I have done further tests against other servers and confirmed that the Compare and History options just aren't available when using VS2008 with FPSE. I have switched over to a file system website and now I'm much happier with the SourceSafe integration.
CowherPower
A: 

Typically I don't use IIS for development anymore. With VS2005 and VS2008 you can create file based websites (or web appllications) that run with the webserver built into VS. Then you don't have to fool with IIS, front page extensions or the permissions issues that IIS imposes. With classic asp this was always a hassle of some kind.

It is very rare that there is a "fidelity" difference between the vs website experience and the IIS so that when I deploy to IIS I don't worry about differences after the intial IIS setup. The debugging within VS works pretty much flawlessly, debugging on IIS can present some issues.

So then the source control seems to work very easily as well and is confined to my dev directory.

Data Dave