Explore topic-wise InterviewSolutions in Current Affairs.

Besides the Ajax Framework (which is the Ajax ENGINE) and Ajax Extensions (which CONTAIN the default Ajax controls), there is a toolkit called the Ajax Control Toolkit available for use & download (for free). This is a collection of rich FEATURED, highly INTERACTIVE controls, created as a joint venture between Microsoft & the DEVELOPER Community.

Besides the Ajax Framework (which is the Ajax engine) and Ajax Extensions (which contain the default Ajax controls), there is a toolkit called the Ajax Control Toolkit available for use & download (for free). This is a collection of rich featured, highly interactive controls, created as a joint venture between Microsoft & the Developer Community.

ASP.NET AJAX is a free FRAMEWORK to implement Ajax in asp.net web applications, for quickly creating efficient and INTERACTIVE Web applications that work across all popular browsers.

The Ajax Framework is powered with

1-Reusable Ajax Controls
2-Support for all modern browsers
3-Access remote services and data from the browser WITHOUT tons of complicated script.

Versions of Ajax release

1-ASP.NET Ajax Framework 1.0 (earlier release to this was called the ATLAS)
2-ASP.NET Ajax Framework 1.0 was available as a separate download for ASP.NET 2.0

ASP.NET AJAX is a free framework to implement Ajax in asp.net web applications, for quickly creating efficient and interactive Web applications that work across all popular browsers.

The Ajax Framework is powered with

1-Reusable Ajax Controls
2-Support for all modern browsers
3-Access remote services and data from the browser without tons of complicated script.

Versions of Ajax release

1-ASP.NET Ajax Framework 1.0 (earlier release to this was called the Atlas)
2-ASP.NET Ajax Framework 1.0 was available as a separate download for ASP.NET 2.0

AJAX REQUESTS should use an HTTP GET request while retrieving data where the data does not change for a given URL requested. An HTTP POST should be used when state is updated on the server. This is in line with HTTP idempotency recommendations and is HIGHLY recommended for a consistent web APPLICATION architecture.

AJAX requests should use an HTTP GET request while retrieving data where the data does not change for a given URL requested. An HTTP POST should be used when state is updated on the server. This is in line with HTTP idempotency recommendations and is highly recommended for a consistent web application architecture.

Call the __doPostBack function. ASP.NET runtime always CREATES a javascript function named __doPostBack(eventTarget, eventArgument) when the WEB PAGE is rendered. A control ID may be passed here to SPECIFICALLY invoke UPDATION of the UpdatePanel.

Call the __doPostBack function. ASP.NET runtime always creates a javascript function named __doPostBack(eventTarget, eventArgument) when the web page is rendered. A control ID may be passed here to specifically invoke updation of the UpdatePanel.

1)An Ajax WEB APPLICATION tends to confused end users if the network bandwidth is SLOW, because there is no full postback running. However, this confusion may be eliminated by using an UpdateProgress control in tandem.
2)Distributed applications running Ajax will need a CENTRAL mechanism for communicating with each other.

1)An Ajax Web Application tends to confused end users if the network bandwidth is slow, because there is no full postback running. However, this confusion may be eliminated by using an UpdateProgress control in tandem.
2)Distributed applications running Ajax will need a central mechanism for communicating with each other.

ASP.NET AJAX Futures

The new release includes support for managing browser history (Back button support), selecting ELEMENTS by CSS selectors or classes, and information on accessing “Astoria” Web data services. The Futures (July 2007) release adds:

History support for the Safari browser, inclusion of “titles”, encoding and encrypting of server-side history STATE and the ability to handle history in the client without a server requirement.

CSS Selectors APIs have been modified to be applicable to W3C recommendations.

A script resource extraction tool that allows you to CREATE script files on disk that originate from embedded resources in ASSEMBLIES. Important: this version of the browser history feature is now outdated and should not be used. Instead, please download the ASP.NET 3.5 Extensions Preview, which contains the new version.

ASP.NET AJAX Futures

The new release includes support for managing browser history (Back button support), selecting elements by CSS selectors or classes, and information on accessing “Astoria” Web data services. The Futures (July 2007) release adds:

History support for the Safari browser, inclusion of “titles”, encoding and encrypting of server-side history state and the ability to handle history in the client without a server requirement.

CSS Selectors APIs have been modified to be applicable to W3C recommendations.

A script resource extraction tool that allows you to create script files on disk that originate from embedded resources in assemblies. Important: this version of the browser history feature is now outdated and should not be used. Instead, please download the ASP.NET 3.5 Extensions Preview, which contains the new version.

Use the ScriptManager's AsyncPostBackTimeout Property.

For example, if you WANT to debug a web PAGE but you get an error that the page request has TIMED out, you may set <asp:scriptmanager id="ScriptManager1 " runat=" server" asyncpost backtimeout="9000 "&GT;</asp: SCRIPT manager>

where the value specified is in seconds.

Use the ScriptManager's AsyncPostBackTimeout Property.

For example, if you want to debug a web page but you get an error that the page request has timed out, you may set <asp:scriptmanager id="ScriptManager1 " runat=" server" asyncpost backtimeout="9000 "></asp: script manager>

where the value specified is in seconds.

An UpdatePanel has a property called UpdateMode. There are two possible values for this property:
1)Always
2)Conditional

If the UpdateMode property is set to "Always", the UpdatePanel control’s CONTENT is updated on each postback that starts from ANYWHERE on the webpage. This also includes asynchronous POSTBACKS from controls that are INSIDE other UpdatePanel controls, and postbacks from controls which are not inside UpdatePanel controls.

If the UpdateMode property is set to Conditional, the UpdatePanel control’s content is updated when one of the following is true:
1-When the postback is caused by a trigger for that UpdatePanel control.
2-When you explicitly call the UpdatePanel control's Update() method.
3-When the UpdatePanel control is nested inside another UpdatePanel control and the parent panel is updated.

When the ChildrenAsTriggers property is set to true and any CHILD control of the UpdatePanel control causes a postback. Child controls of nested UpdatePanel controls do not cause an update to the outer UpdatePanel control unless they are explicitly defined as triggers for the parent panel.

Controls defined inside a node have the capability to update the contents of an UpdatePanel.

If the ChildrenAsTriggers property is set to false and the UpdateMode property is set to Always, an exception is thrown. The ChildrenAsTriggers property is intended to be used only when the UpdateMode property is set to Conditional.

An UpdatePanel has a property called UpdateMode. There are two possible values for this property:
1)Always
2)Conditional

If the UpdateMode property is set to "Always", the UpdatePanel control’s content is updated on each postback that starts from anywhere on the webpage. This also includes asynchronous postbacks from controls that are inside other UpdatePanel controls, and postbacks from controls which are not inside UpdatePanel controls.

If the UpdateMode property is set to Conditional, the UpdatePanel control’s content is updated when one of the following is true:
1-When the postback is caused by a trigger for that UpdatePanel control.
2-When you explicitly call the UpdatePanel control's Update() method.
3-When the UpdatePanel control is nested inside another UpdatePanel control and the parent panel is updated.

When the ChildrenAsTriggers property is set to true and any child control of the UpdatePanel control causes a postback. Child controls of nested UpdatePanel controls do not cause an update to the outer UpdatePanel control unless they are explicitly defined as triggers for the parent panel.

Controls defined inside a node have the capability to update the contents of an UpdatePanel.

If the ChildrenAsTriggers property is set to false and the UpdateMode property is set to Always, an exception is thrown. The ChildrenAsTriggers property is intended to be used only when the UpdateMode property is set to Conditional.

When a script is registered by the ScriptManager class, a type/key pair is created to uniquely identify the script.

For identification PURPOSES, the type/key pair name is ALWAYS UNIQUE for dentifying a script. HENCE, there may be no DUPLICATION in type/key pair names.

When a script is registered by the ScriptManager class, a type/key pair is created to uniquely identify the script.

For identification purposes, the type/key pair name is always unique for dentifying a script. Hence, there may be no duplication in type/key pair names.

For all three, a script ELEMENT is rendered after the opening form tag. Following are the differences:
1-RegisterClientScriptBlock - The script is specified as a string parameter.
2-RegisterClientScriptInclude - The script CONTENT is specified by setting the SRC attribute to a URL that points to a script file.
3-RegisterClientScriptResource - The script content is specified with a resource NAME in an assembly. The src attribute is automatically POPULATED with a URL by a call to an HTTP handler that retrieves the named script from the assembly.

For all three, a script element is rendered after the opening form tag. Following are the differences:
1-RegisterClientScriptBlock - The script is specified as a string parameter.
2-RegisterClientScriptInclude - The script content is specified by setting the src attribute to a URL that points to a script file.
3-RegisterClientScriptResource - The script content is specified with a resource name in an assembly. The src attribute is automatically populated with a URL by a call to an HTTP handler that retrieves the named script from the assembly.

No. It is not POSSIBLE to use multiple ScriptManager CONTROL in a web page. In FACT, any such requirement NEVER comes in because a single ScriptManager control is enough to handle the objects of a web page.

No. It is not possible to use multiple ScriptManager control in a web page. In fact, any such requirement never comes in because a single ScriptManager control is enough to handle the objects of a web page.

Yes. But this has to be done before the INIT EVENT of the page (or during RUNTIME after the page has already loaded). OTHERWISE an InvalidOperationException will be THROWN.

Yes. But this has to be done before the init event of the page (or during runtime after the page has already loaded). Otherwise an InvalidOperationException will be thrown.

ScriptManager class is the heart of ASP.NET Ajax. Before elaborating more on ScriptManager, note that ScriptManager is class and a control (both) in Ajax.

The ScriptManager class in ASP.NET manages Ajax Script Libraries, partial page rendering functionality and client proxy class generation for web applications and services. By saying client proxy class, this means an instance of the Ajax runtime is created on the browser.

This class is defined in the System.Web.Extensions.dll. You will find this DLL in your system's Global Assembly Cache at C:\Windows\Assembly (For XP)

The ScriptManager control (that we may drag on a web form) is actually an instance of the ScriptManager class that we PUT on a web page. The ScriptManager manages all the ASP.NET Ajax controls on a web page. Following tasks are taken care by the ScriptManager class:
1 - Managing all resources (all objects/controls) on a web page
2 - Managing partial page updates
3 - Download Ajax Script Library to the client (means to the browser). This needs to happen so that Ajax engine is accessible to the browsers javascript code.
4 - Interacting with UpdatePanel Control, UpdateProgress Control.
5 - REGISTER script (using RegisterClientScriptBlock)
6 - Information whether Release OR Debug script is sent to the browser
7 - Providing access to Web service methods from the script by registering Web services with the ScriptManager control
8 - Providing access to ASP.NET authentication, role, and profile application services from client script after registering these services with the ScriptManager control
9 - Enable culture specific display of clientside script.
10 - Register server controls that implement IExtenderControl and IScriptControl interfaces.

ScriptManager class' EnablePartialRendering property is true by DEFAULT.

ScriptManager class is the heart of ASP.NET Ajax. Before elaborating more on ScriptManager, note that ScriptManager is class and a control (both) in Ajax.

The ScriptManager class in ASP.NET manages Ajax Script Libraries, partial page rendering functionality and client proxy class generation for web applications and services. By saying client proxy class, this means an instance of the Ajax runtime is created on the browser.

This class is defined in the System.Web.Extensions.dll. You will find this DLL in your system's Global Assembly Cache at C:\Windows\Assembly (For XP)

The ScriptManager control (that we may drag on a web form) is actually an instance of the ScriptManager class that we put on a web page. The ScriptManager manages all the ASP.NET Ajax controls on a web page. Following tasks are taken care by the ScriptManager class:
1 - Managing all resources (all objects/controls) on a web page
2 - Managing partial page updates
3 - Download Ajax Script Library to the client (means to the browser). This needs to happen so that Ajax engine is accessible to the browsers javascript code.
4 - Interacting with UpdatePanel Control, UpdateProgress Control.
5 - Register script (using RegisterClientScriptBlock)
6 - Information whether Release OR Debug script is sent to the browser
7 - Providing access to Web service methods from the script by registering Web services with the ScriptManager control
8 - Providing access to ASP.NET authentication, role, and profile application services from client script after registering these services with the ScriptManager control
9 - Enable culture specific display of clientside script.
10 - Register server controls that implement IExtenderControl and IScriptControl interfaces.

ScriptManager class' EnablePartialRendering property is true by default.

For concurrent requests, declare separate XmlHttpRequest objects for each request. For example, for request to get data from an SQL table1, use something LIKE this...
xmlHttpObject1.Onreadystatechange = functionfromTable1();
and to get data from ANOTHER table (say table2) at the same time, use
xmlHttpObject2.Onreadystatechange = functionfromTable2();
OFCOURSE, the XmlHttpObject needs to be opened &AMP; parameters passed too, like as shown below...
xmlHTTPObject1.open("GET","http://"localhost// " + "Website1/ Default1.aspx" true);
Note that the last parameter "true" used above means that processing shall carry on WITHOUT waiting for any response from the web server. If it is false, the function shall wait for a response.

For concurrent requests, declare separate XmlHttpRequest objects for each request. For example, for request to get data from an SQL table1, use something like this...
xmlHttpObject1.Onreadystatechange = functionfromTable1();
and to get data from another table (say table2) at the same time, use
xmlHttpObject2.Onreadystatechange = functionfromTable2();
Ofcourse, the XmlHttpObject needs to be opened & parameters passed too, like as shown below...
xmlHTTPObject1.open("GET","http://"localhost// " + "Website1/ Default1.aspx" true);
Note that the last parameter "true" used above means that processing shall carry on without waiting for any response from the web server. If it is false, the function shall wait for a response.

Dojo is a third-party javascript toolkit for creating rich featured applications. Dojo is an Open Source DHTML toolkit written in JavaScript. It builds on several CONTRIBUTED code bases (nWidgets, Burstlib, f(m)), which is why we REFER to it sometimes as a "unified" toolkit. Dojo aims to solve some long-standing HISTORICAL problems with DHTML which prevented mass adoption of dynamic WEB APPLICATION development.

Dojo is a third-party javascript toolkit for creating rich featured applications. Dojo is an Open Source DHTML toolkit written in JavaScript. It builds on several contributed code bases (nWidgets, Burstlib, f(m)), which is why we refer to it sometimes as a "unified" toolkit. Dojo aims to solve some long-standing historical problems with DHTML which prevented mass adoption of dynamic web application development.

The ASP.NET Ajax Extensions are set of Ajax-based controls that work in ASP.NET 2 (or above) based applications.

OFCOURSE,they also need the Ajax RUNTIME which is actually the Ajax Framework 1.0.

ASP.NET Ajax Extensions 1.0 have to be downloaded to run with ASP.NET 2.0

The new ASP.NET 3.5 Framework comes with the Ajax Library 3.5 (containing the Ajax Extensions 3.5). So in ORDER to use the LATEST Ajax, simply download .NET 3.5 Framework.

 Summary:
ASP.NET Ajax Extensions 1.0 -> For ASP.NET 2.0
ASP.NET Ajax Extensions 3.5 -> For ASP.NET 3.5

The ASP.NET Ajax Extensions are set of Ajax-based controls that work in ASP.NET 2 (or above) based applications.

Ofcourse,they also need the Ajax runtime which is actually the Ajax Framework 1.0.

ASP.NET Ajax Extensions 1.0 have to be downloaded to run with ASP.NET 2.0

The new ASP.NET 3.5 Framework comes with the Ajax Library 3.5 (containing the Ajax Extensions 3.5). So in order to use the latest Ajax, simply download .NET 3.5 Framework.

 Summary:
ASP.NET Ajax Extensions 1.0 -> For ASP.NET 2.0
ASP.NET Ajax Extensions 3.5 -> For ASP.NET 3.5

INTERNET Explorer 5.0+, SAFARI 1.2, MOZILLA 1.0/Firefox, Opera 8.0 +, NETSCAPE 7

Internet Explorer 5.0+, Safari 1.2, Mozilla 1.0/Firefox, Opera 8.0 +, Netscape 7

YES, AJAX is a technology INDEPENDENT of web SERVER the web application is hosted on. Ajax is a CLIENT (browser) technology.

Yes, AJAX is a technology independent of web server the web application is hosted on. Ajax is a client (browser) technology.

YES. This is POSSIBLE USING REMOTE SCRIPTS.

Yes. This is possible using remote scripts.

Here is a SELECTION of new FEATURES in the .NET 2.0 class LIBRARY:
•Generic collections in the System.Collections.Generic namespace.
•The System.Nullable type. (Note that C# has special SYNTAX for this type, e.g. int? is equivalent to Nullable)
•The GZipStream and DeflateStream classes in the System.IO.Compression namespace.
•The Semaphore class in the System.Threading namespace.
•Wrappers for DPAPI in the form of the ProtectedData and Protected Memory classes in the System. Security. Cryptography namespace.
•The IPC REMOTING channel in the System. Runtime. Remoting. Channels.Ipc namespace, for optimised intra-machine communication. 

Here is a selection of new features in the .NET 2.0 class library:
•Generic collections in the System.Collections.Generic namespace.
•The System.Nullable type. (Note that C# has special syntax for this type, e.g. int? is equivalent to Nullable)
•The GZipStream and DeflateStream classes in the System.IO.Compression namespace.
•The Semaphore class in the System.Threading namespace.
•Wrappers for DPAPI in the form of the ProtectedData and Protected Memory classes in the System. Security. Cryptography namespace.
•The IPC remoting channel in the System. Runtime. Remoting. Channels.Ipc namespace, for optimised intra-machine communication. 

GENERICS, ANONYMOUS methods, partial CLASSES, iterators, property visibility (SEPARATE visibility for get and set) and STATIC classes. 

Generics, anonymous methods, partial classes, iterators, property visibility (separate visibility for get and set) and static classes. 

64-bit (x64) versions of Windows support both 32-bit and 64-bit processes, and corresponding 32-bit and 64-bit versions of .NET 2.0. (.NET 1.1 is 32-bit only)..NET 1.x apps automatically run as 32-bit processes on 64-bit Windows..NET 2.0 apps can either run as 32-bit processes or as 64-bit processes. The OS decides which to use BASED on the PE header of the executable. The flags in the PE header are controlled via the compiler /PLATFORM switch, which allows the TARGET of the app to be SPECIFIED as 'x86', 'x64' or 'any cpu'. Normally you specify 'any cpu', and your app will run as 32-bit on 32-bit Windows and 64-bit on 64-bit Windows. However if you have some 32-bit native code in your app (loaded via COM interop, for example), you will need to specify 'x86', which will force 64-bit Windows to LOAD your app in a 32-bit process. You can also tweak the 32-bit flag in the PE header using the SDK corflags utility. 

64-bit (x64) versions of Windows support both 32-bit and 64-bit processes, and corresponding 32-bit and 64-bit versions of .NET 2.0. (.NET 1.1 is 32-bit only)..NET 1.x apps automatically run as 32-bit processes on 64-bit Windows..NET 2.0 apps can either run as 32-bit processes or as 64-bit processes. The OS decides which to use based on the PE header of the executable. The flags in the PE header are controlled via the compiler /platform switch, which allows the target of the app to be specified as 'x86', 'x64' or 'any cpu'. Normally you specify 'any cpu', and your app will run as 32-bit on 32-bit Windows and 64-bit on 64-bit Windows. However if you have some 32-bit native code in your app (loaded via COM interop, for example), you will need to specify 'x86', which will force 64-bit Windows to load your app in a 32-bit process. You can also tweak the 32-bit flag in the PE header using the SDK corflags utility. 

Each INSTANCE of a reference TYPE has two fields MAINTAINED by the runtime - a method table pointer and a sync block. These are 4 bytes each on a 32-bit system, making a total of 8 bytes per object OVERHEAD. Obviously the instance data for the type must be added to this to get the overall size of the object. So, for example, instances of the following class are 12 bytes each:
class MyInt
{
...
private int x;
}
However, note that with the current implementation of the CLR there seems to be a minimum object size of 12 bytes, even for classes with no data (e.g. System.Object). Values TYPES have no equivalent overhead.

Each instance of a reference type has two fields maintained by the runtime - a method table pointer and a sync block. These are 4 bytes each on a 32-bit system, making a total of 8 bytes per object overhead. Obviously the instance data for the type must be added to this to get the overall size of the object. So, for example, instances of the following class are 12 bytes each:
class MyInt
{
...
private int x;
}
However, note that with the current implementation of the CLR there seems to be a minimum object size of 12 bytes, even for classes with no data (e.g. System.Object). Values types have no equivalent overhead.

An EVENT is just a wrapper for a multicast delegate. Adding a public event to a class is almost the same as adding a public multicast delegate field. In both cases, subscriber objects can register for notifications, and in both cases the publisher object can SEND notifications to the subscribers. HOWEVER, a public multicast delegate has the undesirable property that external objects can invoke the delegate, something we'd normally want to RESTRICT to the publisher. Hence events - an event adds public methods to the containing class to add and remove receivers, but does not make the invocation mechanism public. See this post by Julien COUVREUR for more discussion.

An event is just a wrapper for a multicast delegate. Adding a public event to a class is almost the same as adding a public multicast delegate field. In both cases, subscriber objects can register for notifications, and in both cases the publisher object can send notifications to the subscribers. However, a public multicast delegate has the undesirable property that external objects can invoke the delegate, something we'd normally want to restrict to the publisher. Hence events - an event adds public methods to the containing class to add and remove receivers, but does not make the invocation mechanism public. See this post by Julien Couvreur for more discussion.

.NET remoting involves sending messages along channels. Two of the standard channels are HTTP and TCP. TCP is intended for LANs only-HTTP can be used for LANs or WANs (internet). Support is provided for multiple message serializarion formats. Examples are SOAP (XML-based) and binary. By default, the HTTP channel uses SOAP (via the .NET runtime Serialization SOAP Formatter), and the TCP channel uses binary (via the .NET runtime Serialization Binary Formatter). But EITHER channel can use either serialization format.

There are a NUMBER of styles of remote access:

•SingleCall. Each incoming REQUEST from a client is serviced by a new object. The object is thrown away when the request has finished.
•Singleton. All incoming requests from clients are processed by a single server object.
•Client-activated object. This is the old stateful (D)COM model whereby the client receives a reference to the remote object and holds that reference (thus keeping the remote object alive) until it is finished with it.

Distributed garbage collection of objects is managed by a system called 'leased based LIFETIME'. Each object has a lease time, and when that time expires the object is disconnected from the .NET runtime remoting infrastructure. Objects have a default renew time - the lease is renewed when a successful call is made from the client to the object. The client can also explicitly renew the lease.If you're INTERESTED in using XML-RPC as an alternative to SOAP, take a look at Charles Cook's XML-RPC.Net.

.NET remoting involves sending messages along channels. Two of the standard channels are HTTP and TCP. TCP is intended for LANs only-HTTP can be used for LANs or WANs (internet). Support is provided for multiple message serializarion formats. Examples are SOAP (XML-based) and binary. By default, the HTTP channel uses SOAP (via the .NET runtime Serialization SOAP Formatter), and the TCP channel uses binary (via the .NET runtime Serialization Binary Formatter). But either channel can use either serialization format.

There are a number of styles of remote access:

•SingleCall. Each incoming request from a client is serviced by a new object. The object is thrown away when the request has finished.
•Singleton. All incoming requests from clients are processed by a single server object.
•Client-activated object. This is the old stateful (D)COM model whereby the client receives a reference to the remote object and holds that reference (thus keeping the remote object alive) until it is finished with it.

Distributed garbage collection of objects is managed by a system called 'leased based lifetime'. Each object has a lease time, and when that time expires the object is disconnected from the .NET runtime remoting infrastructure. Objects have a default renew time - the lease is renewed when a successful call is made from the client to the object. The client can also explicitly renew the lease.If you're interested in using XML-RPC as an alternative to SOAP, take a look at Charles Cook's XML-RPC.Net.

Log4net is a port of the ESTABLISHED log4j Java LOGGING COMPONENT.

Log4net is a port of the established log4j Java logging component.

Yes. The Debug and Trace classes both have a Listeners property, which is a collection of sinks that receive the tracing that you send VIA Debug.WriteLine and Trace.WriteLine respectively. By default the Listeners collection contains a SINGLE sink, which is an instance of the DefaultTraceListener class. This sends output to the Win32 OutputDebugString() function and also the System.Diagnostics.Debugger.Log() method. This is useful when debugging, but if you're trying to trace a problem at a customer site, redirecting the output to a file is more appropriate. Fortunately, the TextWriterTraceListener class is provided for this purpose.Here's how to use the Text Writer Trace Listener class to redirect Trace output to a file:

Trace.Listeners.Clear();
FileStream fs = new FileStream( @"c:\log.txt", FileMode. Create, FileAccess.Write);
Trace.Listeners.Add( new TextWriterTraceListener( fs ));
Trace.WriteLine( @"This will be writen to c:\log.txt!" );
Trace.Flush();

Note the use of Trace.Listeners.Clear() to remove the default listener. If you don't do this, the output will GO to the file and OutputDebugString(). Typically this is not what you want, because OutputDebugString() IMPOSES a big performance HIT.

Yes. The Debug and Trace classes both have a Listeners property, which is a collection of sinks that receive the tracing that you send via Debug.WriteLine and Trace.WriteLine respectively. By default the Listeners collection contains a single sink, which is an instance of the DefaultTraceListener class. This sends output to the Win32 OutputDebugString() function and also the System.Diagnostics.Debugger.Log() method. This is useful when debugging, but if you're trying to trace a problem at a customer site, redirecting the output to a file is more appropriate. Fortunately, the TextWriterTraceListener class is provided for this purpose.Here's how to use the Text Writer Trace Listener class to redirect Trace output to a file:

Trace.Listeners.Clear();
FileStream fs = new FileStream( @"c:\log.txt", FileMode. Create, FileAccess.Write);
Trace.Listeners.Add( new TextWriterTraceListener( fs ));
Trace.WriteLine( @"This will be writen to c:\log.txt!" );
Trace.Flush();

Note the use of Trace.Listeners.Clear() to remove the default listener. If you don't do this, the output will go to the file and OutputDebugString(). Typically this is not what you want, because OutputDebugString() imposes a big performance hit.

Yes, in the System.Diagnostics namespace. There are two main classes that deal with tracing - Debug and Trace. They both work in a similar WAY - the DIFFERENCE is that tracing from the Debug class only works in builds that have the DEBUG SYMBOL defined, whereas tracing from the Trace class only works in builds that have the TRACE symbol defined. Typically this MEANS that you should use System.Diagnostics.Trace.WriteLine for tracing that you WANT to work in debug and release builds, and System. Diagnostics. Debug. WriteLine for tracing that you want to work only in debug builds.

Yes, in the System.Diagnostics namespace. There are two main classes that deal with tracing - Debug and Trace. They both work in a similar way - the difference is that tracing from the Debug class only works in builds that have the DEBUG symbol defined, whereas tracing from the Trace class only works in builds that have the TRACE symbol defined. Typically this means that you should use System.Diagnostics.Trace.WriteLine for tracing that you want to work in debug and release builds, and System. Diagnostics. Debug. WriteLine for tracing that you want to work only in debug builds.

Maybe, but be careful. ReaderWriterLock is USED to allow multiple threads to read from a data source, while still granting exclusive ACCESS to a single writer THREAD. This makes sense for data access that is mostly read-only, but there are some caveats. First, ReaderWriterLock is relatively poor performing compared to Monitor. Enter/Exit, which offsets some of the benefits. Second, you need to be very sure that the data structures you are accessing fully support multithreaded read access. Finally, there is APPARENTLY a bug in the v1.1 Reader Writer Lock that can cause starvation for writers when there are a large number of readers. IAN Griffiths has some interesting discussion on Reader Writer Lock here and here.

Maybe, but be careful. ReaderWriterLock is used to allow multiple threads to read from a data source, while still granting exclusive access to a single writer thread. This makes sense for data access that is mostly read-only, but there are some caveats. First, ReaderWriterLock is relatively poor performing compared to Monitor. Enter/Exit, which offsets some of the benefits. Second, you need to be very sure that the data structures you are accessing fully support multithreaded read access. Finally, there is apparently a bug in the v1.1 Reader Writer Lock that can cause starvation for writers when there are a large number of readers. Ian Griffiths has some interesting discussion on Reader Writer Lock here and here.

There is no way to query the THREAD POOL for this information. You must put code into the WaitCallback method to signal that it has COMPLETED. Events are useful for this.

There is no way to query the thread pool for this information. You must put code into the WaitCallback method to signal that it has completed. Events are useful for this.

There are SEVERAL options. First, you can use your own COMMUNICATION mechanism to tell the ThreadStart method to finish. Alternatively the Thread class has in-built support for instructing the thread to stop. The two principle methods are Thread.Interrupt() and Thread.Abort(). The former will cause a Thread Interrupted Exception to be thrown on the thread when it next goes into a WaitJoinSleep state. In other WORDS, Thread.Interrupt is a polite way of asking the thread to stop when it is no longer doing any useful work. In contrast, Thread.Abort() throws a ThreadAbortException regardless of what the thread is doing. Furthermore, the ThreadAbortException cannot NORMALLY be caught (THOUGH the ThreadStart's finally method will be executed). Thread.Abort() is a heavy-handed mechanism which should not normally be required.

There are several options. First, you can use your own communication mechanism to tell the ThreadStart method to finish. Alternatively the Thread class has in-built support for instructing the thread to stop. The two principle methods are Thread.Interrupt() and Thread.Abort(). The former will cause a Thread Interrupted Exception to be thrown on the thread when it next goes into a WaitJoinSleep state. In other words, Thread.Interrupt is a polite way of asking the thread to stop when it is no longer doing any useful work. In contrast, Thread.Abort() throws a ThreadAbortException regardless of what the thread is doing. Furthermore, the ThreadAbortException cannot normally be caught (though the ThreadStart's finally method will be executed). Thread.Abort() is a heavy-handed mechanism which should not normally be required.

Yes. ATL will continue to be VALUABLE for writing COM COMPONENTS for some time, but it has no PLACE in the .NET world.

Yes. ATL will continue to be valuable for writing COM components for some time, but it has no place in the .NET world.

Yes. .NET COMPONENTS are accessed from COM via a COM Callable Wrapper (CCW). This is similar to a RCW (SEE previous question), but works in the opposite direction. Again, if the wrapper cannot be automatically generated by the .NET DEVELOPMENT tools, or if the automatic BEHAVIOUR is not desirable, a custom CCW can be developed. Also, for COM to 'see' the .NET component, the .NET component must be registered in the registry.

Yes. .NET components are accessed from COM via a COM Callable Wrapper (CCW). This is similar to a RCW (see previous question), but works in the opposite direction. Again, if the wrapper cannot be automatically generated by the .NET development tools, or if the automatic behaviour is not desirable, a custom CCW can be developed. Also, for COM to 'see' the .NET component, the .NET component must be registered in the registry.

Yes. COM components are accessed from the .NET runtime via a Runtime Callable Wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM component into .NET-compatible interfaces. For oleautomation interfaces, the RCW can be GENERATED automatically from a type library. For non-oleautomation interfaces, it MAY be necessary to DEVELOP a custom RCW which manually maps the types exposed by the COM INTERFACE to .NET-compatible types.

Yes. COM components are accessed from the .NET runtime via a Runtime Callable Wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM component into .NET-compatible interfaces. For oleautomation interfaces, the RCW can be generated automatically from a type library. For non-oleautomation interfaces, it may be necessary to develop a custom RCW which manually maps the types exposed by the COM interface to .NET-compatible types.

Not immediately. The approach for .NET 1.0 was to provide access to the existing COM+ services (through an interop layer) rather than replace the services with native .NET ones. Various tools and ATTRIBUTES were provided to make this as painless as possible. Over time it is expected that interop will become more seamless - this may mean that some services become a core part of the CLR, and/or it may mean that some services will be REWRITTEN as MANAGED CODE which RUNS on top of the CLR.

Not immediately. The approach for .NET 1.0 was to provide access to the existing COM+ services (through an interop layer) rather than replace the services with native .NET ones. Various tools and attributes were provided to make this as painless as possible. Over time it is expected that interop will become more seamless - this may mean that some services become a core part of the CLR, and/or it may mean that some services will be rewritten as managed code which runs on top of the CLR.

PRETTY much, for .NET developers. The .NET Framework has a NEW remoting MODEL which is not based on DCOM. DCOM was pretty much dead anyway, once firewalls became widespread and Microsoft got SOAP fever. Of course DCOM will still be used in interop scenarios.

Pretty much, for .NET developers. The .NET Framework has a new remoting model which is not based on DCOM. DCOM was pretty much dead anyway, once firewalls became widespread and Microsoft got SOAP fever. Of course DCOM will still be used in interop scenarios.

 .NET has its own mechanisms for type interaction, and they don't USE COM. No IUnknown, no IDL, no typelibs, no registry-based activation. This is mostly GOOD, as a lot of COM was ugly. Generally speaking, .NET allows you to package and use components in a SIMILAR way to COM, but MAKES the whole thing a bit easier.

 .NET has its own mechanisms for type interaction, and they don't use COM. No IUnknown, no IDL, no typelibs, no registry-based activation. This is mostly good, as a lot of COM was ugly. Generally speaking, .NET allows you to package and use components in a similar way to COM, but makes the whole thing a bit easier.

Yes. A COUPLE of SIMPLE examples are that you can THROW EXCEPTIONS that are not DERIVED from System.Exception, and you can have non-zero-based arrays.

Yes. A couple of simple examples are that you can throw exceptions that are not derived from System.Exception, and you can have non-zero-based arrays.

You can buy an IL obfuscation tool. These TOOLS work by 'optimising' the IL in such a WAY that reverse-engineering becomes much more difficult
Of COURSE if you are writing WEB services then reverse-engineering is not a problem as clients do not have access to your IL.

You can buy an IL obfuscation tool. These tools work by 'optimising' the IL in such a way that reverse-engineering becomes much more difficult
Of course if you are writing web services then reverse-engineering is not a problem as clients do not have access to your IL.

Yes, it is often RELATIVELY straightforward to REGENERATE high-level source from IL. Lutz Roeder'sReflector does a very good job of turning IL into C# or VB.NET.

Yes, it is often relatively straightforward to regenerate high-level source from IL. Lutz Roeder'sReflector does a very good job of turning IL into C# or VB.NET.

YES. MS SUPPLY a tool called Ildasm that can be used to view the metadata and IL for an assembly.

Yes. MS supply a tool called Ildasm that can be used to view the metadata and IL for an assembly.

YES, as LONG as you are an ADMINISTRATOR. Just RUN:
CASPOL -s off

Yes, as long as you are an administrator. Just run:
caspol -s off

Caspol has a couple of OPTIONS that might HELP. First, you can ask caspol to tell you what code group an ASSEMBLY belongs to, using caspol -rsg. SIMILARLY, you can ask what permissions are being applied to a particular assembly using caspol -rsp

Caspol has a couple of options that might help. First, you can ask caspol to tell you what code group an assembly belongs to, using caspol -rsg. Similarly, you can ask what permissions are being applied to a particular assembly using caspol -rsp

LOOK at the InnerException PROPERTY of the exception that is THROWN to get a more SPECIFIC error message.

Look at the InnerException property of the exception that is thrown to get a more specific error message.

It depends. XmlSerializer has severe limitations such as the requirement that the target class has a parameterless constructor, and only public read/write PROPERTIES and fields can be serialized. However, on the plus side, XmlSerializer has good support for customising the XML document that is produced or consumed. XmlSerializer's features mean that it is most suitable for cross-platform WORK, or for constructing objects from existing XML documents.

SoapFormatter and BinaryFormatter have fewer limitations than XmlSerializer. They can SERIALIZE private fields, for example. However they both require that the target class be marked with the [Serializable] attribute, so like XmlSerializer the class needs to be written with serialization in mind. Also there are some quirks to WATCH out for - for example on deserialization the constructor of the new object is not invoked.

The choice between SoapFormatter and BinaryFormatter depends on the application.

BinaryFormatter makes sense where both serialization and deserialization will be performed on the .NET platform and where performance is important. SoapFormatter generally makes more sense in all other CASES, for ease of debugging if nothing else.

It depends. XmlSerializer has severe limitations such as the requirement that the target class has a parameterless constructor, and only public read/write properties and fields can be serialized. However, on the plus side, XmlSerializer has good support for customising the XML document that is produced or consumed. XmlSerializer's features mean that it is most suitable for cross-platform work, or for constructing objects from existing XML documents.

SoapFormatter and BinaryFormatter have fewer limitations than XmlSerializer. They can serialize private fields, for example. However they both require that the target class be marked with the [Serializable] attribute, so like XmlSerializer the class needs to be written with serialization in mind. Also there are some quirks to watch out for - for example on deserialization the constructor of the new object is not invoked.

The choice between SoapFormatter and BinaryFormatter depends on the application.

BinaryFormatter makes sense where both serialization and deserialization will be performed on the .NET platform and where performance is important. SoapFormatter generally makes more sense in all other cases, for ease of debugging if nothing else.

The lapsed listener problem is ONE of the primary causes of leaks in .NET applications. It occurs when a subscriber (or 'listener') signs up for a publisher's event, but fails to unsubscribe. The failure to unsubscribe means that the publisher maintains a reference to the subscriber as long as the publisher is alive. For some publishers, this MAY be the duration of the application.

This situation causes two problems. The obvious problem is the leakage of the subscriber object. The other problem is the PERFORMANCE degredation due to the publisher sending redundant notifications to 'zombie' SUBSCRIBERS.

There are at least a couple of solutions to the problem. The simplest is to make sure the subscriber is unsubscribed from the publisher, typically by adding an Unsubscribe() method to the subscriber. Another solution, documented here by Shawn Van Ness, is to CHANGE the publisher to use weak references in its subscriber list.

The lapsed listener problem is one of the primary causes of leaks in .NET applications. It occurs when a subscriber (or 'listener') signs up for a publisher's event, but fails to unsubscribe. The failure to unsubscribe means that the publisher maintains a reference to the subscriber as long as the publisher is alive. For some publishers, this may be the duration of the application.

This situation causes two problems. The obvious problem is the leakage of the subscriber object. The other problem is the performance degredation due to the publisher sending redundant notifications to 'zombie' subscribers.

There are at least a couple of solutions to the problem. The simplest is to make sure the subscriber is unsubscribed from the publisher, typically by adding an Unsubscribe() method to the subscriber. Another solution, documented here by Shawn Van Ness, is to change the publisher to use weak references in its subscriber list.

LOTS of interesting STATISTICS are EXPORTED from the .NET runtime VIA the '.NET CLR xxx' PERFORMANCE counters. Use Performance Monitor to view them.

Lots of interesting statistics are exported from the .NET runtime via the '.NET CLR xxx' performance counters. Use Performance Monitor to view them.

A LITTLE. For example the System.GC class exposes a Collect method, which forces the garbage collector to collect all unreferenced objects immediately.

Also there is a gcConcurrent SETTING that can be specified via the APPLICATION configuration FILE. This SPECIFIES whether or not the garbage collector performs some of its collection activities on a separate thread. The setting only applies on multi-processor machines, and defaults to true.

A little. For example the System.GC class exposes a Collect method, which forces the garbage collector to collect all unreferenced objects immediately.

Also there is a gcConcurrent setting that can be specified via the application configuration file. This specifies whether or not the garbage collector performs some of its collection activities on a separate thread. The setting only applies on multi-processor machines, and defaults to true.

This issue is a little more complex than it first appears. There are really two categories of class that REQUIRE deterministic destruction - the first category manipulate unmanaged types directly, whereas the second category manipulate managed types that require deterministic destruction. An example of the first category is a class with an IntPtr member representing an OS file handle. An example of the second category is a class with a System.IO.FileStream member.

For the first category, it makes sense to implement IDisposable and override Finalize. This allows the object user to 'do the right thing' by calling Dispose, but also provides a fallback of freeing the unmanaged resource in the Finalizer, should the calling code fail in its duty. However this logic does not apply to the second category of class, with only managed resources. In this case implementing Finalize is pointless, as managed member OBJECTS cannot be accessed in the Finalizer. This is because there is no GUARANTEE about the ORDERING of Finalizer execution. So only the Dispose method should be implemented. (If you think about it, it doesn't really make sense to call Dispose on member objects from a Finalizer anyway, as the member object's Finalizer will do the required cleanup.)

For classes that need to implement IDisposable and override Finalize, see Microsoft's documented pattern.

Note that some developers argue that implementing a Finalizer is always a bad idea, as it hides a bug in your code (i.e. the lack of a Dispose call). A less radical approach is to implement Finalize but include a Debug.Assert at the start, thus signalling the problem in DEVELOPER builds but allowing the cleanup to occur in release builds.

This issue is a little more complex than it first appears. There are really two categories of class that require deterministic destruction - the first category manipulate unmanaged types directly, whereas the second category manipulate managed types that require deterministic destruction. An example of the first category is a class with an IntPtr member representing an OS file handle. An example of the second category is a class with a System.IO.FileStream member.

For the first category, it makes sense to implement IDisposable and override Finalize. This allows the object user to 'do the right thing' by calling Dispose, but also provides a fallback of freeing the unmanaged resource in the Finalizer, should the calling code fail in its duty. However this logic does not apply to the second category of class, with only managed resources. In this case implementing Finalize is pointless, as managed member objects cannot be accessed in the Finalizer. This is because there is no guarantee about the ordering of Finalizer execution. So only the Dispose method should be implemented. (If you think about it, it doesn't really make sense to call Dispose on member objects from a Finalizer anyway, as the member object's Finalizer will do the required cleanup.)

For classes that need to implement IDisposable and override Finalize, see Microsoft's documented pattern.

Note that some developers argue that implementing a Finalizer is always a bad idea, as it hides a bug in your code (i.e. the lack of a Dispose call). A less radical approach is to implement Finalize but include a Debug.Assert at the start, thus signalling the problem in developer builds but allowing the cleanup to occur in release builds.

Yes. The garbage collector offers no guarantees about the time when an object will be destroyed and its MEMORY reclaimed.& There was an INTERESTING thread on the DOTNET list, started by CHRIS Sells, about the implications of non-deterministic destruction of OBJECTS in C#. In October 2000, Microsoft's Brian Harry posted a LENGTHY analysis of the problem. Chris Sells' response to Brian's posting is here.

Yes. The garbage collector offers no guarantees about the time when an object will be destroyed and its memory reclaimed.& There was an interesting thread on the DOTNET list, started by Chris Sells, about the implications of non-deterministic destruction of objects in C#. In October 2000, Microsoft's Brian Harry posted a lengthy analysis of the problem. Chris Sells' response to Brian's posting is here.