Slow File Transfer To Remote Site Using VS2008

[Chip Pearson]

I don't know if this is the correct newsgroup, but I can't find a
group specifically for Visual Studio 2008.

I have a web site that I develop using ASP.NET in Visual Studio 2008.
Am I correct in assuming that the only way to transfer pages to the
web server at the host company (they're running Windows Server 2008
and IIS 7) is to transfer by FTP?

Related to that, it takes a LONG(!!!) time to transfer a page from my
local machine to the server. Even a simple page, say 4KB, takes
several minutes. The majority of that time VS seems to be doing
nothing, then the transfer takes place quite quickly (at least by
judging from the Progress Bar), and then there is a delay of at least
a minute after the FTP complete and VS becomes usable again. If it
matters, my local machine is an HP 9400 with Quad Core CPU, 8 GB RAM,
and Windows Vista Ultimate 64-Bit. Aside from the problem with VS2008,
the machine is a speed demon. Fast fast fast.

This is terrible performance. Is this a problem with VS2008? The
server-side software? FTP problem? Should I give up on publishing
from within VS2008 and use a dedicated external FTP program (I have
SmartFTP on the local machine)?

Any advice would be most welcome. And if there is a more relevant
newsgroup for this question, please let me know.


Cordially,
Chip Pearson
Microsoft MVP
Excel Product Group
Pearson Software Consulting, LLC
www.cpearson.com
(email on web site)

 

[Gregory A. Beamer]

I find the deploy to ISP experience to be far less than stellar in any
version of VIsual Studio, and worse when an ISP is not set up properly.

Personally, I use the publish feature and then publish locally. After that,
I upload the content to the server using tools outside of Visual Studio.
This willl change a bit in Visual Studio 2010, where they have added one
click deploy for the web, but that will not be around until November and I
am not sure what the picture will be for the ISP.

 

[Chip Pearson]

Personally, I use the publish feature and then publish locally.

What does that actually do and why would I want to publish locally and
then, I assume, FTP the published site up to the ISP host? Is this
better than just FTP'ing the entire www directory up to the host?

I upload the content to the server using tools outside of Visual Studio.

By this, I assume some sort of XCopy or FTP. Correct?

Thanks.

Cordially,
Chip Pearson
Microsoft MVP
Excel Product Group
Pearson Software Consulting, LLC
www.cpearson.com
(email on web site)

 

[Gregory A. Beamer]

You still end up with FTP to upload, but the VS FTP client is problematic,
in my experience. I find using a standard FTP to be more satisfying.

The main benefit of pre-publishing locally, is you can set up to test the
publish. This is not a mandatory step, by any means, but there are times
when you have issues with a publish to the web and this step allows you to
ensure the problem is solved (at least in theory). I find it even more
important when going from file based to web.

NOTE: If you have problems with a traditional FTP program, then it is your
ISP.

 

[Chip Pearson]

Gregory,

Thanks for the info. I have SmartFTP, so I think I'll use that instead
of the built-in VS FTP.

Cordially,
Chip Pearson
Microsoft MVP
Excel Product Group
Pearson Software Consulting, LLC
www.cpearson.com
(email on web site)

 

[delacombo]

What I do

Using VS to publish to remote server is verrrrrrrrry slow and useless in my opinion. Which is a shame since it would make sense to publish directly from VS. So, here's an example of what I do that has worked great.

1) Publish locally
2) Use Powertoy's SyncToy to "Echo" to a "Scrubbed" folder.
3) Upload to remote server using favorite FTP client (i.e., FileZilla)

SyncToy is very handy in the sense that after an initial Sync of your website(s) committed files, you then use it before every live publish to remote server, and it will not only let you see just the changed files, but updating the live site is quicker because you only have to upload the files that have changed. Works like a charm.

This is of course outside of using a Source Control system, such as Subversion which would do this to the Subversion server system instead.