Best approach for deploying asp.net website_问答_开发者

Just wondering what is the best option for deploying an ASP.Net Website.At the moment I just place the code in a folder on server and create a virtual directory on IIS referring to this folder. Then I open the website in VS2008 on the server and build it.Though it works fine for me,I am not sure if I am开发者_开发知识库 following the best approach for deployment or not.

Thanks.

There's a wealth of opinion on this across the internet and it is all opinion. To an extent it's down to you and your team (if you have one), if your approach is working for you then I don't see any huge reason to change but I would suggest that you at least have a staging site where you can deploy the code for user testing before it's deployed to production.

That said, running VS on the server isn't great (and means you need another VS license so could be a waste) and as VS includes a Publish option anyway, it's rather redundant. I use publish for the smaller sites and it works a fine.

Publish from inside VS is a pretty powerful tool as it lets you do web.config substitution. Check out the Hanselman talk Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong

You have several options which are preferable to running Studio on the server.

Depending on your team size, you could:

publish right from VS
continuous integration, check out Cruise Control for info on that
combination of CI and file synch (i.e. CI to test server then xcopy to production)

I'd advocate for CI since you tend to find issues faster that way, but it assumes you are using good version tracking and testing practices. Copying files can have unintended consequences like missed files, outdated files begin retained, etc.

When you deploy that way, anyone who gains access to the web server (which may be beyond your control if it is hosted) can view and possibly even alter your .aspx pages.

One alternative, which you can use from within Visual Studio, is to compile everything into a binary. You do that by choosing menu Build > Publish > uncheck the checkbox "Allow this precompiled site to be updatable." The downside of this, of course, is that even the tiniest change in a page's HTML will require recompiling the code and redeploying it.

It's a clear tradeoff between security and manageability, but precompilation can also aid in performance. Here is one explanation of precompilation alternatives.

You might also consider the suggestions made in Key Configuration Settings When Deploying a Web Application. In a nutshell,

If you are deploying your web application to a machine that you have control over, such as a web server within your company's intranet or a dedicated web server at a web host provider, you can use the element in machine.config to force all applications on the web server to adhere to the recommendations provided above (namely, using a custom error page, disabling output tracing, and not having the auto-compiled code compiled in debug mode). Simply add the following markup to the machine.config file within the <system.web> element:

<deployment retail="true" />

Again, this is a pretty simple change to make.

On a project I work on, we originally built on a dev machine, zipped and copied the contents of the 'bin' directory across. (unzipping, creating a site in IIS etc...)

Later, when we had the time, we went for this approach:

Creating windows installers in VS2008.

This has worked really well, as (literally) anyone is capable of doing the deployment. The real beauty of this, is that you can account for This is just a fancy way of wrapping the process of copying the 'bin' directory across...

Food for thought I hope.

Dave