Last post Jul 03, 2011 12:53 PM by whighfield
Jul 02, 2011 02:26 PM|Mobieus|LINK
I have an existing site remotely hosted which was a classic asp site. After resisting the change to asp.net as long as possible I find myself having to finally make the turn. I have been actually trying for many years now but something always puts up a solid
wall. The last of which was the complete refusal of "visual studio 2008(not responding)" to allow me to use it completely. I now use visual web developer 2010 which works about 80% of the time. The wall that has me stumped is Developing and deploying to my
current site. If I open the project using the FTP option it works great for editing the site but the debugging is nonexistant so development is shot. So next I tried importing all my files to my local machine and the debugging works great but Deploying back
to the original site is totally disconnected. Since I can't have both projects open at the same time in MSVWD2010 I'm stumped. Sure I can use a third party work around like editing in a text editor and using another FTP program I'm almost certain I'm doing
something wrong. This has prevented me from getting onboard with ASP>NET in spite of my longing to be able to make the turn for years. Can anyone help me?
Jul 03, 2011 12:53 PM|whighfield|LINK
First development and deployment are two separate beasts that should be handled differently. As hard as MS has tried to make deployment easier for devs when it comes to *external*
hosted sites and projects none of their *tools* work that well since no hosting company does it the *Microsoft* way. This can even go for some *internal* hosted sites.
My advice is do all of your work locally debugging and enhancements, then publish your site manually via FTP (not using the built in tools). The problem with the built-in tools
is that they don't really know what can or cannot be published (or if it should be published). The only feature in VS that I use is the *Publish web site* feature and I always publish to a local folder
(Publish) then *merge* that folder with the *live* site using some kind of 3rd party tool that can do folder synchronization between the publish folder and the *live* site via FTP (I wrote
my own to do this)
Also the publish folder that I use is also the *testing environment* that I do testing on before I merge with the live site. The publish folder usually resides on a separate
machine on the network. It's function is purely web server only to mimic the environment the site runs under as closely as possible. The reason for this is the old saying *just because it works locally does not mean it will work anywhere else*. I am sure
that almost all developers can relate to that comment. In some cases the *testing environment* can be a test site on the live server just with its own separate config and database (depending on the environment).
Is this overkill, a lot of developers might agree, but I have complete control over how/when/what gets published.
As a side note I have been able to work on hybrids of classic ASP and ASP.NET sites at the same time being able to debug (and step through) both code bases. It is a bit tricky
setting up VS2010 for classic ASP debugging but it can be done.