Web Deployment Project (WDP) is a Project type plug-in Visual Studio. The main purpose is to provide you with the existing ASP. NET Website Project or ASP.. NET Web Application Project (website Application Project) is another way to deploy a website, so that your developed website has more options during website construction, encapsulation, and deployment, it also makes website deployment more convenient and automated. Some may not understand
ASP. NET Website projectAnd
ASP. NET Website application projectFor the difference, we recommend that you refer to the article on the black big Web Site Project vs Web Application Project. If we have an ASP. NET Website project. If you want to pre-compile the Website and deploy it on the official host, we will use the built-in Publish Web Site (Publish Website) function of VS2008 without relying on WDP (as shown in the left figure below ), however, the disadvantage is that a lot of components will be output. In fact, it is a great burden for website deployment. You do not want to cut down all the information for each website deployment and upload it again. In this case, you can use Web Deployment Projects, but unlike Publish Web Site, Publish Web Site directly publishes a website to a directory, however, the Web Deployment Projects must first add an independent WDP project to the solution (the adding method is shown in the figure above), and then pre-set
Component name(Assembly Name) and
Output directory during website construction. Then, you can directly compile the website or open the WDP project's Property setting page to set it. Most of the descriptions of each field on the attribute setting page are easy to understand. For detailed descriptions, you can go to Using Web Deployment Projects with Visual Studio 2005 for query, the description on this page applies to the development environment of VS2008. However, for some Property Pages options, some very practical settings are described as follows:
Configuration Properties-> Output AssembliesThere are four options in the Output Assemblies category. The default option is the first option. It can compile the entire website into a single component, including all pages, user control items, App_Code, App_WebReferences ,.... However, I prefer the third setting. It can compile all the page Code related to the User Interface (UI) into one component. Others include App_Code, App_WebReferences ,... different components will be created in directories, which means that if there is a page program update in the future, you only need to deploy the relevant components to reduce the network transmission time during deployment.
Configuration Properties-> DeploymentSetting in the Deployment category is my favorite part. It allows you to customize many "deployments". I will first describe the purpose of each parameter: Enable Web. config file section replacement you can use your web. config settings, but dynamically replaced with another web during deployment. for example, you can replace the contents of appSettings or connectionStrings. Here, you can set WDP to output the Web under the root directory of the website project during compilation/deployment (Pressing Build is equivalent to the deployment action. whether the section in config is replaced, such as setting, your ASP. NET project must also have the appSettings_Staging.config and SQL2005_Staging.config files. The following is an example of appSettings_Staging.config. A file can only contain one
SectionInformation:
| <? Xml version = "1.0"?> <AppSettings> <add key = "test" value = "TEST123"/> <add key = "test1" value = "TEST123"/> <add key = "test2" value = "TEST123"/> <add key = "test3" value = "TEST123"/> </appSettings> |
Enforce matching section replacements because you can customize the number of parameter parameters of the ettings in the development environment, sometimes you may forget to deploy the web after adding a parameter yourself. this parameter is also added to config. You can select this option to avoid such loss. Use external configuration source file if this option is not checked, the original web. config content will be based on
Enable Web. config file section replacementDirectly replace the content. If this option is selected, the section in the original web. config will be declared as an external load. For example:
| <Maid configSource = "maid"/> |
Remove the App_Data folder from output location. Usually, the App_Data directory is used to store website-related information, such as the SQLExpress database or other files. These materials usually have different materials in different execution environments. For example, there will be materials for testing on the testing machine, and there will be materials for the official version at the formal opportunity, usually, you do not want to overwrite the data during deployment. If this option is selected, the entire App_Data directory is directly removed during compilation/deployment, so that you do not need to manually delete these files when copying these files. Configuration allows you to switch the Configuration mode. The default mode is Debug and Release. You can also customize it, for example, Staging (test environment ). That is to say, the preceding settings can be set to several groups. You only need to switch to different modes (such as) to output deployment files in different execution environments, so that you can copy the files to the target host. You can also use Configuration Manager to define whether to compile a Web Deployment Project in different Configuration modes. For example, you do not need to build a WDP Project (as shown in) in Debug mode ), you can set Release or Staging to compile the project and generate deployment files automatically: In addition to setting the project through the Visual Studio interface, in fact, you can modify the Project file of the Web Deployment Project (*. wdproj), this project file is actually compiled and executed through MSBuild, so this configuration file allows you to customize all the custom actions to be performed during compilation. For example:
- In Staging mode, you can modify *. wdproj to copy the created file directly to the Staging host.
- Before building (BeforeBuild), delete unnecessary files or directories (such as. svn or _ svn Directories) during deployment)
- Compress all *. js files after building (AfterBuild), or load jQuery by Google AJAX Libraries API
MSBuild is also a set of super powerful tools. For Daily building or those who need to develop process automation, you must be familiar with how this tool works. The following are some links:
- MSBuild reference
- MSBuild command column reference
- MSBuild-Wikipedia, the free encyclopedia
- MSBuild Sidekick-GUI editor and debugger for MSBuild scripts (paid commercial software)
- Open Source MSBuild Community Tasks Project (a bunch of shared Tasks function libraries)
- Inside MSBuild-Compile Apps Your Way With Custom Tasks For The Microsoft Build Engine
- WiX tips-use MSBuild and Windows Installer XML (WiX) to automate release jobs
To download Web Deployment Projects, refer to the following URL:
- Visual Studio 2008 Web Deployment Projects-RTW
- Visual Studio 2005 Web Deployment Projects [direct download]
Note: This article is translated from traditional Chinese and used only for personal learning. Reprinted with the original article address. Address: http://blog.miniasp.com/post/2009/01/Visual-Studio-2008-Web-Deployment-Project.aspx
