Basic Definitions

Garbage Collector: GC is responsible for collecting objects that are no longer referenced. (System.GC.Collect)

Finalize Method: The GC calls the Object.Finalize method immediately before it collects an object that is no longer referenced. (GC.SuppressFinalize)

Value and Reference Types: In value type actual data is stored in the variable on the stack whereas in reference type only a reference is stored in the variable. The actual data is stored on the heap.

Option Strict: Compiler must be able to determine the type of each variable.

Option Explicit: It ensures that variable name is declared.

Option Compare: It determines which strings should be compared as binary strings or if the array characters should be compared as text.

Boxing: It involves taking value that is on the stack and copying it to the heap.

Abstraction: Ability of a language to create “black-box” code. – To take a concept and create an abstract representation of that concept within a program.

Encapsulation: Ability to hide the internal implementation details of the code. It’s the concept of separation between interface and implementation.

Polymorphism: ability to process objects differently depending on their data type or class.

Inheritance: Ability to create new class that can be based on an existing class, inheriting its interface and functionality from the original class.

Early Binding: Compiler knows the object’s data type ahead of time.

Late Binding: Compiler doesn’t know about the data type of object ahead of time.

Delegates: There are times when it would be nice to be able to pass a procedure to a method. The classic case is when building a generic routine, where we not only need to provide the data to be sorted, but we need to provide a comparison routine appropriate for the specific data.

Virtual Methods: Virtual methods are those that can be overridden and replaced by subclasses.

Me: Provide reference of current object.

MyBase: Its provide reference of immediate parent class of the object.

Threading: In a single process there can be multiple execution points, this is known as Threading.

Deadlock: A deadlock occurs when each thread is waiting for the other to do something.

Marshaling: packaging and sending interface method calls across thread or process boundaries.

Proxy Stub: When a function's or interface methods parameters are marshaled across a process boundary, the stub is an interface-specific object that unpackages the marshaled parameters and calls the required method. The stub runs in the receiver's address space and communicates with a corresponding proxy in the sender's address space.

COM: COM is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is a technology that allows objects to interact across process and machine boundaries as easily as within a single process.

COM Interfaces: A COM interface refers to a predefined group of related functions that a COM class implements, but a specific interface does not necessarily represent all the functions that the class supports.

• A COM interface is not the same as a C++ class

• A COM interface is not an object—it is simply a related group of functions and is the binary standard through which clients and objects communicate. As long as it can provide pointers to interface methods, the object can be implemented in any language with any internal state representation.

• COM interfaces are strongly typed—every interface has its own interface identifier (a GUID), which eliminates the possibility of duplication that could occur with any other naming scheme.

• COM interfaces are immutable—you cannot define a new version of an old interface and give it the same identifier. Adding or removing methods of an interface or changing semantics creates a new interface, not a new version of an old interface. Therefore, a new interface cannot conflict with an old interface. However, objects can support multiple interfaces simultaneously.

COM Interface Pointer: The pointer to the interface function table (vtable) that another object must have to call its methods is called simply an interface pointer.

IUnknown and Interface Inheritance: Inheritance in COM does not mean code reuse. Because no implementations are associated with interfaces, interface inheritance does not mean code inheritance. It means only that the contract associated with an interface is inherited in a C++ pure-virtual base-class fashion and modified—either by adding new methods or by further qualifying the allowed usage of methods. There is no selective inheritance in COM. If one interface inherits from another, it includes all the methods that the other interface defines. All COM objects must implement the IUnknown interface because it provides the means, using QueryInterface, to move freely between the different interfaces that an object supports as well as the means to manage its lifetime by using AddRef and Release.

QueryInterface is the mechanism that allows clients to dynamically discover (at run time) whether or not an interface is supported by a component object.
IUnknown Methods Description
QueryInterface Returns pointers to supported interfaces.
AddRef Increments reference count.
Release Decrements reference count.

COM Threading Architecture: In general, the simplest way to view the COM threading architecture is to think of all the COM objects in the process as divided into groups called apartments. A COM object lives in exactly one apartment, in the sense that its methods can legally be directly called only by a thread that belongs to that apartment. Any other thread that wants to call the object must go through a proxy.

There are two types of apartments: single-threaded apartments, and multithreaded apartments.

Single-threaded Apartments—Single-threaded apartments consist of exactly one thread, so all COM objects that live in a single-threaded apartment can receive method calls only from the one thread that belongs to that apartment. All method calls to a COM object in a single-threaded apartment are synchronized with the windows message queue for the single-threaded apartment’s thread. A process with a single thread of execution is simply a special case of this model.

Multithreaded Apartments—Multithreaded apartments consist of one or more threads, so all COM objects that live in an multithreaded apartment can receive method calls directly from any of the threads that belong to the multithreaded apartment. Threads in a multithreaded apartment use a model called free-threading. Calls to COM objects in a multithreaded apartment are synchronized by the objects themselves.

A process can have zero or more single-threaded apartments and zero or one multithreaded apartment. The different types of processes can be defined as follows:
• A process that consists of just one single-threaded apartment is referred to as a single-threaded process.
• A process that has two or more single-threaded apartments and no multithreaded apartments is called an apartment model process.
• A process that has a multithreaded apartment and no single-threaded apartments is referred to as a free-threaded process.
• A process that has a multithreaded apartment and one or more single-threaded apartments is a mixed model process.


Object Pooling: Object pooling enable system to serve more clients than the number of object instances. COM+ automatically provides object pooling.
COM+ Transaction Types:
• Required: setting a component's transaction attribute to Required guarantees that COM+ must create each instance of that component in a transaction but doesn't necessarily start a new transaction.

• Supported: setting a component's transaction attribute to Supported can result in the new object being created in the calling object's transaction. All objects participating in the same transaction share a common transaction identifier, which COM+ reads from the object's context.

CLR (Common Language Runtime): CLR is runtime for all .NET languages. It is responsible for executing and managing all code written by any language that targets for the .NET Platform. It compiles code into MSIL(Intermediate Language), rather than machine code, the IL is just – in – time compiled before code is executed. CLR is basically replacement of Win32API and COM.
CLR Services:
• Garbage Collection
• Code Verification
• Code access security

Assembly: Assembly is a primary unit of .NET Application. It is self describing collection of code, resources and metadata. The assembly manifest contains information what is contained within the assembly. The assembly manifest provides
• Identity information, such as the name and version number of the assembly.
• A list of all types exposed by the assembly.
• A list of other assemblies required by the assembly.
• A list of code access security instructions for the assembly. This includes a list of permissions required by the assembly and permissions to be denied the assembly.

.NET Remoting (System.Runtime.Remoting): Microsoft® .NET remoting provides a framework that allows objects to interact with one another across application domains. All local objects that have to cross the application domain boundary have to be passed by value and should be marked with the [serializable] custom attribute, or they have to implement the ISerializable interface.

• When the object is passed as a parameter, the framework serial
izes the object and transports it to the destination application domain, where the object will be reconstructed. Local objects that cannot be serialized cannot be passed to a different application domain and are therefore nonremotable.
• When the object is passed as a parameter, the framework serializes the object and transports it to the destination application domain, where the object will be reconstructed. Local objects that cannot be serialized cannot be passed to a different application domain and are therefore nonremotable.
• proxy and remote objects are in different application domains, all method call parameters on the stack are converted into messages and transported to the remote application domain, where the messages are turned back into a stack frame and the method call is invoked. The same procedure is used for returning results from the method call.

Proxy Objects
Proxy objects are created when a client activates a remote object. The proxy object acts as a representative of the remote object and ensures that all calls made on the proxy are forwarded to the correct remote object instance. In order to understand exactly how proxy objects work, we need to examine them in more detail. When a client activates a remote object, the framework creates a local instance of the class TransparentProxy that contains a list of all classes, as well as interface methods of the remote object. Since the TransparentProxy class is registered with the CLR when it gets created, all method calls on the proxy are intercepted by the runtime. Here the call is examined to determine if it is a valid method of the remote object and if an instance of the remote object resides in the same application domain as the proxy. If this is true, a simple method call is routed to the actual object. If the object is in a different application domain, the call parameters on the stack are packaged into an IMessage object and forwarded to a RealProxy class by calling its Invoke method. This class (or rather an internal implementation of it) is responsible for forwarding messages to the remote object. Both the TransparentProxy and RealProxy classes are created under the covers when a remote object is activated, but only the TransparentProxy is returned to the client.

Registry Settings
DeleteSetting:Deletes a section or key setting from an application's entry in the registry.

GetSetting:Returns a key setting value from an application's entry in the registry.
GetAllSettings:Returns a list of key settings and their values from an application's entry in the registry.
SaveSetting:Creates or saves an application entry in the registry.

Try...Catch...Finally control structures test a piece of code and direct how the application should handle various categories of error. Each of the structure's three constituent parts plays a specific role in this process.
The Try statement provides the code that is being tested for exceptions.
• Catch clauses identify blocks of code that are associated with specific exceptions. A Catch When block directs the code to execute under specific circumstances. A Catch without a When clause reacts to any exception. Therefore, your code might hold a series of specific Catch...When statements, each reacting to a specific type of exception, followed by a general Catch block that reacts to any exceptions that have not been intercepted by the preceding Catch...When clauses.
• The Finally statement contains code that executes regardless of whether or not an exception occurs within the Try block. A Finally statement will execute even after an Exit Try or Exit Sub. This code often performs clean-up tasks, such as closing files or clearing buffers.
A Catch clause can take three possible forms: Catch, Catch...As, and Catch...When.
A Catch clause with no When keyword allows the associated statement block to handle any exception. Catch...As and Catch...When clauses catch a specific exception and allow the associated statement block to tell the application what to do. Catch...As and Catch...When clauses can also be combined in a single statement, such as Catch ex As Exception When intResult <> 0.
Handling Update Errors
When updating data, errors can occur from a variety of causes. For example, attempting to duplicate a primary key causes an error, as does attempting to update a database that has been modified by another user. Regardless of the source of the error, you must anticipate and plan for possible errors when updating rows.

Both SqlDataAdapters and OledbDataAdapters provide a RowUpdated event that fires after a row update has been attempted but before any exception has been thrown. You can write code in this event to handle any update errors that might occur without going through resource-intensive exception handling blocks.
The RowUpdated event provides an instance of SqlRowUpdatedEventArgs or OleDbRowUpdatedEventArgs, depending on the type of DataAdapter you are using. These event arguments provide information that can be used to determine the error that occurred and how to proceed.

DataRelation Objects
A DataRelation object represents a relationship between two columns of data in different tables. For example, you might have a Customers table and an Orders table, each of which contain a CustomerID column. Each customer would only be listed once in the Customers table, but might be listed multiple times in the Orders table. The CustomerID in the Orders table specifies which customer in the Customers table placed the order. Thus, the CustomerID field of the Orders table directly refers to a particular row of data in the Customers field and can be used as a key to retrieve that row. Likewise, the CustomerID column in the Customers table can be used to retrieve any relevant rows in the Orders table. This is an example of a one-to-many relationship, where a unique identifier in one table might indicate multiple rows in another table. It is the most common type of data relationship.
You can use a DataRelation object to create this kind of relationship between two tables in a DataSet. The DataRelation objects of a particular DataSet are contained in the Relations property of the DataSet. A DataRelation is created by specifying the name of the DataRelation, the parent column, and the child column.

• The key difference between ASP.NET Web services and .NET Remoting is in how they serialize data into messages and the format they choose for metadata.
• ASP.NET Web services rely on the System.Xml.Serialization.XmlSerializer class to marshal data to and from SOAP messages at runtime.
• .NET Remoting relies on the pluggable implementations of the IFormatter interface used by the System.Runtime.Serialization engine to marshal data to and from messages. There are two standard formatters, System.Runtime.Serialization.Formatters.Binary.BinaryFormatter and System.Runtime.Serialization.Formatters.Soap.SoapFormatter. The BinaryFormatter and SoapFormatter, as the names suggest, marshal types in binary and SOAP format respectively. For metadata, .NET Remoting relies on the common language runtime assemblies, which contain all the relevant information about the data types they implement, and expose it via reflection.

• The ASP.NET Web Services model assumes stateless service architecture by default; it does not inherently correlate multiple calls from the same user. In addition, each time a client invokes an ASP.NET Web service, a new object is created to service the request. The object is destroyed after the method call completes. To maintain state between requests, you can either use the same techniques used by ASP.NET pages, i.e., the Session and Application property bags, or you can implement your own custom solution.
• .NET Remoting supports a range of state management options and may or may not correlate multiple calls from the same user, depending on what object lifetime scheme you choose. SingleCall objects are stateless (like the objects used to invoke ASP.NET Web services), Singleton objects share state for all clients, and client-activated objects maintain state on a per-client basis (with all the associated scalability and reliability issues this raises).

• Single Call
Single Call objects service one and only one request coming in. Single Call objects are useful in scenarios where the objects are required to do a finite amount of work. Single Call objects are usually not required to store state information, and they cannot hold state information between method calls. However, Single Call objects can be configured in a load-balanced fashion.

• Singleton Objects
Singleton objects are those objects that service multiple clients and hence share data by storing state information between client invocations. They are useful in cases in which data needs to be shared explicitly between clients and also in which the overhead of creating and maintaining objects is substantial.

• Client-Activated Objects (CAO)
Client-activated objects (CAO) are server-side objects that are activated upon request from the client. This way of activating server objects is very similar to the classic COM class activation. When the client submits a request for a server object using "new" operator, an activation request message is sent to the remote application. The server then creates an instance of the requested class and returns an ObjRef back to the client application that invoked it. A proxy is then created on the client side using the ObjRef. The client's method calls will be executed on the proxy. Client-activated objects can store state information between method calls for its specific client and not across different client objects. Each invocation of "new" returns a proxy to an independent instance of the server type


Single Call/Singleton Objects Client-Activated Objects
Client side- activation code (Code required on the client side)
For more information see the section on configuration files
a) Activator.GetObject()
b) new() with CFG file
Client's CFG file references the URL:
Foo= http://localhost:80/ObjectZone/Foo.soap a) Activator.CreateInstance()
b) new() with CFG file
Client's CFG file references the URL.

Activation of the server object No activation message is sent over the network until the first method call is made. Activation message is sent to the server machine when the client creates the object and a proxy is created on the client side. Constructors with parameters are supported.
Lifetime of the server object Lifetime is dictated by the configuration on the server. Could be either SingleCall or Singleton. Singleton objects are also subject to lifetime management. Lifetime is the earlier of these two events:
a) Lease expires
b) When the client loses its reference on the server object
Server side registration
a) Use configuration file to specify the type (SingleCall or Singleton).
b) Use RegisterWellKnownServiceType () api to register the type.
Use configuration file to export the client-activated object.
For more information see the section on configuration files.

Advantages of the models
a) Clients can be compiled against server component's base class or interface definition Common Language Runtime metadata.
b) Useful to perform finite operations on the server side.
c) Single call objects can be easily deployed in a Load Balanced system, as they don't hold state.
d) Singleton Objects can maintain state information across client objects. a) Classic COM "coclass" like invocation of the server object.
b) Gives clients more flexibility to govern the server object's lifetime.
c) Client can pass constructor parameters to the created object.
d) Server Objects can hold state for its specific client between method calls.



renewOnCallTime="20ms" />

url="http://localhost:8000/RemotingHello/HelloService.soap" />



type="System.Runtime.Remoting.Channels.Http.HttpChannel,
System.Runtime.Remoting" />




Comments

No responses found. Be the first to comment...


  • Do not include your name, "with regards" etc in the comment. Write detailed comment, relevant to the topic.
  • No HTML formatting and links to other web sites are allowed.
  • This is a strictly moderated site. Absolutely no spam allowed.
  • Name:
    Email: