After you’ve developed and tested your application, it’s time to deploy it to a production environment. The deployment process can be automated with tools and scripts, managed and governed by IT departments, or deployed directly by developers through Microsoft Visual Studio. Additionally, many Web developers must release their applications commercially; this means other people need to be able to deploy them in environments that the developer knows nothing about.
There are times, when you might need more control over how your application gets deployed. Check dependencies (such as particular operating system versions or service packs), add registry entries for your application, download and install prerequisites, set security, add dependent dynamic-link libraries (DLLs), and so on.
For all these purposes you will find a number of setup Editors of following types in the View menu of Visual Studio : Launch Conditions Registry User Interface Custom Actions File System File Types
A launch condition is used to check the requirements for your application installation. For example, you can check for specific versions of Windows or verify that specific service packs are present before you allow an install. Launch conditions can provide a useful message to the user if a requirement is missing.
Following are the common launch conditions : File Launch Condition : if you want to verify that a specific DLL is present Registry Launch Condition : search a target computer for a specific registry key or value Windows Installer Launch Condition : to determine if a specific package is installed .NET Framework Launch Condition : checks the runtime version of the .NET Framework on the target computer Internet Information Services Launch Condition : This searches for the presence of the right version of Microsoft Internet Information Services (IIS
To create and manage new launch conditions, you use the Launch Conditions editor in the View menu. There are two main branches of the Launch Conditions editor: • Search Target Machine • Launch Conditions Typically, you must add an item to each of these two nodes. For example, if you want to verify that a specific DLL is present, you must Add File Search under Search Target Machine and store the result of the search in a property. You then Add Launch Condition under Launch Conditions that uses the search condition’s property.
To add a basic search condition, start by right-clicking the Search Target Machine node in the Launch Conditions editor. You will have three search condition types to choose from: File Search This search type allows you to define a search for a file. You set the FileName to the name of the file you are searching for, the Folder to search, and the Property to a variable name you use for tracking the results of the search. Registry Search This search type allows you to specify a registry search. You set the Root property to a place to start looking in the registry, the RegKey to a registry key to search for, and the Value property to a value you hope to be set for the given key. You store the results of your search in the Property property as a variable name that can be used in a related launch condition. Windows Installer Search This search type allows you to search for a registered component. You set the ComponentId to a GUID of the component for which you are searching. You set the Property property to a variable that indicates the results of your search.
Right-click the Launch Conditions folder, and then select Add Launch Condition. With the new launch condition selected, view the Properties window to configure your launch condition. You can set the Condition property to match the Property value of a search condition or specify a different condition. To download software to resolve the missing launch condition, provide a URL in the InstallUrl property. In the Message property, type a message to be displayed to the person installing your Web application if a condition is not met.
To create a grouped launch condition, you right-click the root node, Requirements On Target Machine. Doing so simply creates both a search and a launch condition. However, these items are preconfigured to work together. You simply need to tweak their properties according to your needs.
Although rare, there might still be times when you need to add registry entries during setup. From the View menu, select Registry Editor. To add a registry setting in a nested key, you need to add each nested key to the editor. For example, to add a setting to HKEY_LOCAL_MACHINESOFTWAREMicrosoftASP.NET, you need to add the SOFTWARE, Microsoft, and ASP.NET keys to the HKEY_LOCAL_MACHINE hive in the Registry Settings editor. Right-click the key to which you want to add a setting, select New, and then select String Value, Environment String Value, Binary Value, or DWORD Value. Type the name of the value, and then press Enter.
Administrators responsible for deploying and managing your Web applications can also add custom setup wizard pages. These pages enable you to perform the following types of tasks: Display a license agreement A Web Setup Project provides a dialog box template for requiring the user to accept a license agreement. Modify settings in the Web.config file You can use user input to modify configuration settings without requiring administrators to know how to configure an Extensible Markup Language (XML) file.
Perform custom configuration You can use a custom configuration to prompt the user for information that might be stored in the registry or in another unusual location. Activate or register your application You can prompt the user for a product key or registration information. Prompts can be either required or optional. To add a custom setup wizard page to your Web deployment project, you use the View | User Interface Editor
You add a custom action to your setup project through the View | Custom Actions Editor The Custom Actions editor displays the four setup phases. You can right-click the phase to which you want to add a custom action. You then select Add Custom Action. Doing so launches the Select Item In Project dialog box. From here you can select to add a custom .exe or script file from current project or elsewhere to execute at the appropriate phase of deployment.
Custom actions can run in any of the four phases of setup: Install This phase performs the bulk of the work done during setup Commit This phase finalizes these changes. After the Commit phase, setup cannot be rolled back and the application should be uninstalled with Add or Remove Programs. RollBack The Rollback phase runs only if setup fails or is cancelled. It occurs instead of the Commit phase and removes any new files or settings. Uninstall This phase removes files and settings from the computer when the application is removed with Add or Remove Programs.
There are typically two generated to the target build directory for Web Setup Projects: Setup.exe <Websetupprojectname>.msi Although users are more familiar with using Setup.exe to install an application, the .msi file is smaller, far more versatile, and familiar to most systems administrators. The only disadvantage to deploying the application with the .msi file is that the target Web server must have Windows Installer. Most Web servers already have this component, however.
There are many scenarios in which you simply need to copy changes between two servers. There might be some changes from your development environment up to staging or even from staging to production in some limited scenarios. In these cases, you can use the Copy Web tool to publish changes between source and remote sites. You can also use the tool to synchronize files. This involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited.
To launch the Copy Web tool you typically open the Web site you intend as the source. Then right-click the site in Solution Explorer and choose Copy Web Site. The Copy Web tool displays two panes: Source Web Site and Remote Web Site. To set up a remote Web site, you must create a connection by clicking Connect at the top of the tool. This launches the Open Web Site dialog box, which allows you to find a Web site.
You can copy or synchronize files between the source and the remote Web site in several different ways: Copy individual files in either direction Copy the entire site Right-click the Source Web Site pane, and then select Copy Site To Remote. To copy the Remote Web Site to the source Web site, right-click the Remote Web Site pane, and then select Copy Site To Source. Synchronize individual files Select files in either the source or remote Web site, and then click Synchronize Selected Files. Synchronize the entire site Right-click the Source Web Site pane, and then select Synchronize Site.
To precompile and publish a Web application, follow these steps:1. Open the Web site you wish to precompile and publish.2. Next, you can right-click your Web application in Solution Explorer and select Publish Web Site. Alternatively, you can select the Build menu and then choose Publish Web Site.3. In the Publish Web Site dialog box, specify a location to which to publish.
ASP.NET caching stores frequently accessed data or whole Web pages in memory where they can be retrieved faster than they could be from a file or database. Data that changes infrequently and is accessed by a lot of users is a good candidate for caching. The first access of this data would load it into the cache; subsequent requests would be served from the cache until the cache expires.
There are two different types of caching in ASP. NET: Application caching : This represents a collection that can store any object in memory and automatically remove the object based on memory limitations, time limits, or other dependencies. Page output caching : This is ASP.NET’s ability to store a rendered page, portion of a page, or version of a page in memory to reduce the time required to render the page in future requests.
Application caching (also called application data caching) is the process of storing data (and not pages) in a cache object. The cache object is available as a property of the Page object. It represents a collection class of type System.Web.Caching.Cache. The Page.Cache property actually uses an application- wide cache (and not just a page-specific cache). This means that a single Cache object exists for your entire application; items in the Cache can be shared between user sessions and requests
You work with the Cache object like you would Session or similar objects. You can assign items directly to the cache by giving them a name (key) and assigning them an object (value). Cache["Greeting"] = "Hello, world!"; if (Cache["Greeting"] != null) value = (string)Cache["Greeting"]; else value = "Hello, world!"; You wouldn’t normally cache a static string in your application; you’d more likely cache a file, a database query result, or other data that is shared and expensive to obtain.
The Cache object has both the Add and Insert methods. Both define the same set of parameters and do the same thing behind the scenes. The Add method returns the item added to the cache. The Add method is meant to comply with the collection interface. The Insert method, however, has been the preferred method for adding items to the cache. It has a number of overloads based on the many parameters you can set when adding an item to the cache.
A cache dependency links a cached item to something else such as a file or another item in the cache. ASP.NET monitors the dependency and invalidates the cache if the dependent item changes. Cache.Insert("FileCache", "CacheContents", new System.Web.Caching.CacheDependency( Server.MapPath("SourceFile.xml")));
Many times you want to cache data for a specific amount of time. This allows you to limit the amount of time between cache refresh. To do so, you pass the absoluteExpiration parameter to the Cache.Insert method. Cache.Insert("FileCache", "CacheContents", null, DateTime.Now.Add Minutes(10), Cache.NoSlidingExpiration);
Sliding expiration indicates the amount of time that must elapse between subsequent requests before an item is removed from the cache. This allows most frequently used cached objects to stay in your cache longer You set a sliding expiration by passing a TimeSpan to the slidingExpiration parameter of the Insert method.
After a Web browser retrieves a page, the browser often keeps a copy of the page on the local computer. The next time the user requests the page, the browser simply verifies that the cached version is still valid, and then displays the cached page to the user. This improves the responsiveness of the site by decreasing the time required to load the page. It also reduces the load on the server because the server is not required to render a page.