Interdev to .NET - who's done it?
Discussion
The time has come for us to migrate our product into the latest development environment.
We have a ton of .ASP pages in an Interdev solution - and we're not porting them to ASPX - they work fine.
But we *do* want to migrate the development environment to be Visual Studio .NET compliant.
We need a multi-developer environment from the off as at least two of us code almost constantly...
So - has anyone done this? i.e. Ported an Interdev app into VS.NET, largely keeping the ASP pages the same, but using all the new tools and so on?
Interdev used to manage file get and release by itself...do we need to use SourceSafe now?
All words of wisdom from anyone who has gone before - MUCH appreciated!
TBH - we are doing this as the old development tools are dropping off support - the debuggers fail to work and no-one can be bothered to fix it and so on. So we want a fresh new development environment - but we also want as little disruption to our source code base as possible. In the future we will then create new modules within the app in ASPX files...but the whole thing may *never* be turned into a pure ASP.NET project...
We have a ton of .ASP pages in an Interdev solution - and we're not porting them to ASPX - they work fine.
But we *do* want to migrate the development environment to be Visual Studio .NET compliant.
We need a multi-developer environment from the off as at least two of us code almost constantly...
So - has anyone done this? i.e. Ported an Interdev app into VS.NET, largely keeping the ASP pages the same, but using all the new tools and so on?
Interdev used to manage file get and release by itself...do we need to use SourceSafe now?
All words of wisdom from anyone who has gone before - MUCH appreciated!
TBH - we are doing this as the old development tools are dropping off support - the debuggers fail to work and no-one can be bothered to fix it and so on. So we want a fresh new development environment - but we also want as little disruption to our source code base as possible. In the future we will then create new modules within the app in ASPX files...but the whole thing may *never* be turned into a pure ASP.NET project...
Yup have done it.
The upgrade to VS.Net is painless, however the install takes ages.
To use VS.Net on you existing projects you have to create new projects, however there may actually be migration tools in the released version of vs.net. (i did my upgrade when it was a beta product). I am currently using VS.NET 2005.
VSS still works as part of VS.NET without problems, though if you are developing against a web server linked to VSS etc. i found it easier to use a File share based web rather than one accessed via FrontPage server extensions.
VS.NET 2005 has the ability to use the New Microsoft Team Services which uses SQL2005 and Sharepoint to provide full code collaboration between development teams, the features include version control, project management etc and also Issue management (bug logging)
The upgrade to VS.Net is painless, however the install takes ages.
To use VS.Net on you existing projects you have to create new projects, however there may actually be migration tools in the released version of vs.net. (i did my upgrade when it was a beta product). I am currently using VS.NET 2005.
VSS still works as part of VS.NET without problems, though if you are developing against a web server linked to VSS etc. i found it easier to use a File share based web rather than one accessed via FrontPage server extensions.
VS.NET 2005 has the ability to use the New Microsoft Team Services which uses SQL2005 and Sharepoint to provide full code collaboration between development teams, the features include version control, project management etc and also Issue management (bug logging)
Some guidance here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vetchWebProjectsSourceControlIntegrationInVisualStudioNET.asp
I would suggest you adopt the isolated development model, where each developer runs IIS on his own machine. Its a life saver when you want to use the debugger and makes testing much easier (changes another developer makes aren't affecting your copy of the site). We tend to use a single development SQL database, some people use a local copy for each developer.
This document covers most issues you may have with setting up debugging:
www.gotdotnet.com/team/csharp/learn/whitepapers/howtosolvedebuggerproblems.doc
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vetchWebProjectsSourceControlIntegrationInVisualStudioNET.asp
I would suggest you adopt the isolated development model, where each developer runs IIS on his own machine. Its a life saver when you want to use the debugger and makes testing much easier (changes another developer makes aren't affecting your copy of the site). We tend to use a single development SQL database, some people use a local copy for each developer.
This document covers most issues you may have with setting up debugging:
www.gotdotnet.com/team/csharp/learn/whitepapers/howtosolvedebuggerproblems.doc
Mark.S said:
I would suggest you adopt the isolated development model, where each developer runs IIS on his own machine. Its a life saver when you want to use the debugger and makes testing much easier (changes another developer makes aren't affecting your copy of the site). We tend to use a single development SQL database, some people use a local copy for each developer.
This is exactly the model we have adopted with Interdev - a single SQLServer database, then each developer using "Local Mode" to have a copy of the web app and do debugging. Interdev then maintains a central copy of the app to which developers "release" blocks of changes when ready.
We would like to replicate this model in VS.NET - I may be being dim here but I cannot figure out whether VS.NET maintains this central copy for you like Interdev did or if I will need to use SourceSafe to do it now.
How did *you* go about dealing with this? It sounds like you have a very compatible model with what we want to do...
Thanks so much for your input - its appreciated.
PetrolTed said:
I'm in a similar position. What benefits are there to be had from using VS.net as opposed to interdev?
What we are hoping to achieve is
a) Superior debugging capabilities - we have found that ASP debugging works/doesn't work/falls over/ is generally flaky and we want something more solid.
b) The ability to slowly, slowly migrate to ASPX pages written in C#.
We have our own custom middleware that allows client side web-pages to interact with the server - either with the database directly - or via an ASP page back end - we can do this without page turnarounds and we consider this a superior model (for *our* app) to the usual .NET high-turnaround model.
So for us the new "State Maintenance" features of ASP.NET are good - but no cigar. We *would* benefit from being able to write server side scripts in C# rather than VBScript - which whilst OK is a pretty poor language in comparison. In theory we should gain some better performance too - although this hardly matters.
Really its the debugging and reliability improvements in the development tools we're after rather than anything else...
If your not yet using some form of source control, you really need to be! Once your using it properly you'll wonder how you lived without it.
Sourcesafe was, and still is, pretty flakey. The version they're shipping with VS2005 isn't much better (a few new features on top of the same appalling database) but Team System uses a totally different source control server.
Take a look at www.sourcegear.com/vault. Fantastic product and very reasonably priced.
There are quite a few gotchas to using debugging in VS.NET with classic ASP, the document I linked to covers most of them. In particular, the debugger can't break in to includes if they are referenced as VIRTUAL , has to be FILE. Even then I had difficulties with 'run to cursor' within includes. Those issues aside, it definately works better than in Interdev.
If your planning a gradual migration from ASP to ASP.NET, as far as I'm aware there is no way to share Sessions between them. If you use a custom session store in the database this won't be as much of a problem.
I would also suggest you consider diving straight in to .NET 2 if the migration is likely to take you some time. Some literally mind-blowing new features that you may find useful such as Master/Detail pages and Webparts. Beta2 is apparently due soon, but you'd need to check the licensing issues around commercial deployment of anything based on the beta.
Once you get to grips with ASP.NET you'll want to throw ASP in the bin and re-write your system from the ground up.
Sourcesafe was, and still is, pretty flakey. The version they're shipping with VS2005 isn't much better (a few new features on top of the same appalling database) but Team System uses a totally different source control server.
Take a look at www.sourcegear.com/vault. Fantastic product and very reasonably priced.
There are quite a few gotchas to using debugging in VS.NET with classic ASP, the document I linked to covers most of them. In particular, the debugger can't break in to includes if they are referenced as VIRTUAL , has to be FILE. Even then I had difficulties with 'run to cursor' within includes. Those issues aside, it definately works better than in Interdev.
If your planning a gradual migration from ASP to ASP.NET, as far as I'm aware there is no way to share Sessions between them. If you use a custom session store in the database this won't be as much of a problem.
I would also suggest you consider diving straight in to .NET 2 if the migration is likely to take you some time. Some literally mind-blowing new features that you may find useful such as Master/Detail pages and Webparts. Beta2 is apparently due soon, but you'd need to check the licensing issues around commercial deployment of anything based on the beta.
Once you get to grips with ASP.NET you'll want to throw ASP in the bin and re-write your system from the ground up.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff