WHAT’S IN THIS CHAPTER?
WROX.COM CODE DOWNLOADS FOR THIS CHAPTER
Please note that this chapter because of its focus on packaging and deploying ASP.NET applications has no corresponding code download.
Packaging and deploying ASP.NET applications are topics that usually receive little attention. This chapter takes a more in-depth look at how you can package and deploy your ASP.NET applications after they are built. After you have developed your ASP.NET application on a development computer, you will need to deploy the finished product to a quality assurance or staging server, and eventually onto a production server.
An important reason to consider the proper packaging and deploying of your ASP.NET applications is that many applications are built as saleable products, starter kits, or solutions. In this case, you may have to allow complete strangers to download and install these products in their own environments that you have absolutely no control over. If this is the case, giving the consumer a single installer file that ensures proper installation of the application in any environment is ideal.
Nevertheless, regardless of whether you will distribute your web application outside your company you still need a way to deploy it to another server where it can be tested before production deployment. You should never assume that it would be perfect just because it worked on your computer. Most of the time you just develop using IIS Express in Visual Studio, so you will need a full test using IIS before you assume all is well. Even if you do test with IIS on your computer, deployment-related factors still need to be ironed out and fully tested before the application goes to production.
So what are you actually deploying? ASP.NET contains a lot of pieces that are all possible parts of the overall application and need to be deployed with the application for it to run properly. The following list details some of the items that are potentially part of your ASP.NET application and need deployment consideration when you are moving your application:
Before deploying your ASP.NET web applications, you should take some basic steps to ensure that your application is ready for deployment. These steps are often forgotten and are mentioned here to remind you of how you can ensure that your deployed application performs at its best.
Before you begin, turn off debugging in the web.config file. You do this by setting the debug attribute in the <compilation> element to False, as shown in Listing 33-1.
LISTING 33-1: Setting debug to False before application deployment
<configuration>
<system.web>
<compilation debug="false" targetFramework="4.5" />
</system.web>
</configuration>By default, most developers set the debug attribute to True when developing their applications. Doing this inserts debug symbols into the compiled ASP.NET pages. These symbols degrade the performance of any application. After the application is built and ready to be deployed, keeping these debug symbols in place is unnecessary.
For those who have been coding ASP.NET for some time now, it is important to note that the Debug option in the drop-down list in the Visual Studio menu does not accomplish much in changing the configuration file or anything similar (shown in Figure 33-1). In the ASP.NET 1.0 and 1.1 days, Visual Studio .NET (as it was called at that time) actually controlled the compilation of the ASP.NET project to a DLL. Now, and ever since ASP.NET 2.0, it is actually ASP.NET itself that controls the compilation process at run time.
Therefore, although the drop-down with the Debug designation is present, it really has no meaning in the context of building an ASP.NET project. You completely control the compilation designation through what is set in the web.config file, as shown earlier in Listing 33-1.
You will find that you can provide Web.Debug.config and Web.Release.config files in your application as well. Using Web.Debug.config allows you to put settings in the configuration file that will be utilized when you do a deployment or run of the application while in the debug mode. You can use the same approach with the Web.Release.config file when publishing the application in the Release mode. This approach with the configuration files allows you to use different database connection strings, change the authentication mode, and more. You will find using these varied configuration files beneficial if you are working with more than one environment (for example, testing, staging, and production).
Remember that deployment is the last step in a process. The first is setting up the program — packaging the program into a component that is best suited for the deployment that follows. You can actually deploy a web application in a number of ways. You can use the XCopy capability that simply wows audiences when demonstrated (because of its simplicity). A second method is to use Visual Studio 2012’s capability to copy a website from one location to another using the Copy Web Site feature, as well as an alternative method that uses Visual Studio to deploy a precompiled web application. The final method uses Visual Studio publish profiles to publish an application on a server. After reviewing each of the available methods, you can decide which is best for what you are trying to achieve.
Applications in .NET compile down to assemblies, and these assemblies contain code that is executed by the Common Language Runtime (CLR). One great thing about assemblies is that they are self-describing. All the details about the assembly are stored within the assembly itself. Because a .NET assembly stores this information within itself, XCopy deployment is possible and no registry settings are needed. Installing an assembly is as simple as copying it to another server and you do not need to stop or start IIS while this is going on.
XCopy is mentioned here because it is the command-line way of basically doing a copy-and-paste of all the files and folders you want to copy. XCopy, however, provides a bit more functionality than just a copy-and-paste, as you will see shortly. XCopy enables you to move files, directories, and even entire drives from one point to another.
The default syntax of the XCopy command is as follows:
xcopy [source] [destination] [/w] [/p] [/c] [/v] [/q] [/f] [/l] [/g]
[/d[:mm-dd-yyyy]] [/u] [/i] [/s [/e]] [/t] [/k] [/r] [/h] [{/a|/m}] [/n] [/o]
[/x] [/exclude:file1[+[file2]][+file3]] [{/y|/-y}] [/z]To see an example of using the XCopy feature, suppose you are working from your developer machine (C:\) and want to copy your ASP.NET application to a production server (Y:\). In its simplest form, the following command would do the job:
xcopy c:\Websites\Website1 Y:\Websites\ /f /e /k /hThis command copies the files and folders from the source drive to the destination drive. Figure 33-2 shows an example of this use on the command line.
When you copy files using XCopy, be aware that this method does not allow for the automatic creation of any virtual directories in IIS. When copying a new web application, you also need to create a virtual directory in the destination server and associate this virtual directory with the application you are copying. It is a simple process, but you must take these extra steps to finalize the site copy actions.
You can provide a number of parameters to this XCopy command to get it to behave as you want it to. Table 33-1 details these parameters.
| PARAMETER | DESCRIPTION |
| /w | Displays the message: Press any key to begin copying file(s). It waits for your response to start the copying process. |
| /p | Asks for a confirmation on each file being copied. This is done in a file-by-file manner. |
| /c | Ignores errors that might occur in the copying process. |
| /v | Performs a verification on the files being copied to make sure they are identical to the source files. |
| /q | Suppresses any display of the XCopy messages. |
| /f | Displays the filenames for the source and destination files while the copying process is occurring. |
| /l | Displays a list of the files to be copied to the destination drive. |
| /g | Builds decrypted files for the destination drive. |
| /d | When used as simply /d, the only files copied are those newer than the existing files located in the destination location. Another alternative is to use /d[:mm-dd-yyyy], which copies files that have been modified either on or after the specified date. |
| /u | Copies only source files that already exist in the destination location. |
| /I | If what is being copied is a directory or a file that contains wildcards and the same item does not exist in the destination location, a new directory is created. The XCopy process also copies all the associated files into this directory. |
| /s | Copies all directories and their subdirectories only if they contain files. All empty directories or subdirectories are not copied in the process. |
| /e | Copies all subdirectories regardless of whether these directories contain files. |
| /t | Copies the subdirectories only and not the files they might contain. |
| /k | By default, the XCopy process removes any read-only settings that might be contained in the source files. Using /k ensures that these read-only settings remain in place during the copying process. |
| /r | Copies only the read-only files to the destination location. |
| /h | Specifies that the hidden and system files, which are usually excluded by default, are included. |
| /a | Copies only files that have their archive file attributes set, and leaves the archive file attributes in place at the XCopy destination. |
| /m | Copies only files that have their archive file attributes set, and turns off the archive file attributes. |
| /n | Copies using the NTFS short file and short directory names. |
| /o | Copies the discretionary access control list (DACL) in addition to the files. |
| /x | Copies the audit settings and the system access control list (SACL) in addition to the files. |
| /exclude | Allows you to exclude specific files. The construction used for this is exclude:File1.aspx + File2.aspx + File3.aspx. |
| /y | Suppresses any prompts from the XCopy process that ask whether to overwrite the destination file. |
| /-y | Adds prompts to confirm an overwrite of any existing files in the destination location. |
| /z | Copies files and directories over a network in restartable mode. |
| /? | Displays help for the XCopy command. |
Using XCopy is an easy way to move your applications from one server to another with little work on your part. If you have no problem setting up your own virtual directories, this mode of deployment should work just fine for you.
When the web application is copied (and if placed in a proper virtual directory), it is ready to be called from a browser.
The next option for copying a website is to use a GUI provided by Visual Studio 2012. This Copy Web Site GUI enables you to copy websites from your development server to either the same server or a remote server (as you can when you use the XCopy command). This option is useful if you are using Web Site projects rather than Web Application projects.
You can open this Copy Web Site window in Visual Studio in two ways. The first way is to click in the Copy Web Site icon in the Visual Studio Solution Explorer. The other way to open the Copy Web Site GUI is to choose Website ⇒ Copy Web Site from the Visual Studio menu. Using either method opens the Copy Web Site GUI in the Document window, as illustrated in Figure 33-3.
From this GUI, you can click the Connect To a Remote Server button (next to the Connections textbox and labeled “Connect”). This action opens the Open Web Site window shown in Figure 33-4.
As you can see from this window, you have a couple of options to connect to and copy your web application. These options include the following:
After being connected to a server, you can copy the contents of your web application to it by selecting all or some of the files from the Source Web Site text area. After you select these files in the window, some of the movement arrows become enabled. Clicking the right-pointing arrow copies the selected files to the destination server. In Figure 33-5 you can see that, indeed, the files have been copied to the remote destination.
If you open the same copy window later, after working on the files, you see an arrow next to the files that have been changed in the interim and are, therefore, newer than those on the destination server (see Figure 33-6).
These arrows enable you to select only the files that must be copied again and nothing more. All the copying actions are recorded in a log file. You can view the contents of this log file from the Copy Web Site window by clicking the View Log button at the bottom of the window. This opens the CopyWebSite.log text file. From the copy that you made previously, you can see the transaction that was done. Here is an example log entry:
Copy from 'C:\Websites\Website1' to 'E:\Website1' started at 10/6/2009 7:52:31 AM.
Create folder App_Data in the remote Web site.
Copy file Default.aspx from source to remote Web site.
Copy file Default.aspx.cs from source to remote Web site.
Copy file About.aspx from source to remote Web site.
Copy file About.aspx.cs from source to remote Web site.
Copy file web.config from source to remote Web site.
Copy from 'C:\Websites\Website1' to 'E:\Website1' is finished.
Completed at 10/6/2009 7:52:33 AM.In addition to using Visual Studio to copy a web application from one location to another, using this IDE to deploy a precompiled application is also possible. The process of precompiling a web application is explained in Chapter 3. ASP.NET includes a precompilation process that allows for a process referred to as precompilation for deployment.
What happens in the precompilation for deployment process is that each page in the web application is built and compiled into a single application DLL and some placeholder files. These files can then be deployed together to another server and run from there. The nice thing about this precompilation process is that it can obfuscate your code by placing all page code (as well as the page’s code-behind code) into the DLL, thereby making it more difficult for your code to be stolen or changed if you select this option in the compilation process. This is an ideal situation when you are deploying applications your customers are paying for, or applications that you absolutely do not want changed in any manner after deployment.
Chapter 3 showed you how to use the command-line tool aspnet_compiler.exe to accomplish the task of precompilation. Although this method is great for precompiling your web applications and deploying them to remote servers, you can also use Visual Studio 2012 to accomplish the precompilation and deployment process.
To accomplish this task, open the project you want to deploy and get the application ready for deployment by turning off the debugging capabilities as described earlier in the chapter. Then open the precompilation and deployment window by choosing Build ⇒ Publish Web Site in the Visual Studio menu. The Publish Web window shown in Figure 33-7 appears.
Using the Browse (. . .) button in this window, you can choose any location (either on your local or remote machine) to which you want to deploy the application. As in earlier examples, your options are a file system location, a place in the local IIS, a location accessed using FTP, or a location accessed via FrontPage Server Extensions.
Figure 33-16 later in the chapter shows the Advanced Precompile settings window where you can find other options in this window such as the Allow (see Fig.33-16) Precompiled Site to Be Updateable check box. When this option is selected, the site will be compiled and copied without any changes to the .aspx pages. This means that after the precompilation process, you can still make minor changes such as modifying the markup of the web pages, and the application will work and function as normal. If this check box is not selected, all the code from the pages is stripped out and placed inside one or more DLLs. In this state, the application is not updateable because updating any of the placeholder files from this compilation process is impossible.
Another option in this window is to assign a strong name to the DLL that is created in this process. You can select the appropriate check box and assign a key to use in the signing process. The created DLL from the precompilation will then be a strong assembly — signed with the key of your choice. Strong names guarantee name uniqueness by relying on unique key pairs and also provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built.
When you are ready to deploy, click OK in the window and then the open application is built and published. Published means that the application is deployed to the specified location. Looking at this location, you can see that a bin directory has now been added that contains some precompiled DLLs, which is your web application. This is illustrated in Figure 33-8.
In this state, the code contained in any of the ASP.NET-specific pages is stripped out and placed inside the DLL. The files that you see are actually just placeholders that the DLL needs for reference.
One of the easiest ways to deploy your web application is to use the new built-in publishing features from Visual Studio 2012. Behind the scenes, this capability uses Microsoft’s web deployment tool, also known as Web Deploy, which means that if you want to deploy this tool to your server, this server must have Web Deploy on the machine for the hydration of your application to work.
The package that is created and passed around is an actual physical file — a .zip file. This .zip file contains everything you need to redeploy your web application with all of its settings into the new environment. In addition to the .zip file, it also includes a manifest file and a command file that are used to initiate the installation of the package on the host machine.
The first way in which this application can be deployed is to use the One-Click Publishing capability found in Visual Studio 2012. To do this, right-click on the project within the Visual Studio Solution Explorer and select the Publish option from the provided menu. This option is available for both Web Site projects as well as Web Application projects.. The Publish Web window appears, as shown in Figure 33-9.
Because many developers are continually deploying their web applications to their testing, staging, and production environments, there is a capability to store your deployment options in a profile that you can use again and again. This setting comes from what you have set in the toolbar of Visual Studio 2012 before you select the Publish option.
You can configure the settings shown in Table 33-2 when publishing an application using the Publish wizard.
| SETTING | DESCRIPTION |
| Profile Name | The name of your saved profile. This provides you with the ability to reuse your settings as a default for repeated deployments. |
| Build Configuration | Specifies whether the build compilation will be done in either the Debug or Release mode. This option is not limited to just Debug/Release but works with any build configuration file for the project. |
| Publish Method | The method you want to employ for the deployment. The possible options include Web Deploy Publish, FTP, File System, and FPSE (FrontPage Server Extensions). |
| Service URL | Specifies the location of the Web Deploy on the host server. This URL points to the actual IIS handler that has the Web Deploy capability and will be constructed similar to http://myhostserver:8172/MsDeploy.axd. |
| Site/Application | Specifies the location where your application will be deployed. Here you can specify the site as well as the virtual directory to place the application. An example of this is MyDomain.com/MyApplication. |
| Remove additional files at the destination | If this option is not selected, the One-Click Publishing option will first delete everything on the host server location before applying the files and settings. |
| User Name | The username used for IIS connections. |
| Password | The password used for IIS connections. |
| Save password | Specifies to the Visual Studio publishing feature whether to save the password in the profile. |
| Destination URL | After a successful publish, the destination URL will be opened in the browser. |
| File Publish Options | Specifies which files need to be published or removed at the destination server. |
| Databases | Specifies whether Entity Framework Code First Migrations should run or the database should be published incrementally. |
| Preview | Gives a preview of the files that will get published to the server. |
Besides using the Web Deploy option, you will find that the other options provided through the newPublish Web dialog are even simpler. Figure 33-10 show you the settings for the other three deployment options provided.
In this figure you can see some standard settings for doing deployments using FTP, the file system, or FrontPage Server Extensions (FPSE).
The interesting thing with the Web Deploy capabilities that Visual Studio 2012 has is that instead of just connecting to a remote Web Deploy handler and running your deployment real-time, you can also create a Web Deploy package that can be run at any time.
Visual Studio 2012 includes the ability to create these packages that can then be e-mailed or by other means provided to someone else to run on their systems. To create a web deployment package, you can select the Web Deploy package option from the Publish method. When you select this option and specify a location where the package will be created, the progress of the package creation appears in the Visual Studio status bar. After you’re notified that the Publish succeeded, you can find the entire package in the location that you specified in the publish window.
Within this folder are all the files that constitute the package. Figure 33-11 presents these files.
All of these files constitute the package that you can use in the deployment process.
With this package, passing another team the installation required for your application is easy. A nice example of this usage is if you are deploying to a web farm because multiple deployments need to occur and you want these deployments to all be the same. Running your installations from this single package ensures this similarity.
The other nice advantage to this package system is that it allows you to save your previous deployments, and if you need to go back and verify deployments, you can easily grab hold of a saved package. It also makes rollbacks easy for your deployment process.
The process of deploying an application to a server has undergone lots of changes in Visual Studio 2012. These changes are also available to developers using Visual Studio 2010. The improvements in the deployment area have been focused on making the commonly used operations easier to do while also making it easier to extend them. This section looks at some of these advanced features.
Almost all of the applications use a database. As you incrementally deploy your application, you want to make sure that the production database is not destroyed and is updated with the latest schema changes that happened when you were deploying your application on development machine.
Entity Framework introduced Code First Migrations. Code First Migrations help you to incrementally update the database rather than having to re-create the database each time you deploy your application. You can customize Code First Migrations on how you want to incrementally update the schema and data of your existing database. When you are deploying your application using Visual Studio, you can determine if you want to execute Code First Migrations when the application is deployed. Figure 33-12 shows the Settings tab of the Publish Web window. As you can see in this figure, the “Execute Code First Migrations” option is selected, which means that when the application is deployed on the server, the Code First Migrations will be executed.
When you deploy your application, Visual Studio does not do anything to the database during the deployment process. When the application is accessed for the first time, Code First automatically creates the database or updates the schema as needed. If the application implements a Seed method, the Seed method is executed after the database is created or updated.
If your application is not using Entity Framework Code First, you can still update your database using the dbDacFx Web Deploy Provider. This provider uses the new Data-Tier Applications Framework (Dacpac Framework) for syncing databases. The dbDacFx provider is an improvement over the dbFullSql provider, which was used in Visual Studio 2010. The dbFullSql provider used to do a full sync of the database each time you deployed your application. This meant that if you had made changes to your existing tables, an error would result when the provider did a full sync of the database. dbDacFx is an improvement since this provider will compare the two databases and will calculate the changes that need to be applied to the destination database to make is similar to the source database.
Figure 33-13 shows how you can use dbDacFx provider. This option is shown for SQL Server databases that the application accesses without using the Entity Framework Code First Context class. This option also allows you to specify custom SQL scripts that should be run on the destination database during deployment. Custom SQL scripts are useful when you want to provide some initial seeding data for any tables.
The dbDacFx Web Deploy Provider is recommended over dbFullSql for database deployment. If you want to use the dbFullSql provider, you can configure the database deployment settings in the Package/Publish SQL tab of your project properties.
Two of the most common operations you do when publishing an application is transform some of the properties of web.config and publish a specific web.config based on whether you are publishing to a production or test server. For example, if you are publishing to a production server, you’ll want to turn off the debugging option for your application.
When you create a web application in Visual Studio, you get a web.config file. If you expand the web.config file you will see that it has two subfiles called web.debug.config and web.release.config. Figure 33-14 shows these two files.
When you are deploying your application using Visual Studio you can select which build configuration will be used to build your project, and if there are any associated transforms with that configuration they will be applied. Figure 33-15 shows how you can configure this option in the Settings tab of the Publish Web window. In this figure, I am using Release configuration while publishing my application. This means when publishing, Visual Studio will publish my application in Release mode and disable the debug flag in web.config as shown in Listing 33-1.
One of the most important features of these files is how Visual Studio transforms these files while deploying your application. Transformation is a key feature whereby you can change different settings of your web.config file. Listing 33-2 shows a common web.config where the debug option is turned on and Listing 33-3 shows how you can apply a transform to turn off debugging in a release web.config.
LISTING 33-2: Typical web.config
<system.web>
<compilation debug="true" />
</system.web>LISTING 33-3: web.release.config transform to turn off debugging
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>Transformation actions are specified by using XML attributes that are defined in the XML-Document-Transform namespace, which is mapped to the xdt prefix. The XML-Document-Transform namespace defines two attributes: Locator and Transform.
You can use the transformation feature to perform other transforms such as enabling logging or setting custom errors.
Apart from supporting most of the common operations while deploying, the Publish Web window has advanced settings that enable you to perform more advanced actions.
The Publish Web window only scratches the surface of most of the common operations of deployment. There may be cases where you want to configure advanced operations that aren’t covered in the UI. Publish profile files are named <profilename>.pubxml and are located in the PublishProfiles folder inside your application. For website projects these files are located in App_Data folder and are named as <profilename>.pubxml. Each pubxml file contains settings that apply to one publish profile, so you can store multiple publish profile settings files here, each of which can contain information about different publishing targets for your application. Listing 33-4 shows a sample of a publish profile settings file.
LISTING 33-4: Sample publish profile settings file
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<IncludeSetACLProviderOnDestination>False</IncludeSetACLProviderOnDestination>
<WebPublishMethod>Package</WebPublishMethod>
<LaunchASiteUrlAfterPublish>True</LaunchASiteUrlAfterPublish>
<SiteUrlToLaunchAfterPublish />
<MSDeployServiceURL />
<DeployIisAppPath />
<RemoteSitePhysicalPath />
<AllowUntrustedCertificate>False</AllowUntrustedCertificate>
<SkipExtraFilesOnServer>True</SkipExtraFilesOnServer>
<DeployAsIisApp>True</DeployAsIisApp>
<MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
<UserName />
<SavePWD>True</SavePWD>
<PublishDatabaseSettings>
<!— this section omitted to keep the example short -->
</PublishDatabaseSettings>
</PropertyGroup>
</Project>The publish profile settings files are MSBuild files, and you can edit this file to configure some options. For example, if you control the ACLs on the server and want to disable the default ACL behavior on deployment, you can remove the IncludeSetACLProviderOnDestination element. Visual Studio will not set the default ACLs (which are read-only on the application root and write permissions on the App_Data folder).
If you are precompiling your web application, you configure the advanced settings in the precompilation window. You can launch this window by expanding the File Publish Options in the Settings tab of the Publish Web window. Figure 33-16 shows the Advanced Precompile Settings window.
Although the Publish Web window has most of the common settings needed for web deployment, there are certain settings that can be configured in the Package/Publish Web tab of the project properties. Figure 33-17 shows the Package/Publish Web tab. You can use this tab to configure IIS settings that should be transferred, such as application pool settings.
As more and more hosting platforms are moving to the Cloud, there have been substantial improvements in making it easier to deploy your web applications to the Cloud. This section shows how easy it is for developers to make an application on their development machines available to users by deploying the application to Windows Azure.
Windows Azure Web Sites is a model in Windows Azure that allows you to quickly and easily deploy sites to a highly-scalable Cloud environment. That environment allows you to start small and scale as traffic grows. This model provides capabilities that can be found in a shared hosting environment, where you start with sharing resources with other websites on the server, and you can gradually scale up to have more instances of your website once you start getting more load on it.
You need to create an account on Windows Azure before you can create any new website. To create an account you can go to the Windows Azure management portal at http://www.windowsazure.com/ and sign up to create an account.
To deploy an application as a Windows Azure Web Site, you have to provision a website in Windows Azure. Figure 33-18 shows how you can create a website using the Quick Create option in the Windows Azure management portal. You have the option to create the website in a geographical location that’s the closest to you. You can also choose the Quick Create with Database option, which will provision a database for your application as well.
Once you have created the website, you can download the publish profile to your development machine. You can select your website from the management portal and select the Dashboard tab. This tab gives you an overview of the usage statistics for your website and all the configuration options available. You can download your publish profile from this section. You can download and save your publish setting file anywhere on your computer. Figure 33-19 shows the “Download Publish Profile” option in the Windows Azure management portal that you can use to download the publish profile. This publish profile contains the connection settings needed to connect to your website and the database that was provisioned.
After you have downloaded this publish profile, you can go to your application and import these settings. Once you launch the Publish Web window, you can import the publish profile settings file that you just downloaded to your machine. Once you import this file, Visual Studio will read this file to get connection values to your website and database in Windows Azure. Once you have imported this file, Visual Studio will store your publish profile settings file as part of your project. This means that your publish profile settings file is added to your project, and you can check this file along with your project into any source control system. This is useful since you do not have to download the publish profile settings file if you copy your project to a different machine and want to republish your application. You can launch the Publish Web window by right-clicking your website. From there you can import the profile (Figure 33-20).
In the publish profile you can look at the Connection tab and can validate the publish profile settings by clicking the Validate Connection button. The program will try to connect to the Azure Web Site that you provisioned and determine whether the connections supplied in the publish profile settings file are valid.
If your application is using a database, you can set the connection string to use when your application is deployed in the Settings tab. If you are using Entity Framework Code First, you can configure whether Code First Migrations should run when the application is deployed to Azure Web Sites.
The last step of deploying the application to Windows Azure is the Preview tab. This tab shows which files will be deployed. You can use this step to check if all the files that you wanted to publish are there. You can also unselect any file which you do not want to be published. Figure 33-23 shows the Preview tab.
Once you click Publish, all the files are copied to the server and the database is updated with the schema that you had in your local database or via Entity Framework Code First Migrations. If the deployment is successful, the default browser is launched with the URL of your website and your application is deployed in the Cloud.
As you can see, you have many possibilities for installing your ASP.NET applications — from the simplest mode of just copying the files to a remote server (sort of a save-and-run mode). Publish profiles make it really easy to publish a website or web application projects to any server, in particular, when you are using Windows Azure.
Just remember that when working on the installation procedures for your web applications, you should be thinking about making the entire process logical and easy for your customers and development team to understand. You do not want to make people’s lives too difficult when they are required to programmatically install items on another machine.
