|
| Favorites | Home Page | email : santhosh0123@yahoo.com |
|
C#, .NET, XML, IIS - Interview Questions (last updated on Saturday, 13. March 2004)
class Program
{
public static void Main()
{
TakesADelegate(new MyDelegate(DelegateFunction));
}
public static void TakesADelegate(MyDelegate SomeFunction)
{
SomeFunction(21);
}
public static void DelegateFunction(int i)
{
System.Console.WriteLine("Called by delegate with number: {0}.", i);
}
}
Level = Machine
Code Groups:
1. All code: Nothing
1.1. Zone - MyComputer: FullTrust
1.1.1. Honor SkipVerification requests: SkipVerification
1.2. Zone - Intranet: LocalIntranet
1.3. Zone - Internet: Internet
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.6. StrongName - 0024000004800000940000000602000000240000525341310004000003
000000CFCB3291AA715FE99D40D49040336F9056D7886FED46775BC7BB5430BA4444FEF8348EBD06
F962F39776AE4DC3B7B04A7FE6F49F25F740423EBF2C0B89698D8D08AC48D69CED0FC8F83B465E08
07AC11EC1DCC7D054E807A43336DDE408A5393A48556123272CEEEE72F1660B71927D38561AABF5C
AC1DF1734633C602F8F2D5: Everything
Note the hierarchy of code groups - the top of the hierarchy
is the most general ('All code'), which is then sub-divided into several groups,
each of which in turn can be sub-divided. Also note that (somewhat
counter-intuitively) a sub-group can be associated with a more permissive
permission set than its parent. using System;
using System.Runtime.Remoting;
public class CAppDomainInfo : MarshalByRefObject
{
public string GetAppDomainInfo()
{
return "AppDomain = " + AppDomain.CurrentDomain.FriendlyName;
}
}
public class App
{
public static int Main()
{
AppDomain ad = AppDomain.CreateDomain( "Andy's new domain", null, null );
ObjectHandle oh = ad.CreateInstance( "appdomaintest", "CAppDomainInfo" );
CAppDomainInfo adInfo = (CAppDomainInfo)(oh.Unwrap());
string info = adInfo.GetAppDomainInfo();
Console.WriteLine( "AppDomain info: " + info );
return 0;
}
}
catch
clause that can handle the exception, as determined by the run-time type of
the exception. First, the current method is searched for a lexically enclosing
try
statement, and the associated catch clauses of the try statement are
considered in order. If that fails, the method that called the current method
is searched for a lexically enclosing
try statement that
encloses the point of the call to the current method. This search continues
until a catch
clause is found that can handle the current exception, by naming an exception
class that is of the same class, or a base class, of the run-time type of the
exception being thrown. A catch
clause that doesn't name an exception class can handle any exception.finally
clauses that were associated with try statements more nested that than the one
that caught the exception. object
type) or if there is no base class destructor, then the exception is
discarded.The following example demonstrates the basic way of using reflection to get access to custom attributes.
class MainClass
{
public static void Main()
{
System.Reflection.MemberInfo info = typeof(MyClass);
object[] attributes = info.GetCustomAttributes();
for (int i = 0; i < attributes.Length; i ++)
{
System.Console.WriteLine(attributes[i]);
}
}
}
public static readonly uint l1 = (uint) DateTime.Now.Ticks;class a
{
public virtual int m()
{
return 1;
}
}
class b:a
{
public int j()
{
return m();
}
}
class Token
{
public string Display()
{
//Implementation goes here
return "base";
}
}
class IdentifierToken:Token
{
public new string Display() //What is the use of new keyword
{
//Implementation goes here
return "derive";
}
}
static void Method(Token t)
{
Console.Write(t.Display());
}
public static void Main()
{
IdentifierToken Variable=new IdentifierToken();
Method(Variable); //Which Class Method is called here
Console.ReadLine();
}
For the above code What is the "new" keyword and Which Class Method is
called here
A: it will call base class Display method
class Token
{
public virtual string Display()
{
//Implementation goes here
return "base";
}
}
class IdentifierToken:Token
{
public override string Display() //What is the use of new keyword
{
//Implementation goes here
return "derive";
}
}
static void Method(Token t)
{
Console.Write(t.Display());
}
public static void Main()
{
IdentifierToken Variable=new IdentifierToken();
Method(Variable); //Which Class Method is called here
Console.ReadLine();
}
A: Derive
| Interfaces vs. Abstract Classes | ||
| Feature | Interface | Abstract class |
| Multiple inheritance | A class may implement several interfaces. | A class may extend only one abstract class. |
|
Default implementation |
An interface cannot provide any code at all, much less default code. |
An abstract class can provide complete code, default code, and/or just stubs that have to be overridden. |
|
Constants |
Static final constants only, can use them without qualification in classes that implement the interface. On the other paw, these unqualified names pollute the namespace. You can use them and it is not obvious where they are coming from since the qualification is optional. |
Both instance and static constants are possible. Both static and instance intialiser code are also possible to compute the constants. |
|
Third party convenience |
An interface implementation may be added to any existing third party class. |
A third party class must be rewritten to extend only from the abstract class. |
|
is-a vs -able or can-do |
Interfaces are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects. |
An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Damamation descendants are Dogs, they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not the things a class is. |
|
Plug-in |
You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the interface, you start from scratch without any default implementation. You have to obtain your tools from other classes; nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design. |
You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad. Another issue that's important is what I call "heterogeneous vs. homogeneous." If implementors/subclasses are homogeneous, tend towards an abstract base class. If they are heterogeneous, use an interface. (Now all I have to do is come up with a good definition of hetero/homogeneous in this context.) If the various objects are all of-a-kind, and share a common state and behavior, then tend towards a common base class. If all they share is a set of method signatures, then tend towards an interface. |
|
Homogeneity |
If all the various implementations share is the method signatures, then an interface works best. |
If the various implementations are all of a kind and share a common status and behavior, usually an abstract class works best. |
|
Maintenance |
If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method. |
Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method. |
|
Speed |
Slow, requires extra indirection to find the corresponding method in the actual class. Modern JVMs are discovering ways to reduce this speed penalty. |
Fast |
|
Terseness |
The constant declarations in an interface are all presumed public static final, so you may leave that part out. You can't call any methods to compute the initial values of your constants. You need not declare individual methods of an interface abstract. They are all presumed so. |
You can put shared code into an abstract class, where you cannot into an interface. If interfaces want to share code, you will have to write other bubblegum to arrange that. You may use methods to compute the initial values of your constants and variables, both instance and static. You must declare all the individual methods of an abstract class abstract. |
|
Adding functionality |
If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method. |
If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change. |
interface ICommon
{
int getCommon();
}
interface ICommonImplements1:ICommon
{
}
interface ICommonImplements2:ICommon
{
}
public class a:ICommonImplements1,ICommonImplements2
{
}How to implement getCommon method in class a? Are you seeing any problem in the implementation?public class a:ICommonImplements1,ICommonImplements2
{
public int getCommon()
{
return 1;
}
}
interface IWeather
{
void display();
}
public class A:IWeather
{
public void display()
{
MessageBox.Show("A");
}
}
public class B:A
{
}
public class C:B,IWeather
{
public void display()
{
MessageBox.Show("C");
}
}
When I instantiate C.display(), will it work?interface IPrint
{
string Display();
}
interface IWrite
{
string Display();
}
class PrintDoc:IPrint,IWrite
{
//Here is implementation
}
how to implement the Display in the class printDoc (How to resolve the naming Conflict)
A: no naming conflictsclass PrintDoc:IPrint,IWrite
{
public string Display()
{
return "s";
}
}
interface IList
{
int Count { get; set; }
}
interface ICounter
{
void Count(int i);
}
interface IListCounter: IList, ICounter {}
class C
{
void Test(IListCounter x)
{
x.Count(1); // Error
x.Count = 1; // Error
((IList)x).Count = 1; // Ok, invokes IList.Count.set
((ICounter)x).Count(1); // Ok, invokes ICounter.Count
}
}
try
{
try
{
...
}
catch
{
...
//exception occurred here.
}
finally
{
...
}
}
catch
{
...
}
finally
{
...
}
try
{
...
}
catch
{
...
}
finally
{
..
}
Will it go to finally block if there is no exception happened?| Code Render Block | Code Declaration Block |
| Compiled | |
| Request/Response | Event Driven |
| Object Oriented - Constructors/Destructors, Inheritance, overloading.. | |
| Exception Handling - Try, Catch, Finally | |
| Down-level Support | |
| Cultures | |
| User Controls | |
| In-built client side validation | |
| Session - weren't transferable across servers | It can span across servers, It can survive server crashes, can work with browsers that don't support cookies |
| built on top of the window & IIS, it was always a separate entity & its functionality was limited. | its an integral part of OS under the .net framework. It shares many of the same objects that traditional applications would use, and all .net objects are available for asp.net's consumption. |
| Garbage Collection | |
| Declare variable with datatype | |
| In built graphics support | |
| Cultures | |
| Phase | What a control needs to do | Method or event to override |
|---|---|---|
| Initialize | Initialize settings needed during the lifetime of the incoming Web request. | Init event (OnInit method) |
| Load view state | At the end of this phase, the ViewState property of a control is automatically populated as described in Maintaining State in a Control. A control can override the default implementation of the LoadViewState method to customize state restoration. | LoadViewState method |
| Process postback data | Process incoming form data and update properties accordingly. | LoadPostData method (if IPostBackDataHandler is implemented) |
| Load | Perform actions common to all requests, such as setting up a database query. At this point, server controls in the tree are created and initialized, the state is restored, and form controls reflect client-side data. | Load event (OnLoad method) |
| Send postback change notifications | Raise change events in response to state changes between the current and previous postbacks. | RaisePostDataChangedEvent method (if IPostBackDataHandler is implemented) |
| Handle postback events | Handle the client-side event that caused the postback and raise appropriate events on the server. | RaisePostBackEvent method(if IPostBackEventHandler is implemented) |
| Prerender | Perform any updates before the output is rendered. Any changes made to the state of the control in the prerender phase can be saved, while changes made in the rendering phase are lost. | PreRender event (OnPreRender method) |
| Save state | The ViewState property of a control is automatically persisted to a string object after this stage. This string object is sent to the client and back as a hidden variable. For improving efficiency, a control can override the SaveViewState method to modify the ViewState property. | SaveViewState method |
| Render | Generate output to be rendered to the client. | Render method |
| Dispose | Perform any final cleanup before the control is torn down. References to expensive resources such as database connections must be released in this phase. | Dispose method |
| Unload | Perform any final cleanup before the control is torn down. Control authors generally perform cleanup in Dispose and do not handle this event. | UnLoad event (On UnLoad method) |
If none of the existing ASP.NET server controls meet the specific
requirements of your applications, you can create either a Web user control or
a Web custom control that encapsulates the functionality you need. The main
difference between the two controls lies in ease of creation vs. ease of use
at design time.
Web user controls are easy to make, but they can be less convenient
to use in advanced scenarios. You develop Web user controls almost exactly the
same way that you develop Web Forms pages. Like Web Forms, user controls can
be created in the visual designer, they can be written with code separated
from the HTML, and they can handle execution events. However, because Web user
controls are compiled dynamically at run time they cannot be added to the
Toolbox, and they are represented by a simple placeholder glyph when added to
a page. This makes Web user controls harder to use if you are accustomed to
full Visual Studio .NET design-time support, including the Properties window
and Design view previews. Also, the only way to share the user control between
applications is to put a separate copy in each application, which takes more
maintenance if you make changes to the control.
Web custom controls are compiled code, which makes them easier to
use but more difficult to create; Web custom controls must be authored in
code. Once you have created the control, however, you can add it to the
Toolbox and display it in a visual designer with full Properties window
support and all the other design-time features of ASP.NET server controls. In
addition, you can install a single copy of the Web custom control in the
global assembly cache and share it between applications, which makes
maintenance easier.
| Web user controls | Web custom controls |
|---|---|
| Easier to create | Harder to create |
| Limited support for consumers who use a visual design tool | Full visual design tool support for consumers |
| A separate copy of the control is required in each application | Only a single copy of the control is required, in the global assembly cache |
| Cannot be added to the Toolbox in Visual Studio | Can be added to the Toolbox in Visual Studio |
| Good for static layout | Good for dynamic layout |
iisreset on the command line) and the session
state value will persist.
Which ASP.NET
configuration options are supported in the ASP.NET implementation on the
shared web hosting platform?
A: Many of the
ASP.NET configuration options are not configurable at the site, application or
subdirectory level on the shared hosting platform. Certain options can affect
the security, performance and stability of the server and, therefore cannot be
changed. The following settings are the only ones that can be changed in your
site’s web.config file (s):
browserCaps
clientTarget
pages
customErrors
globalization
authorization
authentication
webControls
webServices
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconaspnetconfiguration.asp
<authentication mode="Windows|Forms|Passport|None"><forms name="name" loginUrl="url" protection="All|None|Encryption|Validation" timeout="30" path="/" > requireSSL="true|false" slidingExpiration="true|false"><credentials passwordFormat="Clear|SHA1|MD5"><user name="username" password="password"/></credentials></forms><passport redirectUrl="internal"/></authentication>
| Attribute | Option | Description |
|---|---|---|
| mode | Controls the default authentication mode for an application. | |
| Windows | Specifies Windows authentication as the default authentication mode. Use this mode when using any form of Microsoft Internet Information Services (IIS) authentication: Basic, Digest, Integrated Windows authentication (NTLM/Kerberos), or certificates. | |
| Forms | Specifies ASP.NET forms-based authentication as the default authentication mode. | |
| Passport | Specifies Microsoft Passport authentication as the default authentication mode. | |
| None | Specifies no authentication. Only anonymous users are expected or applications can handle events to provide their own authentication. |
| VaryByParam value |
Description |
|
none |
One version of page cached (only raw GET) |
| * |
n versions of page cached based on query string and/or POST body |
| v1 |
n versions of page cached based on value of v1 variable in query string or POST body |
| v1;v2 | n versions of page cached based on value of v1 and v2 variables in query string or POST body |
| Off | Indicates that session state is not enabled. |
| Inproc | Indicates that session state is stored locally. |
| StateServer | Indicates that session state is stored on a remote server. |
| SQLServer | Indicates that session state is stored on the SQL Server. |
| ASP.NET Web Services | .NET Remoting | |
| Protocol | Can be accessed only over HTTP | Can be accessed over any protocol (including TCP, HTTP, SMTP and so on) |
| State Management | Web services work in a stateless environment | Provide support for both stateful and stateless environments through Singleton and SingleCall objects |
| Type System | Web services support only the datatypes defined in the XSD type system, limiting the number of objects that can be serialized. | Using binary communication, .NET Remoting can provide support for rich type system |
| Interoperability | Web services support interoperability across platforms, and are ideal for heterogeneous environments. | .NET remoting requires the client be built using .NET, enforcing homogenous environment. |
| Reliability | Highly reliable due to the fact that Web services are always hosted in IIS | Can also take advantage of IIS for fault isolation. If IIS is not used, application needs to provide plumbing for ensuring the reliability of the application. |
| Extensibility | Provides extensibility by allowing us to intercept the SOAP messages during the serialization and deserialization stages. | Very extensible by allowing us to customize the different components of the .NET remoting framework. |
| Ease-of-Programming | Easy-to-create and deploy. | Complex to program. |
System.Runtime.Serialization.Formatter.Binary
and
System.Runtime.Serialization.SOAPFormatter
and relies on .NET CLR Runtime assemblies for metadata.
Using the Trace Utility on the Server
To see all of a service's messages received from and sent to all clients,
perform the following steps on the server.
Using the Trace Utility on the Client
To see all messages sent to and received from a service, do the following
steps on the client.
(XML)
<?xml version="1.0"?>
<diffgr:diffgram
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"
xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<DataInstance>
</DataInstance>
<diffgr:before>
</diffgr:before>
<diffgr:errors>
</diffgr:errors>
</diffgr:diffgram>
The DiffGram format consists of the following blocks of data:
Areas for study
Assemblies, GAC (how to post private assembly to gac)
.net architecture, MSIL, CTS, CLR
Events, delegates (this is the basics of .net. u have to understand it very
well)
asp.net, webform, server controls, user controls
ado.net, dataset, datareader, dataadapter
remoting, webservice
desktop application - datagrid.
Threading