To deploy a website on production or UAT server, I perform following steps.
1)Build my website in build\release mode.
2)Copy the files manually and paste it on the production server.
I want to apply web.config transformations when website is bulid in release mode. Is it possible?
or is there any other way to change the value of connection string automatically when website is deployed on server.
I am not using webpublish or web packages methods for deployment.
You can use web publish to file system which is exactly as copy paste. You can publish to a folder in your machine and copy to server from there. After you run the publish, the files can be also found in obj\release\Package\PackageTmp
Related
I have an application that is installed at several different client's servers. They each have different web.config files and different virtual folders. At the moment I am compiling, manually copying over, setting up IIS, changing web.config and adding virtual folders for each install and also again when updating.
I simply don't know how to deploy using something like Web Deploy or Deployment Package that will let me create different config files or how to manage virtual folders (I would assume I would simply deploy empty folders and would still have to do this part manually). I can handle setting up IIS and virtual folders from the start but I want each client to be able to download new versions and install them without my input (as some Clients are funny about remote access).
You can setup build configurations for each environment. Typically, you get Debug and Release out of the box. I like to replace those with Development, Staging, and Production configurations, which allows a different web.config per environment.
Of course, when publishing, you still have to make sure you select the correct configuration.
I'm not a fan of Web Deploy and other schemes because web-servers, unlike desktops, all tend to have a unique configuration.
In my case, all of our web applications are deployed with custom-written VBScripts (much more pleasant than Batch files and without needing to relearn PowerShell). VBScript (with its default COM object library) provides a compelling platform for writing deployment scripts. And if you can't stand the syntax you can use JScript using the same tools. Bonus: Visual Studio still provides Windows scripting IntelliSense despite it not being an advertised feature).
My most recent deployment script is simple: it's a VBScript (invoked by VS's Post-build command-line) that uses 7-Zip to pack up the web application's files, then generates an ftp.exe batch file (then runs ftp.exe itself) that uploads the files to the server, it also generates an uploads a file called "Unpack.cmd" which calls 7-Zip to extract the files into the right place. The only manual step is executing Unpack.cmd on the server, but that can be done with Remote PowerShell, for example.
Why do you need to customise your IIS configuration separately from the application? Can't you put everything in your web.config file under <system.webServer>?
I have an ASP.NET application that has two very large folders within the application on the production side: One for images and another for App_Themes. They grow dynamically from user input and customization. There are similar folders in my dev application, which have only some sample data for testing.
I am using web deploy through Visual Studio 2010 to publish my site to the production server. I have changed my .csproj file settings to exclude these two folders from deployment and have also checked the "leave extra files on destination" checkbox. However, the publishing still takes a long time. I think the reason is related to web deploy checking all the files in the images folder and the App_Themes folder on the server.
Is there a solution that would solve the publishing problem? I would like to continue using web deploy because it is really practical compared to other methods of publishing. The server is running IIS 6.
You can publish the way you're doing it, but into a local directory. It should be quick that way. Then set up a robocopy job ( http://en.wikipedia.org/wiki/Robocopy ) to sync the local publish directory with the web server. Robocopy can be fired off via a .bat file (I bet you can even chain it somehow to the completion of the publish) and is very configurable allowing you to specify files or directories to omit.
What are the types of deployment we have in asp.net?
Till now what I am doing?
I use to publish my website in any folder than copy paste the compiled file to the inetpub folder [where my website is configured with the IIS]. I am not sure what kind of deployment this is, is it XCOPY? But I am not using any command line tool.
So you have the following options
xcopy deployment
Compile your asp.net application and copy all the files to your server. You can do this by using FTP or shared directories. (Or anything else to transfer files.)
WebDeploy
You have the possibility to deploy your asp.net webpage directly form your Visual Studio. If you go to "Build" and you choose "Publish Web". To be able to to do this you have to configure your server before. But this works automatically after you have set up everything. It's very handy since your deployment becomes easy to rebuild.
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Web Setup - Installer
Visual Studio provide also the option to build an installer. This works like installing usual software on your windows computer with the installer wizard. (See the link)
http://weblogs.asp.net/scottgu/archive/2007/06/15/tip-trick-creating-packaged-asp-net-setup-programs-with-vs-2005.aspx
Manage multiple server
There is also a way of managing the deployment of multiple servers. It seems to be a bit more complicated but could be interesting for professionals. (Check out on Google Microsoft Web Farm Framework 2.0
To answer your question: yes, what you are using is called xcopy deployment. Even though you do not type xcopy . ... it is still a 'plain copy' and therefore called xcopy deployment.
I know you can copy a Website intact to the server and have it run normally (security and compilation time aside).
What about the projects that are in the solution? [whose dll's are copied to the bin when built]. Is there a way to copy the projects' code files to the server as well?
My goal is to be able to debug [by modifying code in the project if needed] directly on the server without having to install an IDE [or keep building on dev machine and copying over dlls]. I can debug/modify the website files, but not the projects.
EDIT: to clarify, not just debug, but be able to edit.
So long as you upload both the DLLs and the PDBs, you should be able to debug successfully without the raw projects on the server. It can be augmented if you have open the matching project / solutions locally. There really isn't a requirement to upload solution, project, or raw code files to the server to debug effectively, remotely. It should be noted that breakig while debugging will hang the app domain on the target application, and as such, should be done with caution in a multiuser environment.
You do not need the project files in order to debug files.
You should read about remote debugging.
Update:
What you want to do sounds very dangerous in a production environment. If you want to develop, develop locally.
Regardless - project and solution files are organizational tools in visual studio as well as build files for the MSBuild build tool. If you don't have either visual studio or MSBuild installed on the server, there is little point in having the project and solution files on it.
Why do you need to develop on a production machine?
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/