【導讀】當ASP第一次發(fā)布時，Web編程還比較困難，因為需要IIS來處理ASP頁。和VisualStudio®2021通過引入網站開發(fā)模型使一切工作都變得容易了。此外，您還可以使用內置的DevelopmentServer快速測試。安裝IIS才能進行開發(fā)這一先決條件。無需考慮打包和部署。在準備進行部署時，您有多種可選方案。第二種方案是使用。務器上的一組程序集、靜態(tài)內容和配置文件。在以后實際部署時再作打包和部署決定。和發(fā)布版本之間進行切換等操作。有鑒于此，Microsoft迅速推出了Web應用程序項目。，最初它是作為VisualStudio2021的插件發(fā)布的，現(xiàn)在包含在VisualStudio. WAP還使得增量采用引入的新的分部類代碼隱藏模型變得更。單擊各個文件并選擇“轉換為Web應用程序”），也可以讓它們仍然使用舊模型。多既針對網站項目又針對Web應用程序項目的附加部署選項。顯示了VisualStudio所顯示的此。部署站點的/bin目錄中的二進制程序集一起發(fā)布。通過選中“使用固定命名和單頁程序集”（或在命令行實。中的每個可編譯文件創(chuàng)建單獨的程序集。作出該決定并不像您可能想像的那么容

　　

【正文】 w set of assemblies will be generated, with pletely different names from the ones published earlier. This means that deployment is trickier because you must take care to delete all of the previously published assemblies on the live server before deploying the new assemblies or you39。ll generate redundant class definition errors on the next request. Using the fixednames option will resolve this problem as each file will correspond to a distinctly named assembly that will not cha nge from one pilation to the next. If you have a large site, however, generating a separate assembly for each page, control, and Master Page can easily mean managing the publication of hundreds of assemblies. It is this problem of assembly granularity in deployment that Web Deployment Projects solve in a much more satisfying way, as you will see. You can also introduce assembly signing into the pilation process to create strongnamed, versioned assemblies, suitable for deployment in the Global Assembly Cache 18 (GAC) if needed. You can mark the generated assemblies with the assemblylevel attribute AllowPartiallyTrustedCallers using the aptca option, which would be necessary if you did deploy any assemblies to the GAC and were running at a low or medium level of trust. (Keep in mind that this attribute should only be applied to assemblies that have been shown not to expose any security vulnerabilities, as using it with a vulnerability could expose a luring attack.) One other detail about publishing your site is that if you do elect to use Web Application Projects instead of the Web site model, the Build | Publish dialog box will look quite different, as shown in Figure 2. Web Application Projects assume that you want to publish the application as updatable .as*x files and prepiled source files (the same model it uses in development), so the binaryonly deployment options are not available. This utility is really closer in nature to the Copy Web site utility available with Web sites than it is to the Publish Web Site utility since it involves copying files produced by the standard build process. Technically you are not restricted from using binaryonly (nonupdatable) deployment, even if you are using Web Application Projects. If you think about it, the output of the build of a WAP is a valid Web site, which you can then pass through the utility to generate create a binary deployment. You just can39。t invoke it from the Visual Studio 2021 interface which, fortunately, Web Deployment Projects rectify. So what39。s missing from the existing pilation and deployment options presented so far? Primarily two things: the ability to control the naming of assemblies, especially for deployment purposes, and the ability to consolidate all of the output assemblies into a single assembly for simplified deployment. Web Deployment Projects solve both of these problems. Perhaps even more significantly, however, they also tie up a lot of loose ends in the deployment story that existed with Web site applications and Web Application Projects. At their core, Web Deployment Projects (available for download at ) represent just another type of project you add to your solution. Like all Visual Studio project files, Web deployment projects are MSBuild scripts that can be piled directly in the IDE or run from the mand line. Instead of specifying a collection of source code files to pile, however, Web Deployment Projects contain build mands to pile and package Web sites (or Web Application Projects). This means that they will invoke the utility (among others) to create a deployment of a particular Web application. Web Deployment Projects are shipped as a Visual Studio addin package that includes an easytouse menu item for injecting new projects and a plete set of property pages to control all of the available settings. To add one to an existing application, rightclick on an existing Web site (or Web Application Project) and select the Add Web 19 Deployment Project item as shown in Figure 3. This will add a new .wdproj file containing an MSBuild script to your solution, which will generate a deployment of the application you created it from. Once the Web Deployment Project is part of your solution, you can access the property pages of the project file to control exactly what the project does for you, as shown in Figure 4. The default setting for a new deployment project is to deploy the application in updatable mode, with all the .as*x files intact, and the source files piled into a single assembly deployed in the toplevel /bin directory. These deployment projects work the same regardless of whether the source application is using the Web site model or the Web Application Project model, which means that you can now select either development model without impacting your deployment options. One of the most significant features of Web Deployment Projects is the ability to configure the deployment to be all binary (not updatable) in the form of a single assembly, the name of which you can choose. Using this model of deployment means that you can update your entire site merely by pushing a single assembly to the /bin directory of your live site, and not concern yourself with deleting existing assemblies prior to deploying or dealing with a partially deployed site causing errors. It is still necessary to deploy the .piled files for the endpoint mappings, but these files only change when you add, delete, or move pages in your site. Web Deployment Projects provide flexibility in deployment and let you make packaging and deployment decisions independently of how you actually built your Web applications. This independence between development and deployment was partially achieved in the original release of with the utility, but never fully realized because of the constra