Beruflich Dokumente
Kultur Dokumente
The .NET Framework has two main components: the common language runtime and the .NET Framework class library. The common language runtime is the foundation of the .NET Framework. You can think of the runtime as an agent that manages code at execution time, providing core services such as memory management, thread management, and remoting, while also enforcing strict type safety and other forms of code accuracy that promote security and robustness. In fact, the concept of code management is a fundamental principle of the runtime. Code that targets the runtime is known as managed code, while code that does not target the runtime is known as
unmanaged code. The class library, the other main component of the .NET Framework, is a comprehensive, object-oriented collection of reusable types that you can use to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by ASP.NET, such as Web Forms and XML Web services. The .NET Framework can be hosted by unmanaged components that load the common language runtime into their processes and initiate the execution of managed code, thereby creating a software environment that can exploit both managed and unmanaged features. The .NET Framework not only provides several runtime hosts, but also supports the development of third-party runtime hosts.
2. With the help of a suitable example, explain the steps involved in editing, compiling and running a C# program.
Creating C# Program To create, compile and run a C# program by following the steps illustrated in the following topics Compiling and Executing The minimum requirements for getting started with C# programming are: 1. A text editor (like Windows Notepad) 2. The Microsoft .NET Framework The text editor allows you to type in the C# code that will be compiled.
Example: Public class classtest { Public static void Main () { System.console.writeLine (Welcome to c#); } } The sample program typed in Notepad
The Microsoft .Net Framework In addition to the text editor, you should have the Microsoft .Net Framework installed on your PC or Laptop. Steps for writing and compiling the C# code: Step 1: Type the C# code in the notepad as shown below:
Public class classtest { Public static void Main () { System.console.writeLine (Welcome to c#);
} }
Step 2: Save the file into the folder containing the folder corresponding to C#. In my machine it is: C:\Program Files\Microsoft Visual Studio\SDK\V2.0> Step 3: Open the command prompt (Start -> Run and type cmd and click OK) and navigate to the folder where you have saved the file. Alternatively you can start the command window from Windows Start Menu Step 4: Now we are ready to compile the program from the C# command line. The compiler used here is called csc.exe and is in the folder v2.0 of SDK. The syntax for compiling the sample C# program is: csc.exe <filename>.cs The name of our C# program is classtest.cs. The syntax for compilation of the above program file is: csc.exe classtest.cs Step 5: The source code is now compiled into an executable format. The name of the executable file thus generated is hello.exe, which is having the same name as the source code file name, except that the .cs extension is replaced by the .exe extension. To run the executable file, the following command should be typed at the command prompt: classtest .exe The executable file gets executed by the environment and the string message Welcome to C# would be displayed on the console window.
Load: CreateChildControls ( ) is called, if necessary, to create and initialize server controls in the control tree. State is restored, and the form controls show client-side data. You can modify the load phase by handling the Load event with the OnLoad method. Send Postback Change Modifications: If there are any state changes between the current state and the previous state, change events are raised via the RaisePostDataChangedEvent ( ) method. Handle Postback Events: The client-side event that caused the postback is handled. PreRender: This is the phase just before the output is rendered to the browser. It is essentially your last chance to modify the output prior to rendering using the OnPreRender ( ) method. Save State: Near the beginning of the life cycle, the persisted view state was loaded from the hidden variable. Now it is saved back to the hidden variable, persisting as a string object that will complete the round trip to the client. You can override this using the SaveViewState () method. Render: This is where the output to be sent back to the client browser is generated. You can override it using the Render method. CreateChildControls ( ) is called, if necessary, to create and initialize server controls in the control tree. Dispose: This is the last phase of the life cycle. It gives you an opportunity to do any final cleanup and release references to any expensive resources, such as database connections. You can modify it using the Dispose ( ) method.
HTML server controls are HTML elements (or elements in other supported markup, such as XHTML) containing attributes that make them programmable in server code. By default, HTML elements on an ASP.NET Web page are not available to the server. Instead, they are treated as opaque text and passed through to the browser. However, by converting HTML elements to HTML server controls, you expose them as elements you can program on the server. The object model for HTML server controls maps closely to that of the corresponding elements. For example, HTML attributes are exposed in HTML server controls as properties. Any HTML element on a page can be converted to an HTML server control by adding the attribute runat="server". During parsing, the ASP.NET page framework creates instances of all elements containing the runat="server" attribute. If you want to refer to the control as a member within your code, you should also assign an id attribute to the control. The page framework provides predefined HTML server controls for the HTML elements most commonly used dynamically on a page: the form element, the input elements (text box, check box, Submit button), the select element, and so on. These predefined HTML server controls share the basic properties of the generic control, and in addition, each control typically provides its own set of properties and its own event. HTML Server Control Features: An object model that you can program against on the server using familiar object-oriented techniques. Each server control exposes properties that enable you to manipulate the control's markup attributes programmatically in server code. A set of events for which you can write event handlers in much the same way you would in a client-based form, except that the event is handled in server code. The ability to handle events in client script. Automatic maintenance of the control's state. When the page makes a round trip to the server, the values that the user entered into HTML server controls are automatically maintained and sent back to the browser. Interaction with ASP.NET validation controls so you can verify that a user has entered appropriate information into a control. Data binding to one or more properties of the control. Support for styles if the ASP.NET Web page is displayed in a browser that supports cascading style sheets. Pass-through of custom attributes. You can add any attributes you need to an HTML server control and the page framework will render them without any change in functionality. This enables you to add browser-specific attributes to your controls. Working with Web Server Controls Web server controls are a second set of controls designed with a different emphasis. They do not necessarily map one-to-one to HTML server controls. Instead, they are defined as abstract controls in which the actual markup rendered by the control can be quite different from the model that you program against. For example, a RadioButtonList Web server control might be rendered in a table or as inline text with other markup. Web server controls include traditional form controls such as buttons and text boxes as well as complex controls such as tables. They also include controls that provide commonly used form functionality such as displaying data in a grid, choosing dates, displaying menus, and so on. The controls use syntax such as the following: <asp: button attributes runat="server" id="Button1" /> The attributes in this case are not those of HTML elements. Instead, they are properties of the Web control. When the ASP.NET Web page runs, the Web server control is rendered on the page using appropriate markup, which
often depends not only on the browser type but also on settings that you have made for the control. For example, a Textbox control might render as an input tag or a textarea tag, depending on its properties. You add controls to an ASP.NET Web page much the same way you add any HTML element. You can either use a visual designer or add a control from the toolbox, or you can type the element representing the control into the page's markup.
February 2010 Master of Computer Application (MCA) Semester 5 MC0081 .(DOT) Net Technologies 4 Credits
(Book ID: B0974)
B) Application State
ASP.NET allows you to save values using application state which is an instance of the HttpApplocationState class for each active Web application. Application state is a global storage mechanism that is accessible from all pages in the Web application. Thus, application state is useful for storing information that needs to be maintained between server round trips and between requests for pages. Application state is stored in a key/value dictionary that is created during each request to a specific URL. You can add your application-specific information to this structure to store it between page requests.
Once you add your application-specific information to application state, the server manages it.
If youd prefer ,you can write DISCO files for individual Web services and reference Them in master DISCO file using discoveryRef element . Heres a DISCO file that points to other DISCO file that points to other DISCO files .Once more URLs can be absolute or relative:
<?xml version=1.0?> <discovery xmlns=http://schemas.xmlsoap.org/disco/> <discoveryRef ref =http://www.wintellect.com/calc.disco/> <discoveryRef ref =http://www.wintellect.com/locator.disco/> </discover>
A third option is to deploy a VSDISCO to enable dynamic discovery . The following VSDISCO file automatically exposes all ASMX and DISCO files in a host directory and its subdirectories ,with the exception of these subdirectories noted with exclude element: <?xml version=1.0?> <dynamic discovery xmlns=urn:schemas-dynamicdiscovery:disco .2000-30-17> <exclude path=_vti_cnf/> <exclude path=_vti_pvt/> <exclude path=_vti_log/> <exclude path=_vti_script/> <exclude path=_vti_txt/> <dynamic discovery>
How does dynamic discovery work ? ASP. NET maps the file name extension.vsdisco to an HTTP handler that scans the host directory and subdirectory for ASMX and DISCO files and returns a dynamically generate DISCO document .A client that request a VSDISCO file gets back what appears to be static DISCO document For security reasons ,Microsoft disable dynamic discovery just before version 1.0 of the .NET Framework shipped .You can re-enable it by un-commenting the line in the httpHandlers section of Machine .config that maps *.vsdisco to System.WebServices.DiscoveryRequestHandler and granting the ASPNET account permission to access the IIS metabase Microsoft highly discourages dynamic discovery for fear of compromising your Web server ,and a bug in version1.0 of the .NET Framework SDK prevent most DISCO-aware tools from working with VSDISCO anyway . My advice is to forget that VSDISCO files even exist and use static DISCO Files instead. To further simplify Web services discovery , you can link to a master DISCO file from your sites default HTML document . For example ,suppose the default HTML document at www.wintellect.com is default .html and that the same directory also holds a directory document named Default.disco. Including the following HTML in Default.html enables most tools that read DISCO files to accept the URL ww.wintellect.com
<html> <head> <link type=text/htmlrel=alternatehref=Default.disco> </head> </html> Visual Studio.NET reads DISCO files; so does the disco.exe utility that comes with the .NET Framework SDK Discos chief disadvantages is thts at you cant read Disco file if you dont have its URL . So how do you find a web service if you dont even have a URL to start with ?can you spell U-D-D-I?
certain threshold . If another application fails because of the volume of request that it receives, you can set the application pools worker process to recycle when the application exceeds specified number of requests. By creating new application pools and assigning Web sites and applications to them ,you can make your server more efficient , reliable , and secure, and ensure that your application remain available even when a worker process serving an application pool is recycled because of faulty application. . An application pool is configuration that links one or more application to a set of one or more worker processes. Because applications in an application pool are separated from other applications by worker process boundaries, an application in one application pool is not affected by problem caused by application in other application pools. By creating new application pools and assigning Web site and applications to them, you can make your server more efficient and reliable, as well as making your other application always available, even when the worker process serving the new application pool has problems. Guidelines for Creating Application Pools To isolate Web application on a Web site from Web application on other sites worker running on the same computer, create an individual application pool for each Web site. For enhanced security, configure a unique user account (process identify) for each application pool. Use an account with the least user right possible, such as Network services in the IIS_WPG group. If there is a test version of an application on the same server with the production version of the application pools this isolates the test version of the application. As a design consideration , if you b. Deploying ASP.NET Application to run with its own unique set of properties, create a unique application pool for that application . Configuring Application Pools in IIS6.0(IIS 6.0)
Note: You must be a member of the Administrators group on the local computer to perform the following procedures .As a security best practice, log on to your computer by using an account that is not in the administrators group, and then use the runas command to run IIS Manager as an administrator At a command prompt, type runas /user: Administrative_AccountName mmc%systemroot %system32\inetsrv\iis.msc. Step to create a new Application Pool : 1. In IIS Manger, expand the local computer, right-click Application Pools, point to new and then click Application Pool. 2. In the application pool name box, type the new application tool. 3. If the ID that appears in the Application pool Id box is not the ID that you want, type a new ID. 4. Under Application pool setting, click the appropriate setting. If you click Use existing application tool as template, in the application pool name box, right click the application pool that you want to use as a template. 5. Click OK.
Application pool allows you to apply configuration settings to group of applications and the worker processes that service those applications. Any web site, web directory, or virtual directory can be assigned to an application pool. Assigning an application to an application pool: In IIS Manager, right click the application that you want to assign to an application pool, and then click properties. Click the virtual directory, directory and home directory tab. If you are assigning a directory or virtual directory, verify that application name is filled in. If the application name box is not filled in, click create, and then type a name. In the application pool list box, click the name of the application pool to which you want to assign the web site.
About Configuring Servers for applications (IIS 6.0) Internet information services (IIS) 6.0 delivers web hosting services through an adjustable architecture that you can use to manage server resources with improved stability, efficiency, and performance. IIS separates applications into isolated pools and automatically detects memory leaks, defective processes, and over utilized resources. When problems occur, IIS manages them by shutting down and redeploying faulty resources and connecting faulty processes to analytical tools. IIS can run in either of two mutually exclusive modes of operation: Worker process isolation mode. This is the default mode of IIS 6.0, isolates key components of the World Wide Web publishing service (WWW service) from the effects of errant applications, and it protects applications from each other by using the worker process component. Use worker process isolation mode unless you have a specific compatibility issue that makes the use of IIS 5.0 isolation mode necessary. Web sites that serve static content or simple ASP applications should be able to move to IIS 6.0 running in worker process isolation mode with little or no modification. IIS 5.0 isolation mode. With this mode, you can run applications that are incompatible with worker process isolation mode because they were developed for earlier versions of IIS. Applications that run correctly on IIS 5.0 should run correctly on IIS 6.0 in IIS 5.9 isolation mode.
Worker process isolation mode provides better default security for running web applications than IIS 5.0 isolation mode. By default, worker processes run with the Network service identity. The network service account has lower access rights than the default account for IIS 5.0 application mode run as local system. The local system account can read, execute, and change most of the resources on the computer. The default isolation mode upon installing IIS 6.0 depends on whether you perform a clean installation or an upgrade. After a clean install of IIS 6.0, IIS runs in worker process isolation mode. After an upgrade from an earlier version of IIS 6.0, the isolation mode is the same as configured on the previously-installed version of IIS 6.0. After an upgrade from IIS 5.0 or IIS 4.0, IIS 6.0 runs in IIS 5.0 isolation mode by default to maintain compatibility with your existing applications.
Worker Process Isolation Mode IIS 6.0 introduces worker process isolation mode, which runs all Web applications in an isolated environment. When you run IIS in worker process isolation mode, applications can be configured to run in separate application pools. Each application pool is a logical representation of a configurable worker process and links to the applications in the pool. Worker processes operate independently of each other, they can fail without affecting other worker processes. The pooling of applications protects applications from the effects of worker processes that support other application pools. In this way, applications are protected from each other. In worker process isolation mode, Hypertext Transfer Protocol (HTTP) requests are routed directly to an in-kernel application pool queue serving the configured application. Worker processes that serve an application pool pull the requests directly from the queue avoiding process-switching overhead. To further protect your WWW service, IIS 6.0 isolates critical World Wide Web publishing service (WWW service) components, such as the HTTP protocol stack (HTTP.sys) and WWW service Administration and monitoring, from the effects of third party code running in worker processes. HTTP.sys continues to process requests. Meanwhile, the WWW service detects that the worker process is unhealthy and shuts it down. If there is demand for a new worker process to serve requests (HTTP.sys has requests queued), the WWW service starts a new worker process to pick the queued request form HTTP.sys. Even though a worker process has failed, the WWW service continues to process requests and shields the user from experiencing a loss of service. IIS 6.0 worker process isolation mode delivers the following specific improvements over earlier versions of IIS: Robust Performance isolation prevents Web applications and Web sites from affecting each other or the WWW service. Reboots of the operating system and restarting of the WWW service are avoided. Self-Healing automated management provides auto restart of failed worker processes and periodic restart of deteriorating worker process. Scalability Web gardens allow more than one worker process to serve the same application pool. Process Affinity enables the connection of worker processes to specific processors on multi-CPU servers. Automated debugging the debugging feature enables the automatic assignment of failing worker processes to debugging tools. CPU limiting this monitoring feature enables controlling the amount of CPU resources that an application pool consumes in a configured amount of time.