计算机专业aspnet外文翻译-jsp程序(编辑修改稿)

计算机专业aspnet外文翻译-jsp程序(编辑修改稿)内容摘要：

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 constraints imposed when performing the deployment. With Web Deployment Projects, the separation between development and deployment is now plete, and your decision about how to build your applications will no longer impact your deployment choices. Merging Assemblies Much of what Web Deployment Projects provide is just a repackaging of existing utilities exposed via MSBuild tasks and a new interface, but there are also a couple of pletely new features included. The most intriguing is the ability to merge assemblies. When you install Web Deployment Projects, you will find an executable called in the installation directory. This executable is capable of taking the multiassembly output of a prepiled site and merging the assemblies into one. This is the utility that is incorporated into your build script if you select the merge option in a Web Deployment Project. As an example of what is possible with this utility, consider the output of a prepiled Web site, run without the updatable switch, shown in Figure 5. The source application for this output contained two subdirectories, a toplevel file, a class defined in App_Code, and a user control. The end result of the pilation is five different assemblies and a collection of .piled files. If you run the utility on this directory with the o switch to request a single assembly output, shown at the bottom of Figure 5, the result is a much more manageable single assembly named whatever you specify. Although the utility and the corresponding MSBuild task that ship with Web Deployment Projects are new, the underlying technology for merging assemblies has actually been around since the Microsoft174。 .NET Framework in the form of a utility made available from Microsoft Research called ILMerge, the latest version of which is available for download from ~mbart/. This utility is directly incorporated into and does all the heavy lifting involved with merging assemblies. If you think about it, the merging of assemblies is a rather plicated task. You need to take into consideration signing, versioning, and other assemblylevel attributes, embedded resources, and XML documentation, as well as manage the details of clashing type names, and so on. The ILMerge utility manages all of these details for you, with switches to control various decisions about the process. It also gives you the ability to transform .exe assemblies into .dll assemblies for packaging purposes. As an example, suppose you have three assemblies: , , and which you would like to merge into a single library assembly. As long as there were no conflicts in typenames, the following mand line would generate a new library, with all of the types defined in , , and : /t:library /ndebug /out: Pluggable Configuration Files The other pletely new feature that es with Web Deployment Projects is the ability to create pluggable configuration files. It is a mon problem when deploying Web applications to find a way to manage the differences in your configuration files between development and deployment. For example, you may have a local test database to run your site, have another database used by a staging server, and yet another used by the live server. If you are storing your connection strings in (typically in the connectionStrings section), then you need some way of modifying those strings when the application is pushed out to a staging server or to a production machine. Web Deployment Projects offer a clean solution to this problem with a new MSBuild task called ReplaceConfigSections. This task allows you to specify independent files that store the contents of a particular configuration section independently based on solution configurations. For example, you might create a file to store the debug version of our connectionStrings configuration section that looked like this: connectionStrings add connectionString=server=localhost。 database=sales。 trusted_connection=yes name=sales_dsn/ /connectionStrings Similarly, you would then create separate files for each of the solution configurations defined (release, stage, and so on) and populate them with the desired connection strings for their respective deployment environments. For the release configuration, you might name the file and populate it as follows: connectionStrings add connectionString=server=livedbserver。 database=sales。 trusted_connection=yes name=sales_dsn/ /connectionStrings Next, you would configure the MSBuild script added by Web Deployment Projects to describe which configuration sections in the main file should be replaced, and the source files that will supply the content for the replacement. You could modify the scrip。