What is the difference between repeater over datalist and datagrid? The Repeater class is not derived from the WebControl class, like the DataGrid and DataList. Therefore, the Repeater lacks the stylistic properties common to both the DataGrid and DataList. What this boils down to is that if you want to format the data displayed in the Repeater, you must do so in the HTML markup. The Repeater control provides the maximum amount of flexibility over the HTML produced. Whereas the DataGrid wraps the DataSource contents in an HTML < table >, and the DataList wraps the contents in either an HTML < table > or < span > tags (depending on the DataList’s RepeatLayout property), the Repeater adds absolutely no HTML content other than what you explicitly specify in the templates. While using Repeater control, If we wanted to display the employee names in a bold font we’d have to alter the “ItemTemplate” to include an HTML bold tag, Whereas with the DataGrid or DataList, we could have made the text appear in a bold font by setting the control’s ItemStyle-Font-Bold property to True. The Repeater’s lack of stylistic properties can drastically add to the development time metric. For example, imagine that you decide to use the Repeater to display data that needs to be bold, centered, and displayed in a particular font-face with a particular background color. While all this can be specified using a few HTML tags, these tags will quickly clutter the Repeater’s templates. Such clutter makes it much harder to change the look at a later date. Along with its increased development time, the Repeater also lacks any built-in functionality to assist in supporting paging, editing, or editing of data. Due to this lack of feature-support, the Repeater scores poorly on the usability scale. However, The Repeater’s performance is slightly better than that of the DataList’s, and is more noticeably better than that of the DataGrid’s. Following figure shows the number of requests per second the Repeater could handle versus the DataGrid and DataList
Can we handle the error and redirect to some pages using web.config? Yes, we can do this, but to handle errors, we must know the error codes; only then we can take the user to a proper error message page, else it may confuse the user. CustomErrors Configuration section in web.config file: The default configuration is: < customErrors mode=”RemoteOnly” defaultRedirect=”Customerror.aspx” > < error statusCode=”404″ redirect=”Notfound.aspx” / > < /customErrors > If mode is set to Off, custom error messages will be disabled. Users will receive detailed exception error messages. If mode is set to On, custom error messages will be enabled. If mode is set to RemoteOnly, then users will receive custom errors, but users accessing the site locally will receive detailed error messages. Add an < error > tag for each error you want to handle. The error tag will redirect the user to the Notfound.aspx page when the site returns the 404 (Page not found) error. [Example] There is a page MainForm.aspx Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load ‘Put user code to initialize the page here Dim str As System.Text.StringBuilder str.Append(“hi”) ‘ Error Line as str is not instantiated Response.Write(str.ToString) End Sub [Web.Config] < customErrors mode=”On” defaultRedirect=”Error.aspx”/ > ‘ a simple redirect will take the user to Error.aspx [user defined] error file. < customErrors mode=”RemoteOnly” defaultRedirect=”Customerror.aspx” > < error statusCode=”404″ redirect=”Notfound.aspx” / > < /customErrors > ‘This will take the user to NotFound.aspx defined in IIS.
How do you implement Paging in .Net? The DataGrid provides the means to display a group of records from the data source (for example, the first 10), and then navigate to the “page” containing the next 10 records, and so on through the data. Using Ado.Net we can explicit control over the number of records returned from the data source, as well as how much data is to be cached locally in the DataSet. 1.Using DataAdapter.fill method give the value of ‘Maxrecords’ parameter (Note: – Don’t use it because query will return all records but fill the dataset based on value of ‘maxrecords’ parameter). 2.For SQL server database, combines a WHERE clause and a ORDER BY clause with TOP predicate. 3.If Data does not change often just cache records locally in DataSet and just take some records from the DataSet to display.
What is the difference between Server.Transfer and Response.Redirect? Server.Transfer() : client is shown as it is on the requesting page only, but the all the content is of the requested page. Data can be persist across the pages using Context.Item collection, which is one of the best way to transfer data from one page to another keeping the page state alive. Response.Dedirect() :client knows the physical location (page name and query string as well). Context.Items loses the persistence when navigate to destination page. In earlier versions of IIS, if we wanted to send a user to a new Web page, the only option we had was Response.Redirect. While this method does accomplish our goal, it has several important drawbacks. The biggest problem is that this method causes each page to be treated as a separate transaction. Besides making it difficult to maintain your transactional integrity, Response.Redirect introduces some additional headaches. First, it prevents good encapsulation of code. Second, you lose access to all of the properties in the Request object. Sure, there are workarounds, but they’re difficult. Finally, Response.Redirect necessitates a round trip to the client, which, on high-volume sites, causes scalability problems. As you might suspect, Server.Transfer fixes all of these problems. It does this by performing the transfer on the server without requiring a roundtrip to the client. Response.Redirect sends a response to the client browser instructing it to request the second page. This requires a round-trip to the client, and the client initiates the Request for the second page. Server.Transfer transfers the process to the second page without making a round-trip to the client. It also transfers the HttpContext to the second page, enabling the second page access to all the values in the HttpContext of the first page.
Can you create an app domain? Yes, We can create user app domain by calling on of the following overload static methods of the System.AppDomain class 1. Public static AppDomain CreateDomain(String friendlyName) 2. Public static AppDomain CreateDomain(String friendlyName, Evidence securityInfo) 3. Public static AppDomain CreateDomain(String friendlyName, Evidence securityInfo, AppDomainSetup info) 4. Public static AppDomain CreateDomain(String friendlyName, Evidence securityInfo, String appBasePath, String appRelativeSearchPath, bool shadowCopyFiles)
What are the various security methods which IIS Provides apart from .NET ? The various security methods which IIS provides are a) Authentication Modes b) IP Address and Domain Name Restriction c) DNS Lookups DNS Lookups d) The Network ID and Subnet Mask e) SSL
What is Web Gardening? How would using it affect a design? The Web Garden Model The Web garden model is configurable through the section of the machine.config file. Notice that the section is the only configuration section that cannot be placed in an application-specific web.config file. This means that the Web garden mode applies to all applications running on the machine. However, by using the node in the machine.config source, you can adapt machine-wide settings on a per-application basis. Two attributes in the section affect the Web garden model. They are webGarden and cpuMask. The webGarden attribute takes a Boolean value that indicates whether or not multiple worker processes (one per each affinitized CPU) have to be used. The attribute is set to false by default. The cpuMask attribute stores a DWORD value whose binary representation provides a bit mask for the CPUs that are eligible to run the ASP.NET worker process. The default value is -1 (0xFFFFFF), which means that all available CPUs can be used. The contents of the cpuMask attribute is ignored when the webGarden attribute is false. The cpuMask attribute also sets an upper bound to the number of copies of aspnet_wp.exe that are running. Web gardening enables multiple worker processes to run at the same time. However, you should note that all processes will have their own copy of application state, in-process session state, ASP.NET cache, static data, and all that is needed to run applications. When the Web garden mode is enabled, the ASP.NET ISAPI launches as many worker processes as there are CPUs, each a full clone of the next (and each affinitized with the corresponding CPU). To balance the workload, incoming requests are partitioned among running processes in a round-robin manner. Worker processes get recycled as in the single processor case. Note that ASP.NET inherits any CPU usage restriction from the operating system and doesn’t include any custom semantics for doing this. All in all, the Web garden model is not necessarily a big win for all applications. The more stateful applications are, the more they risk to pay in terms of real performance. Working data is stored in blocks of shared memory so that any changes entered by a process are immediately visible to others. However, for the time it takes to service a request, working data is copied in the context of the process. Each worker process, therefore, will handle its own copy of working data, and the more stateful the application, the higher the cost in performance. In this context, careful and savvy application benchmarking is an absolute must. Changes made to the section of the configuration file are effective only after IIS is restarted. In IIS 6, Web gardening parameters are stored in the IIS metabase; the webGarden and cpuMask attributes are ignored.
What is view state?.where it stored?.can we disable it? The web is state-less protocol, so the page gets instantiated, executed, rendered and then disposed on every round trip to the server. The developers code to add “statefulness” to the page by using Server-side storage for the state or posting the page to itself. When require to persist and read the data in control on webform, developer had to read the values and store them in hidden variable (in the form), which were then used to restore the values. With advent of .NET framework, ASP.NET came up with ViewState mechanism, which tracks the data values of server controls on ASP.NET webform. In effect,ViewState can be viewed as “hidden variable managed by ASP.NET framework!”. When ASP.NET page is executed, data values from all server controls on page are collected and encoded as single string, which then assigned to page’s hidden atrribute “< input type=hidden >”, that is part of page sent to the client. ViewState value is temporarily saved in the client’s browser.ViewState can be disabled for a single control, for an entire page orfor an entire web application. The syntax is: Disable ViewState for control (Datagrid in this example) < asp:datagrid EnableViewState=”false” … / > Disable ViewState for a page, using Page directive < %@ Page EnableViewState=”False” … % > Disable ViewState for application through entry in web.config < Pages EnableViewState=”false” … / >