计算机专业ASPNET外文翻译

Extreme https://www.sodocs.net/doc/275551024.html,

1.1Web Deployment Projects

When ASP was first released, Web programming was more difficult because you needed IIS to serve your ASP pages. Later, https://www.sodocs.net/doc/275551024.html, 2.0 and Visual Studio? 2005 made everything easier by introducing the Web site model of development. Instead of creating a new project inside Visual Studio, the Web site model lets you point to a directory and start writing pages and code. Furthermore, you can quickly test your site with the built-in https://www.sodocs.net/doc/275551024.html, Development Server, which hosts https://www.sodocs.net/doc/275551024.html, in a local process and obviates the need to install IIS to begin developing. The beauty of the Web site model is that you can develop your Web application without thinking about packaging and deployment. Need another class? Add a .cs file to the App_Code directory and start writing. Want to store localizable strings in a resource file? Add a .resx file to the App_GlobalResources directory and type in the strings. Everything just works; you don't have to think about the compilation and deployment aspect at all.

When you are ready to deploy, you have several options. The simplest choice is to copy your files to a live server and let everything be compiled on-demand (as it was in your test environment). The second option is to use the aspnet_compiler.exe utility and precompile the application into a binary release, which leaves you nothing but a collection of assemblies, static content, and configuration files to push to the server. The third option is to again use aspnet_compiler.exe, but to create an updateable binary deployment where your .as*x files remain intact (and modifiable) and all of your code files are compiled into binary assemblies.

This seems to cover every possible scenario, leaving the developer to focus simply on writing the Web application, with packaging and deployment decisions to be made later when the application is actually deployed. There was a fair amount of backlash against this model, however, especially from developers who were used to their Web projects being real projects, specified in real project files, that let you inject pre-and post-build functions, exclude files from the build process, move between debug and release builds with a command-line switch, and so on. In response, Microsoft quickly introduced the Web Application Project or WAP, initially released as an add-in to Visual Studio 2005, and now included in Visual Studio 2005 Service available for download from https://www.sodocs.net/doc/275551024.html,/vstudio/support/vs2005sp1.

WAP provides an alternative to the Web site model that is much closer to the Visual Studio .NET 2005 Web Project model. The new WAP model compiles all of the source code files during the build process and generates a single assembly in the local /bin directory for deployment. WAP also makes it much easier to incrementally adopt the new partial class codebehind model

introduced in https://www.sodocs.net/doc/275551024.html, 2.0 because you can now open a Visual Studio .NET 2003 project and only your .sln and .csproj (or .vbproj) files will be modified during the conversion. You can then convert each file and its codebehind class to the new partial class model independently of any other file in the project (by right-clicking on the file in the Solution Explorer and selecting Convert to Web Application), or just leave them using the old model. This is in contrast to converting a Visual Studio .NET 2003 Web project to the Web site model, which converts all files at once and does not support incremental adoption.

Finally, there is a new project type called Web Deployment Projects (the main topic of this column), which introduces myriad additional deployment options for both Web site projects and Web Application Projects. Web Deployment Projects fill the remaining holes in the deployment options for both Web site apps and Web Application Projects and make it possible to implement practically any deployment scenario in a simple and extensible way. To understand exactly what this new project type adds, let's first review what we had before Web Deployment Projects were available.

When you build an application using the Web site model, you have the option of precompiling the site for deployment. You can access the precompilation utility through the Build | Publish menu in Visual Studio 2005 or directly through the command-line utility aspnet_compiler.exe. Figure 1 shows the interface to this tool exposed by Visual Studio.

The first decision you have to make when using the publish utility is whether you want your .as*x files to be updatable once deployed (use the "Allow this precompiled site to be updatable" option of -u switch in the aspnet_compiler.exe command-line utility). This decision hinges on whether you want to be able to make minor changes to your pages once deployed without having to go through the entire deployment process again. You may, in fact, want to explicitly disallow any modifications to the deployed pages and require that all modifications go through the standard deployment (and hopefully testing) process, in which case publishing the site as not updatable is the proper choice.

When a site is published as not updatable, it is possible to completely remove all .as*x files and publish only binary assemblies (plus configuration files and static content). However, without the physical files in place, it is impossible for https://www.sodocs.net/doc/275551024.html, to tell which classes to use for which endpoint requests. For example, if a request comes into your application for Page1.aspx and you have used non-updatable binary deployment, there very well may not be any Page1.aspx file on disk, and there is nothing in the existing configuration files to indicate which class in the collection of assemblies deployed to the /bin directory should actually be the handler for this request. To remedy this, the compilation process will also generate a collection of .compiled files

that contain endpoint-to-type mapping and file dependency information in a simple XML format, and these files must be published along with the binary assemblies in the /bin directory of the deployed site. As an example, if you did have a page named Page1.aspx in your application, the aspnet_compiler.exe utility would generate a file named https://www.sodocs.net/doc/275551024.html,piled (with the hash code varying) that contained the following XML:

virtualPath="/SampleWebSite/Page1.aspx"

hash="8a8da6c5a" filehash="42c4a74221152888"

flags="110000" assembly="App_Web_aq9bt8mj"

type="ASP.page1_aspx">

The other major decision you have to make when publishing a Web site with this utility is the granularity of the packaging of the generated assemblies. You can either create a separate assembly for each directory in your site or create a separate assembly for each compilable file in your site (.aspx, .ascx, .asax, and so on.) by checking the Use fixed naming and single page assemblies (or -fixednames in the aspnet_compiler.exe command-line utility). This decision is not as obvious as you might think, as each option has its own potential issues. If you elect to not use the -fixednames option, then every time you publish your application a completely new set of assemblies will be generated, with completely 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 you'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 change from one compilation 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 compilation process to create strong-named, versioned assemblies, suitable for deployment in the Global Assembly Cache

(GAC) if needed. You can mark the generated assemblies with the assembly-level attribute AllowPartiallyTrustedCallers using the -aptca option, which would be necessary if you did deploy any assemblies to the GAC and were running https://www.sodocs.net/doc/275551024.html, 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 precompiled source files (the same model it uses in development), so the binary-only 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 binary-only (non-updatable) 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 aspnet_compiler.exe utility to generate create a binary deployment. You just can't invoke it from the Visual Studio 2005 interface which, fortunately, Web Deployment Projects rectify.

So what's missing from the existing compilation 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 https://www.sodocs.net/doc/275551024.html,/aa336619.aspx) 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 compiled directly in the IDE or run from the command line. Instead of specifying a collection of source code files to compile, however, Web Deployment Projects contain build commands to compile and package Web sites (or Web Application Projects). This means that they will invoke the aspnet_compiler.exe utility (among others) to create a deployment of a particular Web application. Web Deployment Projects are shipped as a Visual Studio add-in package that includes an easy-to-use menu item for injecting new projects and a complete set of property pages to control all of the available settings. To add one to an existing application, right-click on an existing Web site (or Web Application Project) and select the Add Web 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 compiled into a single assembly deployed in the top-level /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 .compiled 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 https://www.sodocs.net/doc/275551024.html, 2.0 with the aspnet_compiler.exe 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 complete, 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 completely new features included. The most intriguing is the ability to merge assemblies.

When you install Web Deployment Projects, you will find an executable called aspnet_merge.exe in the installation directory. This executable is capable of taking the multi-assembly output of a precompiled 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 precompiled Web site, run without the updatable switch, shown in Figure 5. The source application for this output contained two subdirectories, a top-level global.asax file, a class

defined in App_Code, and a user control. The end result of the compilation is five different assemblies and a collection of .compiled files. If you run the aspnet_merge.exe 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 aspnet_merge.exe 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 Microsoft? .NET Framework 1.1 in the form of a utility made available from Microsoft Research called ILMerge, the latest version of which is available for download from https://www.sodocs.net/doc/275551024.html,/~mbarnett/ILMerge.aspx. This utility is directly incorporated into aspnet_merge.exe and does all the heavy lifting involved with merging assemblies. If you think about it, the merging of assemblies is a rather complicated task. You need to take into consideration signing, versioning, and other assembly-level 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: a.dll, b.dll, and c.exe which you would like to merge into a single library assembly. As long as there were no conflicts in typenames, the following command line would generate a new library, d.dll with all of the types defined in a.dll, b.dll, and c.exe:

ilmerge.exe /t:library /ndebug /out:d.dll a.dll b.dll c.exe

Pluggable Configuration Files

The other completely new feature that comes with Web Deployment Projects is the ability to create pluggable configuration files. It is a common 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 web.config (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 debugconnectionstrings.config file to store the debug version of our connectionStrings configuration section that looked like this:

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 releaseconnectionstrings.config and populate it as follows:

name="sales_dsn"/>

Next, you would configure the MSBuild script added by Web Deployment Projects to describe which configuration sections in the main web.config file should be replaced, and the source files that will supply the content for the replacement. You could modify the script by hand, but there is a nice interface exposed through the property pages of the build script in Visual Studio that will do it for you, as Figure 6 shows. In this case, you are setting the properties for the debug solution configuration, so check the Enable Web.config file section replacement option and specify the section to be replaced along with the file with the contents to replace it: You would use this same dialog page to set the configuration replacement for the Release solution configuration (and any others we had defined) with the corresponding files.

When you then run the build script, the ReplaceConfigSections task extracts the contents from any associated config files and replaces the contents of the corresponding configuration section, creating a new web.config file that is pushed to the deployment directory. This configuration file replacement feature means that you can maintain configuration differences between deployment environments in a manageable way with text files that can be versioned under source control, and you don't have to resort to referring to that sticky note reminding you to change the connection string when you deploy. It should be emphasized that this feature works with any section of the configuration file, even custom sections, so if you have differences in other configuration sections (for example, appSettings) you can easily specify those differences with this build task as well.

Creating Reusable User Controls

There is an interesting side application of Web deployment projects that solves a problem that has plagued https://www.sodocs.net/doc/275551024.html, developers for years-how to create reusable user controls to share across applications. User controls are fundamentally just composite custom controls whose child controls are laid out in an .ascx file. The ability to use the designer for laying out controls and adding handlers is a huge benefit for most developers since it feels almost identical to building a page, except that the resulting .ascx file can be included as a control in any page. The disadvantage has always been that you need the physical .ascx file in the application's directory to actually use it. Techniques for making .ascx controls shareable across applications are available, but they usually involve chores like creating shared virtual directories between applications or harvesting temporary assemblies generated by https://www.sodocs.net/doc/275551024.html, at request time, and they've never been satisfactory.

The introduction of the aspnet_compiler.exe utility in version 2.0 brought us much closer to a decent solution. With the compiler, you can create a Web site consisting of only user controls and publish the site in non-updateable mode using the compiler to generate reusable assemblies. Once you have the resulting assembly (or assemblies), you can then deploy to any Web application and reference the user control just as you would a custom control (not by using the src attribute as you would for .ascx files). The only disadvantage to this technique is that you either have to accept the randomly named assembly produced by the compilation process or select the fixednames option in the compiler to generate a fixed named assembly for each Master Page in the site (not a single assembly for the entire collection).

Web Deployment Projects provide the final step to create truly reusable user control assemblies. You can take the same Web site consisting exclusively of user controls and add a Web Deployment Project to create a single output assembly with the name of your choice. It's even straightforward to create a signed assembly to deploy to the GAC for sharing controls across multiple applications without redeploying the assembly in each /bin directory.

Conclusion

The release of Web Deployment Projects completes the set of tools for deploying https://www.sodocs.net/doc/275551024.html, applications in a very satisfying way. It is now possible to deploy your applications in any manner ranging from all source to all binary, with complete control over the generation, packaging, and naming of the binary assemblies. In addition, Web Deployment Projects provide a solution for replacing sections of your configuration files based on your target build, and they solve the problem of distributing reusable user controls. Anyone who is building and deploying https://www.sodocs.net/doc/275551024.html, applications will undoubtedly find some aspect of Web Deployment Projects compelling enough to begin using them today.

2.1 Client-Side Web Service Calls with AJAX Extensions

Since its inception, https://www.sodocs.net/doc/275551024.html, has fundamentally been a server-side technology. There were certainly places where https://www.sodocs.net/doc/275551024.html, would generate client-side JavaScript, most notably in the validation controls and more recently with the Web Part infrastructure, but it was rarely more than a simple translation of server-side properties into client-side behavior-you as the developer didn't have to think about interacting with the client until you received the next POST request. Developers needing to build more interactive pages with client-side JavaScript and DHTML were left to do it on their own, with some help from the https://www.sodocs.net/doc/275551024.html, 2.0 script callbacks feature. This has changed completely in the last year.

At the Microsoft Professional Developer's Conference in September 2005, Microsoft unveiled a new add-on to https://www.sodocs.net/doc/275551024.html,, code-named "Atlas," which was focused entirely on leveraging client-side JavaScript, DHTML, and the XMLHttpRequest object. The goal was to aid developers in creating more interactive AJAX-enabled Web applications. This framework, which has since been renamed with the official titles of Microsoft? AJAX Library and the https://www.sodocs.net/doc/275551024.html, 2.0 AJAX Extensions, provides a number of compelling features ranging from client-side data binding to DHTML animations and behaviors to sophisticated interception of client POST backs using an UpdatePanel. Underlying many of these features is the ability to retrieve data from the server asynchronously in a form that is easy to parse and interact with from client-side JavaScript calls. The topic for this month's column is this new and incredibly useful ability to call server-side Web services from client-side JavaScript in an https://www.sodocs.net/doc/275551024.html, 2.0 AJAX Extensions-enabled page.

Calling Web Services with AJAX

If you have ever consumed a Web service in the Microsoft .NET Framework, either by creating a proxy using the wsel.exe utility or by using the Add Web Reference feature of Visual Studio?, you are accustomed to working with .NET types to call Web services. In fact, invoking a Web service method through a .NET proxy is exactly like calling methods on any other class. The proxy takes care of preparing the XML based on the parameters you pass, and it carefully translates the XML response it receives into the .NET type specified by the proxy method. The ease with which developers can use the .NET Framework to consume Web service endpoints is incredibly enabling, and is one of the pillars that make service-oriented applications feasible today.

The https://www.sodocs.net/doc/275551024.html, 2.0 AJAX Extensions enable this exact same experience of seamless proxy generation for Web services for client-side JavaScript that will run in the browser. You can author an .asmx file hosted on your server and make calls to methods on that service through a client-side JavaScript class. For example, Figure 1 shows a simple .asmx service that implements a faux stock quote retrieval (with random data).

In addition to the standard .asmx Web service attributes, this service is adorned with the ScriptService attribute that makes it available to JavaScript clients as well. If this .asmx file is deployed in an https://www.sodocs.net/doc/275551024.html, AJAX-Enabled Web application, you can invoke methods of the service from JavaScript by adding a ServiceReference to the ScriptManager control in your .aspx file (this control is added automatically to your default.aspx page when you create a Web site in Visual Studio using the https://www.sodocs.net/doc/275551024.html, AJAX-enabled Web site template):

Now from any client-side JavaScript routine, you can use the MsdnMagazine.StockQuoteService class to call any methods on the service. Because the underlying mechanism for invocation is intrinsically asynchronous, there are no synchronous methods available. Instead, each proxy method takes one extra parameter (beyond the standard input parameters)- a reference to another client-side JavaScript function that will be called asynchronously when the method completes. The example page shown in Figure 2 uses client-side JavaScript to print the result of calling the stock quote Web service to a label (span) on the page.

If something goes wrong with a client-side Web service call, you definitely want to let the client know, so it's usually wise to pass in another method that can be invoked if an error, abort, or timeout occurs. For example, you might change the OnLookup method shown previously as follows, and add an additional OnError method to display any problems:

function OnLookup()

{

var stb = document.getElementById("_symbolTextBox");

MsdnMagazine.StockQuoteService.GetStockQuote(

stb.value, OnLookupComplete, OnError);

}

function OnError(result)

{

alert("Error: " + result.get_message());

}

This way if the Web service call fails, you will notify the client with an alert box. You can also include a userContext parameter with any Web service calls made from the client, which is an arbitrary string passed in as the last parameter to the Web method, and it will be propagated to both the success and failure methods as an additional parameter. In this case, it might make sense to pass the actual symbol of the stock requested as the userContext so you can display it in the OnLookupComplete method:

function OnLookup()

{

var stb = document.getElementById("_symbolTextBox");

MsdnMagazine.StockQuoteService.GetStockQuote(

stb.value, OnLookupComplete, OnError, stb.value);

}

function OnLookupComplete(result, userContext)

{

// userContext contains symbol passed into method

var res = document.getElementById("_resultLabel");

res.innerHTML = userContext + " : " + result + "";

}

If you find that you're making many different calls to a Web service, and that you re-use the same error and/or complete methods for each call, you can also set the default error and succeeded callback method globally. This avoids having to specify the pair of callback methods each time you make a call (although you can choose to override the globally defined methods on a per-method basis). Here is a sample of the OnLookup method that sets the default succeeded and failed callback methods globally instead of on a per-call basis.

// Set default callbacks for stock quote service

MsdnMagazine.StockQuoteService.set_defaultSucceededCallback(

OnLookupComplete);

MsdnMagazine.StockQuoteService.set_defaultFailedCallback(

OnError);

function OnLookup()

{

MsdnMagazine.StockQuoteService.GetStockQuote(stb.value);

}

Another interesting alternative to building a complete .asmx file for your Web service methods is to embed the Web service methods directly in the page class. If it doesn't make sense to build a complete Web service endpoint for the methods you want to call, you can expose a Web method from your page that is callable from client-side JavaScript by adding a server-side method to your page (either directly in the page or in the codebehind) and annotating it with the WebMethod attribute. You will then be able to invoke it via the client-side object PageMethods. The example in Figure 3 shows the stock quote service sample rewritten to be entirely contained in a single page instead of split into a separate Web service.

Bear in mind that these client-side proxies can only be generated from https://www.sodocs.net/doc/275551024.html, .asmx endpoints, Windows Communication Foundation .svc endpoints, or WebMethods embedded directly in a page, and are not a general mechanism for calling arbitrary Web services. In fact, there is a general restriction on the underlying XmlHTTPRequest object that requests be restricted to the same domain from which the page was loaded (for security reasons), so this technique could not be used to call arbitrary Web services regardless of whether the client-side proxies supported it. If you do find the need to call external Web services, your best bet is to set up a bridge .asmx endpoint in your own application that calls into a .NET proxy class (generated with wsdl.exe or Add Web Reference in Visual Studio) for the external Web service.

How It Works

It might seem surprising at first that you can take a standard .asmx Web service and access it from client-side JavaScript within a browser with almost no changes. The secret lies in the registration of a new .asmx HTTP handler, added to the configuration file of every https://www.sodocs.net/doc/275551024.html, AJAX-enabled Web site:

type="Microsoft.Web.Services.ScriptHandlerFactory"

validate="false"/>

This newly registered handler will invoke the standard Web service handler (System.Web.Services.Protocols.WebServiceHandlerFactory) if it is a standard Web service request made to an .asmx endpoint. If, however, the request has a trailing /js in the URL or contains a query string with an mn= variable (such as ?mn=GetStockQuote), the handler will either return a chunk of JavaScript that creates a client-side proxy for the Web service (the /js option), or it will invoke the corresponding method defined in the WebService-derived class and

package up the response in a JavaScript Object Notation (JSON)-encoded string (the ?mn= option).

When a page includes a client-side reference to an .asmx service (via the ServiceReference element within the ScriptManager control), it injects a script element that references the .asmx file with a trailing /js, creating a proxy in the client. For example, the stock quote page I built earlier rendered with the following script element in it:

This is, of course, in addition to the script references added for the Microsoft AJAX Libraries, which include the client-side features needed to interact with this proxy. If you try navigating to this endpoint yourself, you will see the following JavaScript (elided): Type.registerNamespace('MsdnMagazine');

MsdnMagazine.StockQuoteService=function() {

this._timeout = 0;

this._userContext = null;

this._succeeded = null;

this._failed = null;

}

MsdnMagazine.StockQuoteService.prototype={

GetStockQuote:https://www.sodocs.net/doc/275551024.html,._WebMethod._createProxyMethod(this,

"GetStockQuote",

"MsdnMagazine.StockQuoteService.GetStockQuote",

"symbol"), ...

}

This JavaScript is using features of the Microsoft AJAX Libraries (like namespaces and the WebMethod class) that are included with every page that includes a ScriptManager control. The proxy method created by this JavaScript is initialized to invoke the .asmx endpoint with the query string ?mn=GetStockQuote in this case, so that whenever you call MsdnMagazine.StockQuoteService.GetStockQuote from the client, it turns into an asynchronous Web request for the same .asmx endpoint. This combination of client-side proxy generation and server-side support for JavaScript-initiated Web service calls means you can include client-side calls to your .asmx Web services in an intuitive way.

Serialization

The default serialization of AJAX-based Web services is JSON. If you look at a trace of the page shown in the last section in action, the bodies of the Web service request and response look like this:

Request: {"symbol":"ABC"}

Response: 51

This is definitely not the standard XML format you are probably accustomed to seeing when calling your .asmx Web services. Since .asmx endpoints were built to serialize into XML, one of the major additions of the https://www.sodocs.net/doc/275551024.html, 2.0 AJAX Extensions is a JSON serializer. There are actually two of them-one implemented in JavaScript for use on the client, and one implemented in .NET for use on the server, specifically when an AJAX client invokes an .asmx endpoint. The server-side serializer is available through the Microsoft.Web.Script.Serialization.JavaScriptSerializer class and the client-side serializer is available through Sys.Serialization.JavaScriptSerializer. One of the major advantages of using JSON as a serialization format over XML is that you can deserialize objects in JavaScript by simply evaluating a JSON string. The deserialize method of the client serializer class ends up being very short (error checking removed):

Sys.Serialization.JavaScriptSerializer.deserialize=

function(){eval('('+data+')');}

The serialize method of the JavaScriptSerializer, on the other hand, is considerably more involved. Another advantage to using JSON is its relatively compact representation compared with the XML equivalent.

Much as the XmlSerializer used by standard Web services serializes types to XML, you can take almost any .NET type and serialize it into JSON with JavaScriptSerializer. If you want to try it yourself, it's just a matter of calling the Serialize method of the JavaScriptSerializer class. Figure 4 shows a sample console application that serializes the complex Person type (shown in Figure 5), as an example. (It must include an assembly reference to the Microsoft.Web.Extensions.dll installed in the Global Assembly Cache (GAC) with the https://www.sodocs.net/doc/275551024.html, AJAX Extensions.)

The output of the console application would be the Person class in JSON format, or:

{"Married":true,"Age":33,"FirstName":"Bob","LastName":"Smith"}

Like XmlSerializer, JavaScriptSerializer will only serialize publicly accessible data in a type, and there is no support for resolving cyclic references. But any types that can be serialized by a standard .asmx Web service will work fine with this serializer (and yes, this includes DataSet).

With this knowledge in place, you can build a more complex Web service, knowing that it will handle complex types as easily as any SOAP-based Web service defined in an .asmx file.

The example in Figure 6 shows a Web service called MarriageService that implements a Marry method to take two Person objects (as defined earlier) and modify their attributes appropriately. (The accompanying https://www.sodocs.net/doc/275551024.html, page is included with the code download for this issue.)

If you'd rather work with XML in your client-side script, that option is available as well. In addition to the standard WebMethod attribute used when defining Web services, there is a new attribute in the Microsoft.Web.Script.Services namespace called ScriptMethod, which has a ResponseFormat property that can be set to either Json or Xml (it defaults to Json).

namespace PS

{

[ScriptService]

[WebService(Namespace = "https://www.sodocs.net/doc/275551024.html,/ws")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class StockQuoteService : WebService

{

[WebMethod]

public int GetStockQuote(string symbol)

{

return (new Random()).Next(0, 120);

}

}

}

The serialized response would then be:

74

It is up to you when you invoke this method from client-side JavaScript to handle the XML response. If you plan on running a transformation on it or are already using MSXML, this may be useful.

Conclusion

It's worth pointing out that the https://www.sodocs.net/doc/275551024.html, 2.0 AJAX Extensions provide two pre-built services to tap into specific https://www.sodocs.net/doc/275551024.html, 2.0 application services from client-side code: ProfileService and AuthenicationService. With these two client-side proxy classes you can set and

retrieve profile values for individual clients, as well as perform authentication (via the default Membership provider) and grant authentication cookies completely within client script.

While many discussions and demonstrations of the https://www.sodocs.net/doc/275551024.html, 2.0 AJAX Extensions focus on the flashy controls that enable responsive user interfaces, one of the most impressive and useful features is the ability to call Web services directly from client-side JavaScript. With a full .NET Framework/JSON serializer, direct integration with the familiar .asmx Web services, support for batching, and auto-generated bridges to external Web services, the breadth and depth of support for Web services makes this perhaps the most compelling feature of all.

非常https://www.sodocs.net/doc/275551024.html,

1.1Web 部署项目

当ASP 第一次发布时，Web 编程还比较困难，因为需要 IIS 来处理 ASP 页。后来，https://www.sodocs.net/doc/275551024.html, 2.0 和Visual Studio? 2005 通过引入网站开发模型使一切工作都变得容易了。借助该网站模型，您不必在 Visual Studio 中创建新项目，而是可以指向一个目录并开始编写网页和代码。此外，您还可以使用内置的 https://www.sodocs.net/doc/275551024.html, Development Server 快速测试站点，https://www.sodocs.net/doc/275551024.html, Development Server 将 https://www.sodocs.net/doc/275551024.html, 寄宿在一个本地进程中，并消除了必须安装 IIS 才能进行开发这一先决条件。该网站模型的魅力在于您在开发 Web 应用程序时无需考虑打包和部署。需要其他类时怎么办？向 App_Code 目录添加一个 .cs 文件即可开始编写。希望将可本地化的字符串存储在资源文件中时怎么办？向 App_GlobalResources 目录添加一个 .resx 文件并键入字符串。一切都顺顺当当；您根本就不必考虑编译和部署方面的事情。

在准备进行部署时，您有多种可选方案。最简单的方案是将文件复制到主运行服务器并按要求编译每一个文件（和在测试环境中一样）。第二种方案是使用 aspnet_compiler.exe 实用工具将应用程序预编译为二进制版本，之后将只剩下要放到服务器上的一组程序集、静态内容和配置文件。第三种方案也使用 aspnet_compiler.exe，但要创建一个可更新的二进制部署，其中 .as*x 文件保持不变（并且可修改），而所有代码文件都编译为二进制程序集。

这似乎涵盖了每一种可能的情况，开发人员可以一心一意地编写 Web 应用程序，而在以后实际部署时再作打包和部署决定。不过，此模型也遭到了相当大的反对，特别是那些习惯了自己开发的 Web 项目是在实际项目文件中指定的实际项目的开发人员的反对，这些项目允许注入生成前和生成后函数、从生成过程排除文件以及使用命令行开关在调试和发布版本之间进行切换等操作。有鉴于此，Microsoft 迅速推出了 Web 应用程序项目（即 WAP），

最初它是作为 Visual Studio 2005 的插件发布的，现在包含在 Visual Studio 2005 Service Pack 1 (SP1) 中，Visual Studio 2005 Service Pack 1 (SP1) 可从

https://www.sodocs.net/doc/275551024.html,/vstudio/support/vs2005sp1 下载。

WAP 可替代与 Visual Studio .NET 2005 Web 项目模型非常接近的网站模型。新的 WAP 模型会在生成过程中编译所有源代码文件，并在本地的 /bin 目录中生成一个用于部署的程序集。WAP 还使得增量采用 https://www.sodocs.net/doc/275551024.html, 2.0 引入的新的分部类代码隐藏模型变得更加容易，因为现在您可以打开 Visual Studio .NET 2003 项目，并且在转换过程中只修改 .sln

和 .csproj（或 .vbproj）文件。然后可将每个文件及其代码隐藏类转换为与项目中任何其他文件都无关的新的分部类模型（操作方法是：在解决方案资源管理器中右键单击各个文件并选择“转换为 Web 应用程序”），也可以让它们仍然使用旧模型。这与将 Visual Studio .NET 2003 Web 项目转换为网站模型大不相同，转换为网站模型会同时转换所有文件，并且不支持增量采用。

最后，还有一个称为“Web 部署项目”（本专栏的主题）的新项目类型，它引入了许多既针对网站项目又针对 Web 应用程序项目的附加部署选项。 Web 部署项目弥补了既针对网站应用程序又针对 Web 应用程序项目的部署选项中的遗留漏洞，并且可以简单而又可扩展地实现几乎任何部署方案。为确切了解这一新项目类型增加了哪些内容，我们先来回顾一下在 Web 部署项目推出之前的情况。

使用网站模型生成应用程序时，您可以选择对部署站点进行预编译。通过 Visual Studio 2005 中的“生成”|“发布”菜单或直接通过命令行实用工具

aspnet_compiler.exe，您可以访问预编译实用工具。显示了 Visual Studio 所显示的此工具的界面。

使用发布实用工具时必须作出的第一个决定是 .as*x 文件在部署后是否可更新（在aspnet_compiler.exe 命令行实用工具中使用 -u 开关的“允许更新此预编译站点”选项）。此决定取决于在部署后是否希望能够在不重复整个部署过程的情况下对网页进行较少更改。事实上，您可能希望明确禁止对已部署网页进行任何修改，并要求所有修改都要遵循标准的部署（也希望遵循标准的测试）过程，在这种情况下，应选择将站点发布为不可更新。

将站点发布为不可更新时，您可以完全删除所有 .as*x 文件，而只发布二进制程序集（以及配置文件和静态内容）。不过，如果没有物理文件，https://www.sodocs.net/doc/275551024.html, 将无法确定哪些类要用于哪些端点请求。例如，如果您的应用程序收到一个请求 Page1.aspx 的请求，而您已经使用了不可更新的二进制部署，则磁盘上很可能没有任何 Page1.aspx 文件，并且现有配置文件中没有任何内容来指示部署到 /bin 目录的程序集集合中哪个类应是该请求的实际处理程序。为弥补这一缺陷，编译过程还将生成一个 .compiled 文件集合，这些文件以简单的XML 格式包含端点-类型映射和文件依赖关系信息，同时这些文件必须与所部署站点的 /bin

目录中的二进制程序集一起发布。例如，如果应用程序中原来有一个名为 Page1.aspx 的页，则 aspnet_compiler.exe 实用工具会生成一个名为 https://www.sodocs.net/doc/275551024.html,piled（哈希代码不定）的文件，其中包含以下 XML：

virtualPath="/SampleWebSite/Page1.aspx"

hash="8a8da6c5a" filehash="42c4a74221152888"

flags="110000" assembly="App_Web_aq9bt8mj"

type="ASP.page1_aspx">

使用此实用工具发布网站时必须作出的另一个重要决定是确定生成的程序集的打包粒度。通过选中“使用固定命名和单页程序集”（或在 aspnet_compiler.exe 命令行实用工具中使用 -fixednames），既可为站点中的每个目录创建单独的程序集，又可为站点中的每个可编译文件创建单独的程序集。作出该决定并不像您可能想像的那么容易，因为每个选项都有其潜在问题。如果决定不使用 -fixednames 选项，则每次发布应用程序时都会生成一组全新的程序集，并且它们的名称与之前发布的程序集不同。这意味着部署更加复杂，因为在部署新的程序集之前必须删除主运行服务器上所有以前发布的程序集，否则在处理下一个请求时将生成冗余的类定义错误。使用 -fixednames 选项可以解决此问题，因为每个文件都将与命名清晰的程序集对应，而这些程序集在一次编译和下次编译中不会发生变化。不过，如果站点规模较大，则为每个网页、控件和母版页分别生成单独的程序集，很明显意味着您要管理成百上千个程序集的发布。Web 部署项目非常圆满地解决了部署中程序集粒度这一问题，如下所示。

您还可以将程序集签名引入编译过程，以便创建具有强名称的不同版本的程序集，如果需要这也适用于全局程序集缓存 (GAC) 中的部署。通过使用 -aptca 选项，您可以使用程序集级别的属性 AllowPartiallyTrustedCallers 来标记生成的程序集，在将任何程序集部署到 GAC 并且以低等或中等信任级别运行 https://www.sodocs.net/doc/275551024.html, 的情况下，这是必要的。（请注意，此属性应仅应用于已证明不会暴露任何安全漏洞的程序集，因为如有漏洞，使用此属性可能招致引诱攻击。）

有关发布站点的另一个细节是如果决定使用 Web 应用程序项目而不使用网站模型，则“生成”|“发布”对话框的外观将大不相同。Web 应用程序项目假定您希望将应用程序发

布为可更新的 .as*x 文件和预编译的源文件（开发中它所使用的同一模型），因此仅针对二进制的部署选项不可用。此实用工具实质上更接近于“复制网站”实用工具（随网站一起提供）而不是“发布网站”实用工具，因为它需要复制由标准生成过程生成的文件。

从技术上讲，即使您使用 Web 应用程序项目，也不会限制您使用仅针对二进制（不可更新）的部署。其实，WAP 生成的输出是一个有效的网站，然后您可以传递

aspnet_compiler.exe 实用工具来生成创建二进制部署。幸运的是，您只是不能从 Web 部署项目调整过的 Visual Studio 2005 界面调用它而已。

Web 部署项目

那么迄今为止所有现有的编译和部署选项中缺少什么呢？主要缺少两种功能：控制程序集命名（特别是为了进行部署）的功能，以及将所有输出的程序集合并为一个程序集从而简化部署的功能。Web 部署项目可以解决这两个问题。但或许更重要的是，它们还与网站应用程序和 Web 应用程序项目的部署问题中的许多遗留问题有关。

它们的核心是，Web 部署项目（可从 https://www.sodocs.net/doc/275551024.html,/aa336619.aspx 下载）代表的只是向您解决方案中添加的另一个项目类型。与所有 Visual Studio 项目文件一样，Web 部署项目也是可在 IDE 中直接编译或从命令行运行的 MSBuild 脚本。不过，Web 部署项目包含用于编译和打包网站（或 Web 应用程序项目）的生成命令，而不指定要编译的源代码文件集合。这意味着它们会调用 aspnet_compiler.exe 实用工具（以及其他实用工具）来创建特定 Web 应用程序的部署。Web 部署项目是作为 Visual Studio 插件包提供的，其中包含了一个用于注入新项目的易用菜单项和一个用于控制所有可用设置的完整属性页集。若要向现有应用程序中添加新项目，可右键单击现有网站（或 Web 应用程序项目），然后选择“添加 Web 部署项目”项。此操作将把一个包含 MSBuild 脚本的新 .wdproj 文件添加到您的解决方案中，并会生成您所创建的应用程序的部署。

将 Web 部署项目添加到您的解决方案之后，您就可以通过访问项目文件的属性页来精确控制项目的用途。新部署项目的默认设置是以可更新模式部署应用程序，所有 .as*x 文件都将保持不变，源文件则编译为部署在顶级 /bin 目录中的一个程序集。不管源应用程序使用网站模型还是使用 Web 应用程序项目模型，这些部署项目的作用都是相同的，这意味着无论您现在选择哪个开发模型都不会影响您的部署选项。Web 部署项目最重要的功能之一是它能够将所有部署都配置为二进制（不可更新）- 一个程序集，您可以为该程序集选择名称。使用此部署模型意味着，您只需将一个程序集放到活动站点的 /bin 目录中即可更新整个站点，并且在部署或处理导致错误的已部分部署的站点之前无需删除现有程序集。为端点映射部署 .compiled 文件仍是必需的，但只有当您在站点中添加、删除或移动页时这些文件才会发生变化。

Web 部署项目提供了部署灵活性，使您可以在作出打包和部署决定时无需考虑 Web 应用程序的实际生成过程。借助 aspnet_compiler.exe 实用工具，https://www.sodocs.net/doc/275551024.html, 2.0 的原始版本

部分地实现了开发和部署之间的这种独立性，但由于执行部署时的各种约束从未完全实现。Web 部署项目则已完全实现了开发和部署的分离，有关应用程序如何生成的决定将不再影响部署选择。

合并程序集

Web 部署项目的功能主要是对通过 MSBuild 任务和新界面提供的现有实用工具进行重新打包，但除此之外还提供了几个全新功能。其中最引人关注的功能是程序集合并功能。

安装 Web 部署项目时，您会发现安装目录（默认情况下

是 %PROGRAMFILES%\MSBuild\Microsoft\WebDeployment\v8.0）中有一个名为

aspnet_merge.exe 的可执行文件。该可执行文件能够提取预编译站点的多个程序集输出并将这些程序集合并为一个程序集。如果选中 Web 部署项目中的合并选项，则该实用工具即可集成到生成脚本中。为了说明该实用工具的功能，我们来看一个没有可更新开关的预编译网站的输出。该输出的源应用程序包含两个子目录、一个顶级 global.asax 文件、一个在App_Code 中定义的类以及一个用户控件。最终的编译结果是五个不同的程序集和一

个 .compiled 文件集合。如果在此目录上运行 aspnet_merge.exe 实用工具（使用 -o 开关）来请求一个程序集输出，结果将是一个可管理性大大提高的单一程序集，其名称可以随意指定。

虽然随 Web 部署项目一起提供的 aspnet_merge.exe 实用工具和相应的 MSBuild 任务是新的，但自从微软研究院将Microsoft? .NET Framework 1.1 包装成名为 ILMerge 的实用工具以来，用于合并程序集的基础技术实际上就已经诞生了。ILMerge 的最新版本可从https://www.sodocs.net/doc/275551024.html,/~mbarnett/ILMerge.aspx 下载。此实用工具现已直接集成到aspnet_merge.exe 中，用于执行与合并程序集相关的所有繁重任务。其实，程序集合并是一项相当复杂的任务。您需要考虑签名、版本控制、其他程序集级别的属性、嵌入式资源和XML 文档，同时还要管理冲突类型名称的详细信息等内容。ILMerge 实用工具可以为您管理所有这些内容，并用开关来控制有关该过程的各种决定。使用该实用工具还可以将 .exe 程序集转换为 .dll 程序集以便打包。例如，假定您有三个程序集：a.dll、b.dll 和 c.exe，并要将它们合并为一个库程序集。只要类型名称中没有冲突，下面的命令行就会生成一个新库 d.dll，其中包含在 a.dll、b.dll 和 c.exe 中定义的所有类型：

ilmerge.exe /t:library /ndebug /out:d.dll a.dll b.dll c.exe

可插入配置文件

Web 部署项目提供的另一个全新功能是创建可插入配置文件。部署 Web 应用程序时，要确定一种方法来管理开发与部署之间配置文件的差别是一个常见问题。例如，您的一个本地测试数据库可能用于运行站点，另一个数据库用于暂存服务器，还有一个数据库用于主运行服务器。如果将连接字符串存储在 web.config 中（通常是在 connectionStrings 部分），那么在将应用程序推送到暂存服务器或实际工作环境时，就需要通过某种方式来修改这些字

毕设外文资料翻译.

理工学院 毕业设计外文资料翻译 专业：计算机科学与技术 姓名：马艳丽 学号： 12L0752218 外文出处：The Design and Implementation of 3D Electronic Map of Campus Based on WEBGIS 附件： 1.外文资料翻译译文；2.外文原文。

附件1：外文资料翻译译文 基于WebGIS的校园三维电子地图的设计与实现 一．导言 如今，数字化和信息化是当今时代的主题。随着信息革命和计算机科学的发展，计算机技术已经渗透到科学的各个领域，并引起了许多革命性的变化，在这些科目，古代制图学也不例外。随着技术和文化的不断进步，地图变化的形式和内容也随之更新。在计算机图形学中，地理信息系统（GIS）不断应用到Web，制作和演示的传统方式经历了巨大的变化，由于先进的信息技术的发展，地图的应用已经大大延长。在这些情况下，绘图将面临广阔的发展前景。电子地图是随之应运而生的产品之一。随着计算机技术，计算机图形学理论，遥感技术，航空摄影测量技术和其他相关技术的飞速发展。用户需要的三维可视化，动态的交互性和展示自己的各种地理相关的数据处理和分析，如此多的关注应支付的研究三维地图。东北石油大学及其周边地区的基础上本文设计并建立三维电子地图。 二．系统设计 基于WebGIS的校园三维电子地图系统的具有普通地图的一般特性。通过按键盘上的箭头键（上，下，左，右），可以使地图向相应的方向移动。通过拖动鼠标，可以查看感兴趣的任何一个地方。使用鼠标滚轮，可以控制地图的大小，根据用户的需求来查看不同缩放级别的地图。在地图的左下角会显示当前鼠标的坐标。在一个div层，我们描绘了一个新建筑物的热点，这层可以根据不同的地图图层的显示，它也可以自动调整。通过点击热点，它可以显示热点的具体信息。也可以输入到查询的信息，根据自己的需要，并得到一些相关的信息。此外，通过点击鼠标，人们可以选择检查的三维地图和卫星地图。 主要功能包括： ?用户信息管理：检查用户名和密码，根据权限设置级别的认证，允许不同权限的用户通过互联网登录系统。 ?位置信息查询：系统可以为用户提供模糊查询和快速定位。

计算机专业毕业设计说明书外文翻译(中英对照)

Talking about security loopholes Richard S. Kraus reference to the core network security business objective is to protect the sustainability of the system and data security, This two of the main threats come from the worm outbreaks, hacking attacks, denial of service attacks, Trojan horse. Worms, hacker attacks problems and loopholes closely linked to, if there is major security loopholes have emerged, the entire Internet will be faced with a major challenge. While traditional Trojan and little security loopholes, but recently many Trojan are clever use of the IE loophole let you browse the website at unknowingly were on the move. Security loopholes in the definition of a lot, I have here is a popular saying: can be used to stem the "thought" can not do, and are safety-related deficiencies. This shortcoming can be a matter of design, code realization of the problem. Different perspective of security loo phole s In the classification of a specific procedure is safe from the many loopholes in classification. 1. Classification from the user groups: ● Public loopholes in the software category. If the loopholes in Windows, IE loophole, and so on. ● specialized software loophole. If Oracle loopholes, Apach e,

计算机专业ASPNET外文翻译

Extreme https://www.sodocs.net/doc/275551024.html, 1.1Web Deployment Projects When ASP was first released, Web programming was more difficult because you needed IIS to serve your ASP pages. Later, https://www.sodocs.net/doc/275551024.html, 2.0 and Visual Studio? 2005 made everything easier by introducing the Web site model of development. Instead of creating a new project inside Visual Studio, the Web site model lets you point to a directory and start writing pages and code. Furthermore, you can quickly test your site with the built-in https://www.sodocs.net/doc/275551024.html, Development Server, which hosts https://www.sodocs.net/doc/275551024.html, in a local process and obviates the need to install IIS to begin developing. The beauty of the Web site model is that you can develop your Web application without thinking about packaging and deployment. Need another class? Add a .cs file to the App_Code directory and start writing. Want to store localizable strings in a resource file? Add a .resx file to the App_GlobalResources directory and type in the strings. Everything just works; you don't have to think about the compilation and deployment aspect at all. When you are ready to deploy, you have several options. The simplest choice is to copy your files to a live server and let everything be compiled on-demand (as it was in your test environment). The second option is to use the aspnet_compiler.exe utility and precompile the application into a binary release, which leaves you nothing but a collection of assemblies, static content, and configuration files to push to the server. The third option is to again use aspnet_compiler.exe, but to create an updateable binary deployment where your .as*x files remain intact (and modifiable) and all of your code files are compiled into binary assemblies. This seems to cover every possible scenario, leaving the developer to focus simply on writing the Web application, with packaging and deployment decisions to be made later when the application is actually deployed. There was a fair amount of backlash against this model, however, especially from developers who were used to their Web projects being real projects, specified in real project files, that let you inject pre-and post-build functions, exclude files from the build process, move between debug and release builds with a command-line switch, and so on. In response, Microsoft quickly introduced the Web Application Project or WAP, initially released as an add-in to Visual Studio 2005, and now included in Visual Studio 2005 Service available for download from https://www.sodocs.net/doc/275551024.html,/vstudio/support/vs2005sp1. WAP provides an alternative to the Web site model that is much closer to the Visual Studio .NET 2005 Web Project model. The new WAP model compiles all of the source code files during the build process and generates a single assembly in the local /bin directory for deployment. WAP also makes it much easier to incrementally adopt the new partial class codebehind model

计算机专业外文文献及翻译

微软Visual Studio 1微软Visual Studio Visual Studio 是微软公司推出的开发环境，Visual Studio可以用来创建Windows平台下的Windows应用程序和网络应用程序，也可以用来创建网络服务、智能设备应用程序和Office 插件。Visual Studio是一个来自微软的集成开发环境IDE，它可以用来开发由微软视窗，视窗手机，Windows CE、.NET框架、.NET精简框架和微软的Silverlight支持的控制台和图形用户界面的应用程序以及Windows窗体应用程序，网站，Web应用程序和网络服务中的本地代码连同托管代码。 Visual Studio包含一个由智能感知和代码重构支持的代码编辑器。集成的调试工作既作为一个源代码级调试器又可以作为一台机器级调试器。其他内置工具包括一个窗体设计的GUI应用程序，网页设计师，类设计师，数据库架构设计师。它有几乎各个层面的插件增强功能，包括增加对支持源代码控制系统（如Subversion和Visual SourceSafe）并添加新的工具集设计和可视化编辑器，如特定于域的语言或用于其他方面的软件开发生命周期的工具（例如Team Foundation Server的客户端：团队资源管理器）。 Visual Studio支持不同的编程语言的服务方式的语言，它允许代码编辑器和调试器（在不同程度上）支持几乎所有的编程语言，提供了一个语言特定服务的存在。内置的语言中包括C/C + +中（通过Visual C++）,https://www.sodocs.net/doc/275551024.html,（通过Visual https://www.sodocs.net/doc/275551024.html,），C＃中（通过Visual C＃）和F＃（作为Visual Studio 2010），为支持其他语言，如M,Python,和Ruby等，可通过安装单独的语言服务。它也支持的 XML/XSLT,HTML/XHTML ,JavaScript和CSS.为特定用户提供服务的Visual Studio也是存在的：微软Visual Basic，Visual J＃、Visual C＃和Visual C++。 微软提供了“直通车”的Visual Studio 2010组件的Visual Basic和Visual C＃和Visual C + +，和Visual Web Developer版本，不需任何费用。Visual Studio 2010、2008年和2005专业版，以及Visual Studio 2005的特定语言版本（Visual Basic、C++、C＃、J＃），通过微软的下载DreamSpark计划，对学生免费。 2架构 Visual Studio不支持任何编程语言，解决方案或工具本质。相反，它允许插入各种功能。特定的功能是作为一个VS压缩包的代码。安装时，这个功能可以从服务器得到。IDE提供三项服务：SVsSolution，它提供了能够列举的项目和解决方案; SVsUIShell，它提供了窗口和用户界面功能（包括标签，工具栏和工具窗口）和SVsShell，它处理VS压缩包的注册。此外，IDE还可以负责协调和服务之间实现通信。所有的编辑器，设计器，项目类型和其他工具都是VS压缩包存在。Visual Studio 使用COM访问VSPackage。在Visual Studio SDK中还包括了管理软件包框架(MPF)，这是一套管理的允许在写的CLI兼容的语言的任何围绕COM的接口。然而，MPF并不提供所有的Visual Studio COM 功能。

计算机网络安全文献综述

计算机网络安全综述学生姓名：李嘉伟 学号：11209080279 院系：信息工程学院指导教师姓名：夏峰二零一三年十月

［摘要］ 随着计算机网络技术的快速发展，网络安全日益成为人们关注的焦点。本文分析了影响网络安全的主要因素及攻击的主要方式，从管理和技术两方面就加强计算机网络安全提出了针对性的建议。 ［关键词］ 计算机网络；安全；管理；技术；加密；防火墙 一．引言 计算机网络是一个开放和自由的空间，但公开化的网络平台为非法入侵者提供了可乘之机，黑客和反黑客、破坏和反破坏的斗争愈演愈烈，不仅影响了网络稳定运行和用户的正常使用，造成重大经济损失，而且还可能威胁到国家安全。如何更有效地保护重要的信息数据、提高计算机网络的安全性已经成为影响一个国家的政治、经济、军事和人民生活的重大关键问题。本文通过深入分析网络安全面临的挑战及攻击的主要方式，从管理和技术两方面就加强计算机网络安全提出针对性建议。

二．正文 1.影响网络安全的主要因素［1］ 计算机网络安全是指“为数据处理系统建立和采取的技术和管理的安全保护，保护计算机硬件、软件数据不因偶然和恶意的原因而遭到破坏、更改和泄漏”。计算机网络所面临的威胁是多方面的，既包括对网络中信息的威胁，也包括对网络中设备的威胁，但归结起来，主要有三点：一是人为的无意失误。如操作员安全配置不当造成系统存在安全漏洞，用户安全意识不强，口令选择不慎，将自己的帐号随意转借他人或与别人共享等都会给网络安全带来威胁。二是人为的恶意攻击。这也是目前计算机网络所面临的最大威胁，比如敌手的攻击和计算机犯罪都属于这种情况，此类攻击又可以分为两种：一种是主动攻击，它以各种方式有选择地破坏信息的有效性和完整性；另一类是被动攻击，它是在不影响网络正常工作的情况下，进行截获、窃取、破译以获得重要机密信息。这两种攻击均可对计算机网络造成极大的危害，并导致机密数据的泄漏。三是网络软件的漏洞和“后门”。任何一款软件都或多或少存在漏洞，这些缺陷和漏洞恰恰就是黑客进行攻击的首选目标。绝大部分网络入侵事件都是因为安全措施不完善，没有及时补上系统漏洞造成的。此外，软件公司的编程人员为便于维护而设置的软件“后门”也是不容忽视的巨大威胁，一旦“后门”洞开，别人就能随意进入系统，后果不堪设想。

计算机专业外文文献翻译6

外文文献翻译（译成中文2000字左右）： As research laboratories become more automated,new problems are arising for laboratory managers.Rarely does a laboratory purchase all of its automation from a single equipment vendor. As a result,managers are forced to spend money training their users on numerous different software packages while purchasing support contracts for each. This suggests a problem of scalability. In the ideal world,managers could use the same software package to control systems of any size; from single instruments such as pipettors or readers to large robotic systems with up to hundreds of instruments. If such a software package existed, managers would only have to train users on one platform and would be able to source software support from a single vendor. If automation software is written to be scalable, it must also be flexible. Having a platform that can control systems of any size is far less valuable if the end user cannot control every device type they need to use. Similarly, if the software cannot connect to the customer’s Laboratory Information Management System (LIMS) database,it is of limited usefulness. The ideal automation software platform must therefore have an open architecture to provide such connectivity. Two strong reasons to automate a laboratory are increased throughput and improved robustness. It does not make sense to purchase high-speed automation if the controlling software does not maximize throughput of the system. The ideal automation software, therefore, would make use of redundant devices in the system to increase throughput. For example, let us assume that a plate-reading step is the slowest task in a given method. It would make that if the system operator connected another identical reader into the system, the controller software should be able to use both readers, cutting the total throughput time of the reading step in half. While resource pooling provides a clear throughput advantage, it can also be used to make the system more robust. For example, if one of the two readers were to experience some sort of error, the controlling software should be smart enough to route all samples to the working reader without taking the entire system offline. Now that one embodiment of an ideal automation control platform has been described let us see how the use of C++ helps achieving this ideal possible. DISCUSSION C++: An Object-Oriented Language Developed in 1983 by BjarneStroustrup of Bell Labs,C++ helped propel the concept of object-oriented programming into the mainstream.The term ‘‘object-oriented programming language’’ is a familiar phrase that has been in use for decades. But what does it mean? And why is it relevant for automation software? Essentially, a language that is object-oriented provides three important programming mechanisms:

ASPNET毕业设计外文翻译3

毕业设计(论文)外文资料翻译 学院 专业 学生姓名 班级学号 外文出处 附件：1.外文资料翻译译文；2.外文原文 指导教师评价： 1．翻译内容与课题的结合度：□优□良□中□差2．翻译内容的准确、流畅：□优□良□中□差3．专业词汇翻译的准确性：□优□良□中□差4．翻译字符数是否符合规定要求：□符合□不符合 指导教师签名： 年月日

附件1：外文资料翻译译文 非常https://www.sodocs.net/doc/275551024.html, 1.1Web 部署项目 当ASP 第一次发布时，Web 编程还比较困难，因为需要 IIS 来处理 ASP 页。后来，https://www.sodocs.net/doc/275551024.html, 2.0 和 Visual Studio? 2005 通过引入网站开发模型使一切工作都变得容易了。借助该网站模型，您不必在 Visual Studio 中创建新项目，而是可以指向一个目录并开始编写网页和代码。此外，您还可以使用内置的 https://www.sodocs.net/doc/275551024.html, Development Server 快速测试站点，https://www.sodocs.net/doc/275551024.html, Development Server 将 https://www.sodocs.net/doc/275551024.html, 寄宿在一个本地进程中，并消除了必须安装 IIS 才能进行开发这一先决条件。该网站模型的魅力在于您在开发 Web 应用程序时无需考虑打包和部署。需要其他类时怎么办？向 App_Code 目录添加一个 .cs 文件即可开始编写。希望将可本地化的字符串存储在资源文件中时怎么办？向 App_GlobalResources 目录添加一个 .resx 文件并键入字符串。一切都顺顺当当；您根本就不必考虑编译和部署方面的事情。 在准备进行部署时，您有多种可选方案。最简单的方案是将文件复制到主运行服务器并按要求编译每一个文件（和在测试环境中一样）。第二种方案是使用 aspnet_compiler.exe 实用工具将应用程序预编译为二进制版本，之后将只剩下要放到服务器上的一组程序集、静态内容和配置文件。第三种方案也使用 aspnet_compiler.exe，但要创建一个可更新的二进制部署，其中 .as*x 文件保持不变（并且可修改），而所有代码文件都编译为二进制程序集。 这似乎涵盖了每一种可能的情况，开发人员可以一心一意地编写 Web 应用程序，而在以后实际部署时再作打包和部署决定。不过，此模型也遭到了相当大的反对，特别是那些习惯了自己开发的 Web 项目是在实际项目文件中指定的实际项目的开发人员的反对，这些项目允许注入生成前和生成后函数、从生成过程排除文件以及使用命令行开关在调试和发布版本之间进行切换等操作。有鉴于此，Microsoft 迅速推出了 Web 应用程序项目（即 WAP），最初它是作为 Visual Studio 2005 的插件发布的，现在包含在 Visual Studio 2005 Service Pack 1 (SP1) 中，Visual Studio 2005 Service Pack 1 (SP1) 可从https://www.sodocs.net/doc/275551024.html,/vstudio/support/vs2005sp1 下载。 WAP 可替代与 Visual Studio .NET 2005 Web 项目模型非常接近的网站模型。新的WAP 模型会在生成过程中编译所有源代码文件，并在本地的 /bin 目录中生成一个用于部署的程序集。WAP 还使得增量采用 https://www.sodocs.net/doc/275551024.html, 2.0 引入的新的分部类代码隐藏模型变得更

无线局域网-计算机毕业论文外文翻译

毕业设计(论文)外文资料翻译 系：信息工程学院 专业：计算机科学与技术 姓名： 学号： 外文出处：Chris Haseman. Android-essential (用外文写) s[M].London:Spring--Verlag,2008 .8-13. 附件： 1.外文资料翻译译文；2.外文原文。 指导教师评语： 签名： 年月日注：请将该封面与附件装订成册。

附件1：外文资料翻译译文 无线局域网 一、为何使用无线局域网络 对于局域网络管理主要工作之一，对于铺设电缆或是检查电缆是否断线这种耗时的工作，很容易令人烦躁，也不容易在短时间内找出断线所在。再者，由于配合企业及应用环境不断的更新与发展，原有的企业网络必须配合重新布局，需要重新安装网络线路，虽然电缆本身并不贵，可是请技术人员来配线的成本很高，尤其是老旧的大楼，配线工程费用就更高了。因此，架设无线局域网络就成为最佳解决方案。 二、什么情形需要无线局域网络 无线局域网络绝不是用来替代有限局域网络，而是用来弥补有线局域网络之不足，以达到网络延伸之目的，下列情形可能须要无线局域网络。 ●无固定工作场所的使用者 ●有线局域网络架设受环境限制 ●作为有线局域网络的备用系统 三、无线局域网络存取技术 目前厂商在设计无线局域网络产品时，有相当多种存取设计方式，大致可分为三大类：窄频微波技术、展频(Spread Spectrum)技术、及红外线(Infrared)技术，每种技术皆有其优缺点、限制及比较，接下来是这些技术方法的详细探讨。 1.技术要求 由于无线局域网需要支持高速、突发的数据业务，在室内使用还需要解决多径衰落以及各子网间串扰等问题。具体来说，无线局域网必须实现以下技术要求： 1)可靠性：无线局域网的系统分组丢失率应该低于10-5，误码率应该低 于10-8。

网络安全外文翻译文献

网络安全外文翻译文献 (文档含英文原文和中文翻译) 翻译： 计算机网络安全与防范 1.1引言 计算机技术的飞速发展提供了一定的技术保障，这意味着计算机应用已经渗透到社会的各个领域。在同一时间，巨大的进步和网络技术的普及，社会带来了巨大的经济利润。然而，在破坏和攻击计算机信息系统的方法已经改变了很多的网络环境下，网络安全问题逐渐成为计算机安全的主流。

1.2网络安全 1.2.1计算机网络安全的概念和特点 计算机网络的安全性被认为是一个综合性的课题，由不同的人，包括计算机科学、网络技术、通讯技术、信息安全技术、应用数学、信息理论组成。作为一个系统性的概念，网络的安全性由物理安全、软件安全、信息安全和流通安全组成。从本质上讲，网络安全是指互联网信息安全。一般来说，安全性、集成性、可用性、可控性是关系到网络信息的相关理论和技术，属于计算机网络安全的研究领域。相反，狭隘“网络信息安全”是指网络安全，这是指保护信息秘密和集成，使用窃听、伪装、欺骗和篡夺系统的安全性漏洞等手段，避免非法活动的相关信息的安全性。总之，我们可以保护用户利益和验证用户的隐私。 计算机网络安全有保密性、完整性、真实性、可靠性、可用性、非抵赖性和可控性的特点。 隐私是指网络信息不会被泄露给非授权用户、实体或程序，但是授权的用户除外，例如，电子邮件仅仅是由收件人打开，其他任何人都不允许私自这样做。隐私通过网络信息传输时，需要得到安全保证。积极的解决方案可能会加密管理信息。虽然可以拦截，但它只是没有任何重要意义的乱码。 完整性是指网络信息可以保持不被修改、破坏，并在存储和传输过程中丢失。诚信保证网络的真实性，这意味着如果信息是由第三方或未经授权的人检查，内容仍然是真实的和没有被改变的。因此保持完整性是信息安全的基本要求。 可靠性信息的真实性主要是确认信息所有者和发件人的身份。 可靠性表明该系统能够在规定的时间和条件下完成相关的功能。这是所有的网络信息系统的建立和运作的基本目标。 可用性表明网络信息可被授权实体访问，并根据自己的需求使用。 不可抵赖性要求所有参加者不能否认或推翻成品的操作和在信息传输过程中的承诺。

毕业设计外文翻译

毕业设计（论文） 外文翻译 题目西安市水源工程中的 水电站设计 专业水利水电工程 班级 学生 指导教师 2016年

研究钢弧形闸门的动态稳定性 牛志国 河海大学水利水电工程学院，中国南京，邮编210098 nzg_197901@https://www.sodocs.net/doc/275551024.html,，niuzhiguo@https://www.sodocs.net/doc/275551024.html, 李同春 河海大学水利水电工程学院，中国南京，邮编210098 ltchhu@https://www.sodocs.net/doc/275551024.html, 摘要 由于钢弧形闸门的结构特征和弹力，调查对参数共振的弧形闸门的臂一直是研究领域的热点话题弧形弧形闸门的动力稳定性。在这个论文中，简化空间框架作为分析模型，根据弹性体薄壁结构的扰动方程和梁单元模型和薄壁结构的梁单元模型，动态不稳定区域的弧形闸门可以通过有限元的方法，应用有限元的方法计算动态不稳定性的主要区域的弧形弧形闸门工作。此外，结合物理和数值模型，对识别新方法的参数共振钢弧形闸门提出了调查，本文不仅是重要的改进弧形闸门的参数振动的计算方法，但也为进一步研究弧形弧形闸门结构的动态稳定性打下了坚实的基础。 简介 低举升力，没有门槽，好流型，和操作方便等优点，使钢弧形闸门已经广泛应用于水工建筑物。弧形闸门的结构特点是液压完全作用于弧形闸门，通过门叶和主大梁，所以弧形闸门臂是主要的组件确保弧形闸门安全操作。如果周期性轴向载荷作用于手臂，手臂的不稳定是在一定条件下可能发生。调查指出:在弧形闸门的20次事故中，除了极特殊的破坏情况下，弧形闸门的破坏的原因是弧形闸门臂的不稳定;此外，明显的动态作用下发生破坏。例如:张山闸，位于中国的江苏省，包括36个弧形闸门。当一个弧形闸门打开放水时，门被破坏了，而其他弧形闸门则关闭，受到静态静水压力仍然是一样的，很明显，一个动态的加载是造成的弧形闸门破坏一个主要因素。因此弧形闸门臂的动态不稳定是造成弧形闸门(特别是低水头的弧形闸门)破坏的主要原是毫无疑问。

计算机专业外文翻译

专业外文翻译 题目JSP Technology Conspectus and Specialties 系（院）计算机系 专业计算机科学与技术 班级 学生姓名 学号 指导教师 职称讲师 二〇一三年五月十六日

JSP Technology Conspectus and Specialties The JSP (Java Server Pages) technology is used by the Sun micro-system issued by the company to develop dynamic Web application technology. With its easy, cross-platform, in many dynamic Web application programming languages, in a short span of a few years, has formed a complete set of standards, and widely used in electronic commerce, etc. In China, the JSP now also got more extensive attention; get a good development, more and more dynamic website to JSP technology. The related technologies of JSP are briefly introduced. The JSP a simple technology can quickly and with the method of generating Web pages. Use the JSP technology Web page can be easily display dynamic content. The JSP technology are designed to make the construction based on Web applications easier and efficient, and these applications and various Web server, application server, the browser and development tools work together. The JSP technology isn't the only dynamic web technology, also not the first one, in the JSP technology existed before the emergence of several excellent dynamic web technologies, such as CGI, ASP, etc. With the introduction of these technologies under dynamic web technology, the development and the JSP. Technical JSP the development background and development history In web brief history, from a world wide web that most of the network information static on stock transactions evolution to acquisition of an operation and infrastructure. In a variety of applications, may be used for based on Web client, look no restrictions. Based on the browser client applications than traditional based on client/server applications has several advantages. These benefits include almost no limit client access and extremely simplified application deployment and management (to update an application, management personnel only need to change the program on a server, not thousands of installation in client applications). So, the software industry is rapidly to build on the client browser multilayer application. The rapid growth of exquisite based Web application requirements development of

外文文献—从经典ASP到ASPNET

附录Ⅰ英文文献翻译 Moving from Classic ASP to https://www.sodocs.net/doc/275551024.html, ABSTRACT https://www.sodocs.net/doc/275551024.html, is Microsoft new offering for Web application development, innovation within https://www.sodocs.net/doc/275551024.html, have resulted in significant industry popularity for this product. Consequently there is an increased need for https://www.sodocs.net/doc/275551024.html, education. The Web Application Development is a third year undergraduate course. To meet the demands of both industry and students, we have changed the focus of this course from Classic ASP to https://www.sodocs.net/doc/275551024.html,. This paper reports this move. The significant features of https://www.sodocs.net/doc/275551024.html, and the motivations for this move are discussed. The process, the problems encountered, and some helpful online learning resources are described. Key words: Web Application Development, Classic ASP, https://www.sodocs.net/doc/275551024.html,, Move, https://www.sodocs.net/doc/275551024.html, 1. INTRODUCTION https://www.sodocs.net/doc/275551024.html, is not just a new version of ASP. It provides innovation for moving Windows applications to Web applications. Web services and the .NET framework have made the vision of the Web as the next generation computing platform a reality. With server controls, Web forms and “code-behind”, we can develop a Web application by using a complete object-oriented programming (OOP) model. This increases the popularity of https://www.sodocs.net/doc/275551024.html, in industry. The industry project is the final course of the Bachelor of Computing Systems (BCS) degree at UNITEC, in which students undertake a real-world project. We have observed a rapid growth of https://www.sodocs.net/doc/275551024.html, related industry projects in our school. The Web Application Development (WAD) paper is a third year undergraduate course. It was originally offered using ASP 2.0 and ColdFusion. To meet the demands from both industry and students, we have changed the course content to cover https://www.sodocs.net/doc/275551024.html,, Visual https://www.sodocs.net/doc/275551024.html, (https://www.sodocs.net/doc/275551024.html,) and ColdFusion. This change commenced with the first semester of 2003. This paper will examine the features of https://www.sodocs.net/doc/275551024.html, and explain why these are unique. The motivations for moving to https://www.sodocs.net/doc/275551024.html, are discussed by analyzing the current situation of https://www.sodocs.net/doc/275551024.html, related to industry projects in our school, analyzing the results of short surveys on students, and