How Do I: Deploy a Web Site Using the Copy Web Site Tool

Is there anyway we can exclude files?

say we have different configuration btw dev, qa and production?

how do people usualy handle this?

thanks~

I was wondering if you could also give us an idea of how to deploy to say a web farm or garden and how to troubleshoot the application when it is on a live server. Sometimes, your site works fine on your local machine but as soon as you move it to a live server, it breaks and you are left wondering what happened even when in your Visual studio build, you see no exceptions and no errors or warnings associated with the same web application.

This needs to be removed and replaced by a video on how to use a Web Deployment project.  Or, at the very least, it should be re-recorded so we never see .vb files on the remote server.  I don't know what imaginary world this video is from, but in the real world, we never push .cs and .vb files to servers.  If you want to make a video on how to sync a web site between two developer machines with the Copy Web Site tool, that's fine, but in my opinion, it's named "Copy Web Site" not "Deploy Web Site" because it's not a valid deployment tool.

Perhaps Im missing something, but isnt using the publish website a better option?  It pre-compiles it, you have the option to leave aspx pages "updatable", and it keeps you from putting code-behinds on your servers, which ultimately arent necessary.

In the real world, I have seen cases where the .cs and the .vb files have been pushed on to the server in fortune 500 companies. I, for one thought that we ought to compiled but since I was just the one with that view or idea that it ought to be so, the idea was never recieved as being valid. If both work well, I would like to know how come most all interviewers and examiners penalize you when you answer that the .cs and .vb files can also be loaded on the server along with the .aspx pages??

I do prefer the Copy Website method for site updates but yes, I would also love to see an option like Dreamweaver has for un-selecting files before Copy to remote on Site synchronization. Very important feature in regard to privacy.

I find the copy website tool useless. If you want to see what it should look like, try soemthing like Allway Sync (allwaysync.com). It checks for differences between source and target folders, has very good exclude/include features, and essentially lets you define to the folder or file level, which files are to be compared for differences. You can exclude folders/files on the fly, and build a valid list in realtime. Once you want to sync, it provides you with a list of new and updated files, after which you can just push them over to the server.

MS should take a clue from this product on how to properly build a copy web site tool.

If you are uploading using FTP as opposed to a network transfer, just map a drive using NetDrive and you're all set.

I know that there are many other such tools, but this one seems to do quite well and handles my needs, so I never looked further.

Nice and useful !

I just finished watching the video.  My impression is that this tool was not designed for deployment of ASP.Net applications but was designed for copying/synchronizing otherwise normal web sites.  As others have already posted, I don't like the ideal of posting code-behind files to the production server, but the tool does work for syncing up files on two different systems.

The video is fine as far as it goes, but I would really like to see a step-by-step of how to copy to a *remote* IIS, on a server in your domain, for example.

As far as I can make out, this is only possible by mapping a network drive and then copying to there, then using IIS on the remote machine to create the virtual directory etc...

easy to follow up ! could be better to work forward and give more example,

I believe that the "Copy Web Site" tool is doing exactly what it says but it is more on synching your "Source Code" rather than "Deploying the Web Site". And I agree that .cs and .vb files should not supppose to reach production/public Server as it may compromise your entire Web Site.