I'm basically wondering what the best way to deploy an Asp.Net Web Site is, mostly from the point of view of security. Right now, I'm trying to publish the website using Visual Studio 2010. Could someone direct me to a good tutorial on how to do this securely? For example, can it be done over an encrypted connection via Visual Studio? Is it necessary to install any software on the server to do this? Should I use a different program to open up an SSL (TLS) connection first, and if so, which program (does it come standard with windows)?
The server is running Windows Server 2008. Development is on Vista.
Many thanks in advance for any direction in this matter!
Andrew
I would publish the site to your local machine and file copy the files across to your test/production environment. As a rule we don't publish sites straight from VS to test or production.
For example you don't want to accidentally push things straight from dev into a live environment do you?
As far as the file transfer security goes you could use SFTP.
Note: First thing is to check with the owner of the server, as they often will provide you an FTP connection and will take care of configuring IIS.
If you want to add security, make a keyfile and sign your assemblies and consider running Dotfuscator on your dlls, the community edition is included in Visual Studio. Here is an earlier question where I've put more info on Dotfuscator.
If you have to do the deployment yourself, here's a few things to consider.
XCopy (easy)
MSI (have to create a setup program, you can do this easily in Visual Studio)
There is no security advantage in deploying using Visual Studio, but you can use Visual Studio to create a small setup program. One thing you want to make sure for security is DO NOT deploy any .cs files. Prepare your files, you should compile in Release mode, make sure debug is not enabled in your config file, keep your bin and it's dll, also the aspx, asmx, ascx, svc, css, js, and config files.
XCopy: Install a small FTP server, or use one your company alreayd has, this will allow you to get your files once you are logged into the target machine. You should be able to get an administrator account for the target machine, just ask the sysadmin of the domain, then log on using remote desktop, got to your ftp site, and download your files. Open IIS on the target machine, create a virtual directory and a pool. Copy your files to the location, configure your connection string to your DB if you use one, then test your website.
MSI: same process as above, except the setup will create the virtual directory and pool for you.
Here is extra info on best practices from the official ASP.Net website.
If you have some control on the server (e.g. to configure IIS7), you might want to look into Microsoft Web Deploy (new product just been released):
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Haven't tried it myself, but looks quite slick and it apparently encrypts the data being copied up, so might suit you.
Related
I don't know if this is possible, but I am trying to open a Visual Studio 2010 solution that is on a remote server from in Visual Studio. The project I am on is using Kentico CMS and we would like to be able to sync changes made to the hosted site (on the server) using TFS and Visual Studio as well as changes made via the Kentico CMS Desk portal. I haven't found anything on the Visual Studio or Kentico dev site or in the documentation. Whether or not this is possible, or if there is a better way of achieving this goal, I would appreciate any insight you could give.
I believe this system would help you accomplish syncing your development environment to a remote server.
http://www.kentico.com/Product/All-Features/Other-Modules/Staging-and-synchronization
You can check out what gets synced on this page:
http://devnet.kentico.com/docs/devguide/index.html
The content staging is good for synchronizing changes made via the user interface.
For synchronizing changes in the file system (e.g. changes in the code files in Visual studio), you can use some third party tools to keep the folders up to date - i.e. Drop box or Google drive (but there are also other tools and utilities).
After talking with a couple developers who were a bit more familiar with Kentico, we eventually found a good solution to our problem. It's not perfect, but it will work for our purposes.
We had the Kentico administrator generate a new license code for Kentico for 'localhost'.
In Visual Studio, we pulled down one of the default Kentico projects from the server.
On the project properties, we set Use Dynamic Ports to false and chose a number to set the ports to.
Once the project was built and running, we could navigate to 'localhost:1501/[ProjectName]/[PageName (CMSDesk, Landing.aspx, etc.)]' to access the CMS Desk portal.
In the CMS Site Manager, navigate to Sites > (click the Edit button for the site) > Domain Aliases > New Domain Alias and set a new domain alias (the website you want to use when viewing the site (for us it was dev.[projectname].com). This allows other developers to log onto and use the pages via the domain alias when the project is on the server. Changes made on the localhost copy must be pushed to the server before they are visible.
Using the local copy, we could work with the web parts and sync changes to TFS. We still have to manually copy the project from our local machine to the server in order to deploy, but we are hoping to set up a build machine that will push the TFS build to the server on a regular basis, which shouldn't be especially difficult.
If we find any better way to achieve this goal, or find any potential problems, I will be sure to update.
The old school way is to copy and paste and the files.. so we don't want that anymore..
So I notice VS2010 has 'Publish'... Should I use file system and just create a shared drive on the VM and publish that way?? Should I FTP and set up FTP on the VM FTP server? Should I use web deploy?? But that seems to be made for commercial web hosting ?
Go with the easiest possible
If it's possible to do a File System deploy, then do it. Don't overcomplicate setting up additional services just to be able to deploy using something more fancy.
After a number of failed deployment attempts (configs overwritten, files missing, out dated etc) to our shared hosting server I thought I might get some insight on processes to make deployment run more smoothly.
We use SQL Compare to move database related stuff over and that seems to work well.
The web site itself is in SVN source control, to deploy we create a tag for the current release and then export the files. We then upload the exported files to the server through ftp manually making sure we are not overriding server specific files.
Is there any (free) tools that can assist in this or do you have a solid process that you generally follow?
For the web stuff, I'd recommend you look at the asp.net web deployment project add-on for Visual Studio. Using the web deployment project, you can take advantage of various degrees of pre-compilation and handle all that messy config file search-replace stuff too. Doesn't work with Web Dev Express though...
For the database end, SQL Compare is a good way to go, so if that is working fine for you stick with it.
Is there a security risk associated with using the option that copies "All project files" when publishing a web application into a production environment? I normally use the option "Only files needed to run this application" which does not copy the source code to the server.
I am the only person with access to the production server. There is also no issue with cluttering the production server as there isn't much on it. In fact I don't mind having all the source files be kept on the server together with the binaries.
Is there any security issue with this?
If no one can get access to the production server then there is no security risk with this option. However this is a pretty big if! I can’t see any real benefit from using the All project files or All files in the source project folder options – these don’t even allow you to update the web application in place on the production server which might be useful in some situations. I would stick to the Only files needed to run this application option just to be save.
We currently deploy web applications by creating a database and running SQL scripts through query analyzer. Then we copy the output from "publish website" and set up that website in IIS.
We have seen websetup in visual studio, but that part seems to be thinly documented. For example, we are not clear how to ask the user for IP and password of SQL server. We also tend to get websites deployed this way coming up under folders like http://example.com/project, instead of just http://example.com.
Then there are issues with AJAX.Net not being installed or some or the other patch not applied.
So far, we have physical access to the servers. Pretty soon though we are going to be shipping CDROMs. What is the practical tradeoff between manual intervention and automation?
Avoid Visual Studio deployment, and automate as much as possible. Web Deployment Projects and NAnt can be your friends!
Briefly, our deployment setup:
We use RedGate SQL to script differences between dev and live database.
An NAnt build file which calls MSBUILD to build the web deployment project (.wdproj), zips up the resulting compiled web app (along with the SQL change script) and then uploads the zip file to the server.
On the server side, there is another NAnt build file which takes the application offline, backs up the database, backs up the website. runs the SQL change script, unzips the new version and brings the app online.
Step 3 is usually run "manually" (one double-click), but sometimes scheduled for late at night. You could do exactly the same from a CDROM, or even write a pretty little Windows Forms app as a wrapper.
Quite happy to give details of the NAnt script if you're interested.
Have you tried using Web Deployment project? There is support for VS 2008 also now..
I deploy mostly ASP.NET apps to Linux servers. Here is my standard workflow:
I use a source code repository (like Subversion)
On the server, I have a bash script that does the following:
Checks out the latest code
Does a build (creates the DLLs)
Filters the files down to the essentials (removes code files for example)
Backs up the database
Deploys the files to the web server in a directory named with the current date
Updates the database if a new schema is included in the deployment
Makes the new installation the default one so it will be served with the next hit
Checkout is done with the command-line version of Subversion and building is done with xbuild (msbuild work-alike from the Mono project). Most of the magic is done in ReleaseIt.
On my dev server I essentially have continuous integration but on the production side I actually SSH into the server and initiate the deployment manually by running the script. My script is cleverly called 'deploy' so that is what I type at the bash prompt. I am very creative. Not.
In production, I have to type 'deploy' twice: once to check-out, build, and deploy to a dated directory and once to make that directory the default instance. Since the directories are dated, I can revert to any previous deployment simply by typing 'deploy' from within the relevant directory.
Initial deployment takes a couple of minutes and reversion to a prior version takes a few seconds.
It has been a nice solution for me and relies only on the three command-line utilities (svn, xbuild, and releaseit), the DB client, SSH, and Bash.
I really need to update the copy of ReleaseIt on CodePlex sometime:
http://releaseit.codeplex.com/