01 July, 2009

Interview Questions on ASP.NET Page navigation techniques

What are different page navigation techniques in ASP.NET?
Hyperlink control : Navigate to another page.
Response.Redirect : Navigate to another page from code. This is equivalent to clicking a hyperlink.
Server.Transfer : End the current Web form and begin executing a new Web form. This method works only when navigating to a Web Forms page (.aspx).
Server.Execute : Begin executing a new Web form while still displaying the current Web form. The contents of both forms are combined. This method works only when navigating to a Web Forms page (.aspx).
Window.Open script method : Display a page in a new browser window on the client.

What is the difference between Response.Redirect and Server.Transfer?
1.
When we use Server.Transfer the redirection happens on the server where as when we use Response.Redirect the redirection happens from the browser.
2. Server.Transfer is faster as there is no round trip involved while navigating from one webform to another webform.
Response.Redirect is slower than Server.Transfer as there is round trip from the server to the client browser.
3. Server.Transfer works only with .aspx files where as Response.Redirect works with .aspx and .Htm pages.
4. Server.Transfer will work with files on the same web server. You can't use Server.Transfer to send the user to an external site where as Response.Redirect can do that.
5. Server.Transfer does not update the URL in the browser. For example when you navigate from WebForm1.aspx to WebForm2.aspx using Server.Transfer the URL in the browser still shows WebForm1.aspx while you are actually looking at WebForm2.aspx. Response.Redirect updates the URL in the browser.

What is the use of Server.Execute method?
Server.Execute method is used to process a second Web form without leaving the first Web form. This technique lets you direct the results from a Web form to a region on the current page.

Is it possible to send a webform's QueryString, ViewState, and event procedure information to another webform?
Yes, we can use Server.Transfer or Server.Execute to send a webform's QueryString, ViewState, and event procedure information to another webform.

For this to work you have to set the preserveForm argument to True.To be able to read one Web form’s ViewState from another, you must first set the EnableViewStateMac attribute in the Web form’s Page directive to False. By default, ASP.NET hashes ViewState information, and setting this attribute to False disables that hashing so that the information can be read on the subsequent Web form.

Managed Code and Unmanaged Code related ASP.NET Interview Questions

What is Managed Code and Unmanaged Code?
Microsoft ASP.NET Web applications run under the control of the common language runtime (CLR). The CLR controls how the application’s assembly executes, allocates, and recovers memory; therefore, ASP.NET applications are said to use managed code. In contrast, most other Windows executables use unmanaged code because the executable itself determines how memory is used.

Examples of unmanaged code include the Microsoft Win32 API, legacy DLLs and EXEs created for Windows applications prior to the Microsoft .NET Framework, and COM objects.

What is Platform Invoke or pinvoke?
The process of executing native code from within a .NET assembly is called platform invoke, or pinvoke for short. You use platform invoke to call the Win32 API directly, to access existing (legacy) DLLs your company uses, or to access procedures compiled to native code for performance reasons.

What are the steps to follow to use Platform Invoke?
To use platform invoke, follow the following steps:
1. Import the System.Runtime.InteropServices namespace.
2. Declare the unmanaged procedure using the DllImport attribute or the Declare statement.
3. Map the data types of the procedures parameters to the equivalent .NET types.
4. Call the unmanaged procedure and test its return value for success.
5. If the procedure did not succeed, retrieve and handle the exception code using the Marshal object’s GetLastWin32Error method.

What are the limitations of using Unmanaged Code from within a .NET assembly?
Performance :
Although native-code DLLs can perform some operations more quickly than equivalent code managed by the CLR, these benefits might be offset by the time it takes to marshal the data to pass between the unmanaged procedure and the .NET assembly.
Type safety : Unlike .NET assemblies, unmanaged procedures might not be type-safe. This can affect the reliability of your .NET application. In general, reliability is a paramount concern with ASP.NET Web applications.
Code security : Unmanaged procedures do not use the .NET Framework’s model for code security.
Versioning:Unmanaged code does not support .NET versioning; therefore, assemblies that call unmanaged procedures might lose the benefit of being able to coexist with other versions of the same assembly.

What are COM objects?
COM objects are another type of unmanaged code that you can use from .NET assemblies. Because COM is widely used, Visual Studio includes built-in tools for importing and using COM objects within .NET assemblies. Visual Studio also includes the option of automatically registering .NET class library assemblies for use from COM.

List the steps in order, to use a COM object from a .NET assembly in Visual Studio?
1. Install and register the COM object on your system.
2. Open the .NET project in Visual Studio, and add a reference to the COM object, as shown in diagram below. If the COM object does not appear on the COM tab of the Add Reference dialog box, you can add a reference directly to the executable by clicking Browse.


3. Create an instance of the COM object in code, and use it as you would any other object.

What happens when you add a reference to a COM object from with in a dot net application?
When you add a reference to a COM object, Visual Studio automatically generates an interop assembly for the object and places it in the project’s /bin folder. The interop assembly is created from the COM object’s type information and contains the metadata that the CLR uses to call the unmanaged code in the COM object. You can then use COM objects from within .NET code the same way that you use .NET classes.

You can view this interop assembly using the Microsoft Intermediate Language Disassembler (Ildasm.exe) included in the .NET Framework.

Can we create a .NET object for use from COM?
Yes, Visual Studio can automatically generate type library information and register a .NET class library assembly for use from COM. These automatic tools do not work for ASP.NET Web applications, so you must isolate the code you want to use from COM in its own Class Library project.

How do you hide Public .NET Classes and other public members from COM?
In some cases, you might want to hide selected .NET classes from COM but keep them public for use from other .NET assemblies. The ComVisible attribute allows you to select which public .NET classes and members are included in the generated type library. This attribute applies hierarchically for the assembly, class, and member levels.
How do you handle exceptions between .NET and COM?
.NET handles errors through exception classes. COM handles errors through 32-bit data types called HRESULTs. All of the .NET exception classes include HResult properties that map to COM HRESULT codes.

If an exception occurs in a .NET object, the exception is automatically mapped to the appropriate HRESULT and returned to COM. Similarly, if an exception occurs in a COM object, the COM HRESULT is mapped to the appropriate exception class, which is returned to .NET, where it can be handled just like any other exception.

If you are creating your own .NET exception classes for use with COM, be sure to set the class’s HResult property so that the exception can be handled within COM.

What are the technical limitations of COM Interop?
The .NET Framework was developed to address the limitations of COM. Because of this evolution, there are limits to the .NET features that you can use from COM. The following list describes these limits:
Static members : COM requires objects to be created before use, so it does not support .NET Static members.
New members : COM flattens the inheritance tree of .NET objects, so members in a derived class that hides members inherited from a base class are not callable.
Constructors with parameters : COM can’t pass parameters to an object’s constructor.

What are the practical limitations of using COM objects?
The following are the practical limitations of using COM objects from .NET:
Shared solutions might not allow COM objects : ASP.NET host that use nondedicated servers can limit or prohibit the installation of COM objects on their servers.
COM objects are prone to memory leaks : COM uses reference counting to determine when to destroy objects and free memory. It is possible for this reference count to become incorrect, leaving objects in memory indefinitely.
Type libraries might be inaccurate : Because COM separates the object’s description from its implementation, it’s possible for this description to not accurately reflect the object. In this case, the generated interop assembly will also include those inaccuracies.
COM is unmanaged code : All the limitations of unmanaged code apply to COM objects as well.