Explore topic-wise InterviewSolutions in Current Affairs.

An application domain is lighter than a PROCESS. Application domains are appropriate for scenarios that require isolation without the heavy cost associated with running an application within a process. A process runs exactly one application. In contrast, the CLR ALLOWS multiple applications to be run in a single process by LOADING them into SEPARATE application domains. Additionally, the CLR verifies that user CODE in an application domain is type safe.

An application domain is lighter than a process. Application domains are appropriate for scenarios that require isolation without the heavy cost associated with running an application within a process. A process runs exactly one application. In contrast, the CLR allows multiple applications to be run in a single process by loading them into separate application domains. Additionally, the CLR verifies that user code in an application domain is type safe.

The first STEP in running managed code in a process is to get the CLR loaded and initialized using a CLR host. Typically, a host consists of both managed code and unmanaged code. The managed code which executes in the default domain is usually responsible for creating the application domains in which the user code exists. All CLR hosts must contain unmanaged code because execution must begin in unmanaged code. The .NET Frameworks provides a SET of unmanaged APIs that the host can use to configure the CLR, load the CLR into a process, load the hosts managed code into the default domain, and transition from the unmanaged code to the managed code. The second step in running managed code in a process is to create application domains in which the user code will execute. The creator of the application domain can specify criteria which control code isolation, security, and loading of assemblies. The third step in running managed code in a process is to execute user code in one or more application domains created in the previous step. All code that is run in the CLR must be part of an assembly. There are three options for loading assemblies. First, precompiled assemblies can be loaded from disk. Second, precompiled assemblies can be loaded from an array of BYTES. Third, assemblies can be built dynamically in an application domain using the BCL Reflection Emit APIs.

Note. For an application launched from the command-line, the shell host executes the steps described above on BEHALF of the user and hides the COMPLEXITY from the user.

The first step in running managed code in a process is to get the CLR loaded and initialized using a CLR host. Typically, a host consists of both managed code and unmanaged code. The managed code which executes in the default domain is usually responsible for creating the application domains in which the user code exists. All CLR hosts must contain unmanaged code because execution must begin in unmanaged code. The .NET Frameworks provides a set of unmanaged APIs that the host can use to configure the CLR, load the CLR into a process, load the hosts managed code into the default domain, and transition from the unmanaged code to the managed code. The second step in running managed code in a process is to create application domains in which the user code will execute. The creator of the application domain can specify criteria which control code isolation, security, and loading of assemblies. The third step in running managed code in a process is to execute user code in one or more application domains created in the previous step. All code that is run in the CLR must be part of an assembly. There are three options for loading assemblies. First, precompiled assemblies can be loaded from disk. Second, precompiled assemblies can be loaded from an array of bytes. Third, assemblies can be built dynamically in an application domain using the BCL Reflection Emit APIs.

Note. For an application launched from the command-line, the shell host executes the steps described above on behalf of the user and hides the complexity from the user.

CLR does not provide a way to unload an assembly. The only mechanism to remove the assembly is to unload the APPLICATION domain in which the assembly is LOADED. If you wish to remove an assembly after it has been used, you should CREATE an application domain, load the assembly into the created application domain, and then unload the application domain when you no longer NEED the assembly.

CLR does not provide a way to unload an assembly. The only mechanism to remove the assembly is to unload the application domain in which the assembly is loaded. If you wish to remove an assembly after it has been used, you should create an application domain, load the assembly into the created application domain, and then unload the application domain when you no longer need the assembly.

You should use the following static method in the System.APPDOMAIN

class:
public static void Unload(AppDomain DOMAIN)

The Unload method gracefully shuts down the specified application domain. During SHUTDOWN no new threads are allowed to enter the application domain and all application domain specific data structures are freed. You cannot unload an application domain in a finalizer or destructor.

If the application domain has run code from a domain-neutral ASSEMBLY, the domains copy of the statics and related CLR data structures are freed, but the code for the domain-neutral assembly remains until the process is shutdown. There is no mechanism to fully unload a domain-neutral assembly other than SHUTTING down the process.

You should use the following static method in the System.AppDomain

class:
public static void Unload(AppDomain domain)

The Unload method gracefully shuts down the specified application domain. During shutdown no new threads are allowed to enter the application domain and all application domain specific data structures are freed. You cannot unload an application domain in a finalizer or destructor.

If the application domain has run code from a domain-neutral assembly, the domains copy of the statics and related CLR data structures are freed, but the code for the domain-neutral assembly remains until the process is shutdown. There is no mechanism to fully unload a domain-neutral assembly other than shutting down the process.

One of the good features of the CLR is Garbage Collection, which runs in the background collecting unused object references, freeing us from having to ENSURE we always destroy them. In reality the time difference between you releasing the object instance and it being garbage COLLECTED is LIKELY to be very small, since the GC is always running.
[The process of transitively tracing through all pointers to actively used objects in order to locate all objects that can be referenced, and then arranging to reuse any heap memory that was not found during this trace. The common LANGUAGE runtime garbage collector also compacts the memory that is in use to reduce the working SPACE needed for the heap.]

Heap:
A portion of memory reserved for a program to use for the temporary storage of data structures whose existence or size cannot be determined until the program is running.

One of the good features of the CLR is Garbage Collection, which runs in the background collecting unused object references, freeing us from having to ensure we always destroy them. In reality the time difference between you releasing the object instance and it being garbage collected is likely to be very small, since the GC is always running.
[The process of transitively tracing through all pointers to actively used objects in order to locate all objects that can be referenced, and then arranging to reuse any heap memory that was not found during this trace. The common language runtime garbage collector also compacts the memory that is in use to reduce the working space needed for the heap.]

Heap:
A portion of memory reserved for a program to use for the temporary storage of data structures whose existence or size cannot be determined until the program is running.

MSIL: (Microsoft INTERMEDIATE language):
When compiling to managed code, the compiler translates your source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code. MSIL includes instructions for loading, storing, initializing, and calling methods on OBJECTS, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. Before code can be executed, MSIL must be converted to CPU-specific code, usually by a just-in-time (JIT) compiler. Because the common language runtime supplies one or more JIT compilers for each computer architecture it supports, the same set of MSIL can be JIT-compiled and executed on any supported architecture.

When a compiler produces MSIL, it also produces metadata. Metadata DESCRIBES the types in your code, including the definition of each type, the signatures of each type's members, the members that your code references, and other DATA that the runtime uses at execution time. The MSIL and metadata are contained in a portable executable (PE) file that is based on and extends the published Microsoft PE and Common Object File Format (COFF) used historically for executable content. This file format, which accommodates

MSIL or native code as well as metadata, enables the operating system to recognize common language runtime IMAGES. The presence of metadata in the file along with the MSIL enables your code to describe itself, which means that there is no need for type libraries or Interface Definition Language (IDL). The runtime locates and extracts the metadata from the file as needed during execution.

IL: (Intermediate Language):
A language used as the output of a number of compilers and as the input to a just-in-time (JIT) compiler. The common language runtime includes a JIT compiler for converting MSIL to native code.

CTS: (Common Type System):
The specification that determines how the common language runtime defines, uses, and manages types

CLR: (Common Language Runtime):
The engine at the core of managed code execution. The runtime supplies managed code with services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support.

MSIL: (Microsoft intermediate language):
When compiling to managed code, the compiler translates your source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code. MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. Before code can be executed, MSIL must be converted to CPU-specific code, usually by a just-in-time (JIT) compiler. Because the common language runtime supplies one or more JIT compilers for each computer architecture it supports, the same set of MSIL can be JIT-compiled and executed on any supported architecture.

When a compiler produces MSIL, it also produces metadata. Metadata describes the types in your code, including the definition of each type, the signatures of each type's members, the members that your code references, and other data that the runtime uses at execution time. The MSIL and metadata are contained in a portable executable (PE) file that is based on and extends the published Microsoft PE and Common Object File Format (COFF) used historically for executable content. This file format, which accommodates

MSIL or native code as well as metadata, enables the operating system to recognize common language runtime images. The presence of metadata in the file along with the MSIL enables your code to describe itself, which means that there is no need for type libraries or Interface Definition Language (IDL). The runtime locates and extracts the metadata from the file as needed during execution.

IL: (Intermediate Language):
A language used as the output of a number of compilers and as the input to a just-in-time (JIT) compiler. The common language runtime includes a JIT compiler for converting MSIL to native code.

CTS: (Common Type System):
The specification that determines how the common language runtime defines, uses, and manages types

CLR: (Common Language Runtime):
The engine at the core of managed code execution. The runtime supplies managed code with services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support.

BOXING:
The conversion of a value TYPE instance to an object, which implies that the instance will carry full type INFORMATION at run time and will be allocated in the HEAP. The Microsoft intermediate language (MSIL) instruction set's box instruction CONVERTS a value type to an object by making a copy of the value type and embedding it in a newly allocated object.

Un-Boxing:
The conversion of an object instance to a value type.

Boxing:
The conversion of a value type instance to an object, which implies that the instance will carry full type information at run time and will be allocated in the heap. The Microsoft intermediate language (MSIL) instruction set's box instruction converts a value type to an object by making a copy of the value type and embedding it in a newly allocated object.

Un-Boxing:
The conversion of an object instance to a value type.

The Microsoft .NET COMPACT Framework is designed to run on mobile DEVICES such as mobile phones, Personal Digital ASSISTANTS (PDAs), and embedded devices. The easiest way to develop and TEST a Smart Device Application is to use an emulator.

These devices are divided into two main divisions:

1) Those that are directly supported by .NET (Pocket PCs, i-Mode phones, and WAP devices)
2) Those that are not (Palm OS and J2ME-powered devices).

The Microsoft .NET Compact Framework is designed to run on mobile devices such as mobile phones, Personal Digital Assistants (PDAs), and embedded devices. The easiest way to develop and test a Smart Device Application is to use an emulator.

These devices are divided into two main divisions:

1) Those that are directly supported by .NET (Pocket PCs, i-Mode phones, and WAP devices)
2) Those that are not (Palm OS and J2ME-powered devices).

These are static assemblies that must have a unique SHARED name and can be used by any application.

An application uses a private ASSEMBLY by referring to the assembly USING a static path or through an XML-based application configuration file. While the CLR doesn't enforce versioning policies-checking whether the CORRECT version is used-for private assemblies, it ensures that an application uses the correct shared assemblies with which the application was built. Thus, an application uses a specific shared assembly by referring to the specific shared assembly, and the CLR ensures that the correct version is LOADED at runtime.

These are static assemblies that must have a unique shared name and can be used by any application.

An application uses a private assembly by referring to the assembly using a static path or through an XML-based application configuration file. While the CLR doesn't enforce versioning policies-checking whether the correct version is used-for private assemblies, it ensures that an application uses the correct shared assemblies with which the application was built. Thus, an application uses a specific shared assembly by referring to the specific shared assembly, and the CLR ensures that the correct version is loaded at runtime.

"Advantage includes AUTOMATIC garbage collection,memory management,security,type checking,versioning Managed code is compiled for the .NET run-time environment. It RUNS in the Common Language Runtime (CLR), which is the HEART of the .NET Framework. The CLR provides services such as security,memory management, and cross-language integration. Managed applications written to take advantage of the features of the CLR perform more efficiently and safely, and take better advantage of developers existing EXPERTISE in languages that support the .NET Framework.

Unmanaged code includes all code written before the .NET Framework was introduced-this includes code written to use COM, native Win32, and Visual Basic 6. Because it does not run INSIDE the .NET environment, unmanaged code cannot make use of any .NET managed facilities."

"Advantage includes automatic garbage collection,memory management,security,type checking,versioning Managed code is compiled for the .NET run-time environment. It runs in the Common Language Runtime (CLR), which is the heart of the .NET Framework. The CLR provides services such as security,memory management, and cross-language integration. Managed applications written to take advantage of the features of the CLR perform more efficiently and safely, and take better advantage of developers existing expertise in languages that support the .NET Framework.

Unmanaged code includes all code written before the .NET Framework was introduced-this includes code written to use COM, native Win32, and Visual Basic 6. Because it does not run inside the .NET environment, unmanaged code cannot make use of any .NET managed facilities."

• You can create an objects of DLL but not of the EXE.
• Dll is an In-Process Component whereas EXE is an OUt-Process Component.
• Exe is for SINGLE use whereas you can use Dll for multiple use.
• Exe can be STARTED as STANDALONE where dll cannot be.

Strong typing IMPLIES that the types of variables involved in operations are ASSOCIATED to the variable, checked at compile-time, and require explicit conversion; weak typing implies that they are associated to the VALUE, checked at run-time, and are implicitly converted as required. (Which is PREFERRED is a disputable point, but I personally PREFER strong typing because I like my errors to be found as soon as possible.)

Strong typing implies that the types of variables involved in operations are associated to the variable, checked at compile-time, and require explicit conversion; weak typing implies that they are associated to the value, checked at run-time, and are implicitly converted as required. (Which is preferred is a disputable point, but I personally prefer strong typing because I like my errors to be found as soon as possible.)

.NET PROVIDES an utility called strong name tool. You can run this toolfrom the VS.NET COMMAND prompt to generate a strong name with an option "-k" and providing the strong key file name. i.e. sn- -k < file-name >

.NET provides an utility called strong name tool. You can run this toolfrom the VS.NET command prompt to generate a strong name with an option "-k" and providing the strong key file name. i.e. sn- -k < file-name >

Netremoting replaces DCOM. Web Services that USES remoting can run in anyApplication type i.e. Console Application, Windows Form Applications,Window Services etc. In CLR Object Remoting we can CALL objectsacross NETWORK.

Netremoting replaces DCOM. Web Services that uses remoting can run in anyApplication type i.e. Console Application, Windows Form Applications,Window Services etc. In CLR Object Remoting we can call objectsacross network.

Bill Gates DELIVERED a keynote at Forum 2000, held June 22, 2000, outlining the .NET 'vision'. The JULY 2000 PDC had a number of sessions on .NET TECHNOLOGY, and delegates were GIVEN CDs containing a pre-release version of the .NET framework/SDK and Visual Studio.NET.

Bill Gates delivered a keynote at Forum 2000, held June 22, 2000, outlining the .NET 'vision'. The July 2000 PDC had a number of sessions on .NET technology, and delegates were given CDs containing a pre-release version of the .NET framework/SDK and Visual Studio.NET.

The final VERSION of the 1.0 SDK and runtime was made PUBLICLY available around 6pm PST on 15-Jan-2002. At the same time, the final version of Visual Studio.NET was made available to MSDN subscribers.

The final version of the 1.0 SDK and runtime was made publicly available around 6pm PST on 15-Jan-2002. At the same time, the final version of Visual Studio.NET was made available to MSDN subscribers.

The runtime supports Windows XP, Windows 2000, NT4 SP6a and Windows ME/98. Windows 95 is not supported. Some PARTS of the framework do not work on all platforms - for example, ASP.NET is only supported on Windows XP and Windows 2000. Windows 98/ME cannot be used for DEVELOPMENT.

IIS is not supported on Windows XP HOME Edition, and so cannot be used to host ASP.NET. However, the ASP.NET Web Matrix web server does RUN on XP Home.

The Mono project is attempting to implement the .NET framework on Linux.

The runtime supports Windows XP, Windows 2000, NT4 SP6a and Windows ME/98. Windows 95 is not supported. Some parts of the framework do not work on all platforms - for example, ASP.NET is only supported on Windows XP and Windows 2000. Windows 98/ME cannot be used for development.

IIS is not supported on Windows XP Home Edition, and so cannot be used to host ASP.NET. However, the ASP.NET Web Matrix web server does run on XP Home.

The Mono project is attempting to implement the .NET framework on Linux.

Major or minor. Changes to the major or minor portion of the version NUMBER indicate an incompatible change. Under this convention then, version 2.0.0.0 would be considered incompatible with version 1.0.0.0. Examples of an incompatible change would be a change to the types of some method PARAMETERS or the removal of a type or method altogether. Build. The Build number is typically used to distinguish between daily builds or SMALLER compatible releases. REVISION. Changes to the revision number are typically reserved for an incremental build needed to fix a particular bug. You'll sometimes hear this referred to as the "emergency bug fix" number in that the revision is what is often changed when a fix to a specific bug is SHIPPED to a customer.

Major or minor. Changes to the major or minor portion of the version number indicate an incompatible change. Under this convention then, version 2.0.0.0 would be considered incompatible with version 1.0.0.0. Examples of an incompatible change would be a change to the types of some method parameters or the removal of a type or method altogether. Build. The Build number is typically used to distinguish between daily builds or smaller compatible releases. Revision. Changes to the revision number are typically reserved for an incremental build needed to fix a particular bug. You'll sometimes hear this referred to as the "emergency bug fix" number in that the revision is what is often changed when a fix to a specific bug is shipped to a customer.

Side-by-side execution is the ability to run multiple versions of an APPLICATION or component on the same computer. You can have multiple versions of the common language runtime, and multiple versions of applications and components that use a version of the runtime, on the same computer at the same time. Since versioning is only APPLIED to SHARED assemblies, and not to private assemblies, two application ONE using private assembly and one using shared assembly cannot be stated as side-by-side executables,

Side-by-side execution is the ability to run multiple versions of an application or component on the same computer. You can have multiple versions of the common language runtime, and multiple versions of applications and components that use a version of the runtime, on the same computer at the same time. Since versioning is only applied to shared assemblies, and not to private assemblies, two application one using private assembly and one using shared assembly cannot be stated as side-by-side executables,

The memory representation of string is an Array of Characters, So on re-assigning the NEW array of Char is formed & the START ADDRESS is changed . Thus keeping the Old string in Memory for Garbage COLLECTOR to be disposed.

The memory representation of string is an Array of Characters, So on re-assigning the new array of Char is formed & the start address is changed . Thus keeping the Old string in Memory for Garbage Collector to be disposed.

In debug COMPILATION, assert takes in a Boolean condition as a parameter, and shows the error dialog if the condition is false. The program PROCEEDS WITHOUT any INTERRUPTION if the condition is true.

In debug compilation, assert takes in a Boolean condition as a parameter, and shows the error dialog if the condition is false. The program proceeds without any interruption if the condition is true.

DOCUMENTATION LOOKS the same. Use DEBUG CLASS for debug builds, use TRACE class for both debug and release builds.

Documentation looks the same. Use Debug class for debug builds, use Trace class for both debug and release builds.

To the Console or a text FILE DEPENDING on the parameter PASSED to the CONSTRUCTOR.

To the Console or a text file depending on the parameter passed to the constructor.

Each assembly has a version number called the compatibility version. ALSO each reference to an assembly (from another assembly) includes both the name and version of the referenced assembly.The version number has four numeric parts (e.g. 5.5.2.33). Assemblies with either of the first two parts DIFFERENT are normally viewed as incompatible. If the first two parts are the same, but the third is different, the assemblies are deemed as 'maybe compatible'. If only the fourth part is different, the assemblies are deemed compatible. HOWEVER, this is just the default GUIDELINE - it is the version policy that decides to what extent these rules are enforced. The version policy can be SPECIFIED via the application configuration

Each assembly has a version number called the compatibility version. Also each reference to an assembly (from another assembly) includes both the name and version of the referenced assembly.The version number has four numeric parts (e.g. 5.5.2.33). Assemblies with either of the first two parts different are normally viewed as incompatible. If the first two parts are the same, but the third is different, the assemblies are deemed as 'maybe compatible'. If only the fourth part is different, the assemblies are deemed compatible. However, this is just the default guideline - it is the version policy that decides to what extent these rules are enforced. The version policy can be specified via the application configuration

There are two separate mechanisms provided by the .NET class library-XmlSerializer and
SoapFormatter/BinaryFormatter. MICROSOFT uses XmlSerializer for Web Services, and uses
SoapFormatter/BinaryFormatter for remoting. Both are AVAILABLE for use in your own code

There are two separate mechanisms provided by the .NET class library-XmlSerializer and
SoapFormatter/BinaryFormatter. Microsoft uses XmlSerializer for Web Services, and uses
SoapFormatter/BinaryFormatter for remoting. Both are available for use in your own code

Yes. XMLSERIALIZER supports a range of attributes that can be used to configure serialization for a particular class. For example, a field or property can be marked with the [XmlIgnore] attribute to EXCLUDE it from serialization. Another example is the [XmlElement] attribute, which can be used to specify the XML element name to be used for a particular property or field. Serialization via SoapFormatter/BinaryFormatter can also be controlled to some extent by attributes. For example, the [NonSerialized] attribute is the equivalent of XmlSerializer's [XmlIgnore] attribute. Ultimate control of the serialization PROCESS can be acheived by IMPLEMENTING the the ISerializable interface on the class WHOSE instances are to be serialized.

Yes. XmlSerializer supports a range of attributes that can be used to configure serialization for a particular class. For example, a field or property can be marked with the [XmlIgnore] attribute to exclude it from serialization. Another example is the [XmlElement] attribute, which can be used to specify the XML element name to be used for a particular property or field. Serialization via SoapFormatter/BinaryFormatter can also be controlled to some extent by attributes. For example, the [NonSerialized] attribute is the equivalent of XmlSerializer's [XmlIgnore] attribute. Ultimate control of the serialization process can be acheived by implementing the the ISerializable interface on the class whose instances are to be serialized.

There is a once-per-process-per-type overhead with XmlSerializer. So the first time you serialize or deserialize an object of a given type in an APPLICATION, there is a SIGNIFICANT delay. This normally doesn't matter, but it MAY mean, for example, that XmlSerializer is a poor choice for loading CONFIGURATION settings during startup of a GUI application.

There is a once-per-process-per-type overhead with XmlSerializer. So the first time you serialize or deserialize an object of a given type in an application, there is a significant delay. This normally doesn't matter, but it may mean, for example, that XmlSerializer is a poor choice for loading configuration settings during startup of a GUI application.

XmlSerializer will REFUSE to serialize instances of any CLASS that implements IDictionary, e.g. HASHTABLE. SoapFormatter and BinaryFormatter do not have this RESTRICTION.

XmlSerializer will refuse to serialize instances of any class that implements IDictionary, e.g. Hashtable. SoapFormatter and BinaryFormatter do not have this restriction.

A STATIC CONSTRUCTOR of a class gets INITIALISED and INVOKED when the assembly loads itself.

A Static Constructor of a class gets initialised and invoked when the assembly loads itself.

you can invoke it in 3 ways.
1.Using rs SCRIPT and command PROMPT
2.From web BROWSER.
3.Using SOAP API

you can invoke it in 3 ways.
1.Using rs script and command Prompt
2.From web browser.
3.Using SOAP API

There is a simple but important DIFFERENCE between these three.

ToString() raise exception when the object is NULL

So in the case of object.ToString(), if object is null, it raise NullReferenceException.

Convert.ToString() return string.Empty in case of null object

(string) cast ASSIGN the object in case of null

So in case of
MyObject o = (string)NullObject;

But when you USE o to access any property, it will raise NullReferenceException.

There is a simple but important difference between these three.

ToString() raise exception when the object is null

So in the case of object.ToString(), if object is null, it raise NullReferenceException.

Convert.ToString() return string.Empty in case of null object

(string) cast assign the object in case of null

So in case of
MyObject o = (string)NullObject;

But when you use o to access any property, it will raise NullReferenceException.

It enabled us to query REMOTE DATABASE SERVERS of different providers.

THUS we can copy or select table data between multiple servers.

It enabled us to query remote database servers of different providers.

Thus we can copy or select table data between multiple servers.

1.User DEFINED STORED PROCEDURES.
a.Transact-SQL stored PROCEDURE
b.CLR Stored Procedure.

2.System Stored Procedures

1.User Defined Stored Procedures.
a.Transact-SQL stored procedure
b.CLR Stored Procedure.

2.System Stored Procedures

Advantages VB.NET :-

* Has SUPPORT for optional parameters which makes COM interoperability much easy.
* With Option Strict off late BINDING is supported.Legacy VB functionalities can be used by using Microsoft.VisualBasic namespace.
* Has the WITH construct which is not in C#.
* The VB.NET part of VISUAL Studio .NET compiles your code in the background.

While this is considered an advantage for small projects, people CREATING very large projects have found that the IDE slows down considerably as the project gets larger.

Advantages of C#

* XML documentation is generated from source code but this is now been incorporated in Whidbey.
*Operator overloading which is not in current VB.NET but is been introduced in Whidbey.
* The using statement, which makes unmanaged resource disposal simple.
* Access to Unsafe code. This allows POINTER arithmetic etc, and can improve performance in some situations. However, it is not to be used lightly, as a lot of the normal safety of C# is lost (as the name implies).This is the major difference that you can access unmanaged code in C# and not in VB.NET

Advantages VB.NET :-

* Has support for optional parameters which makes COM interoperability much easy.
* With Option Strict off late binding is supported.Legacy VB functionalities can be used by using Microsoft.VisualBasic namespace.
* Has the WITH construct which is not in C#.
* The VB.NET part of Visual Studio .NET compiles your code in the background.

While this is considered an advantage for small projects, people creating very large projects have found that the IDE slows down considerably as the project gets larger.

Advantages of C#

* XML documentation is generated from source code but this is now been incorporated in Whidbey.
*Operator overloading which is not in current VB.NET but is been introduced in Whidbey.
* The using statement, which makes unmanaged resource disposal simple.
* Access to Unsafe code. This allows pointer arithmetic etc, and can improve performance in some situations. However, it is not to be used lightly, as a lot of the normal safety of C# is lost (as the name implies).This is the major difference that you can access unmanaged code in C# and not in VB.NET

More MANAGEABILITY, MULTIPLE VIEW Support, More unit TESTING COMPATIBILITY.

More Manageability, Multiple View Support, More unit testing compatibility.

Action is a built-in delegate which RETURNS void.

There are 5 VERSIONS of Action

Action Action&LT;T&GT;
Action<T1,T2>
Action<T1,T2,T3>
Action<T1,T2,T3,T4>

Action is a built-in delegate which returns void.

There are 5 versions of Action

Action Action<T>
Action<T1,T2>
Action<T1,T2,T3>
Action<T1,T2,T3,T4>

Func is a delegate in .Net that RETURNS a value.

The RETURN type is specified USING the TResult argument.

There are 5 VERSIONS of Func in .Net.

Func&LT;TResult>
Func<T,TResult>
Func<T1,T2,TResult>
Func<T1,T2,T3,TResult>
Func<T1,T2,T3,T4,TResult>

Func is a delegate in .Net that returns a value.

The return type is specified using the TResult argument.

There are 5 versions of Func in .Net.

Func<TResult>
Func<T,TResult>
Func<T1,T2,TResult>
Func<T1,T2,T3,TResult>
Func<T1,T2,T3,T4,TResult>

Type safe code can access only the MEMORY LOCATIONS that it has PERMISSION to execute. Type safe code can NEVER access any PRIVATE members of an object. Type safe code ensures that objects are isolated from each other.

Type safe code can access only the memory locations that it has permission to execute. Type safe code can never access any private members of an object. Type safe code ensures that objects are isolated from each other.

The assembly which is used only by a single application is called as private assembly. THUS the assembly is private to your application.Suppose that you are CREATING a GENERAL purpose DLL which provides functionality which will be used by variety of applications. Now, instead of each client application having its own copy of DLL you can place the DLL in 'global assembly cache'. Such assemblies are called as shared assemblies.

The assembly which is used only by a single application is called as private assembly. Thus the assembly is private to your application.Suppose that you are creating a general purpose DLL which provides functionality which will be used by variety of applications. Now, instead of each client application having its own copy of DLL you can place the DLL in 'global assembly cache'. Such assemblies are called as shared assemblies.

We can see the ASSEMBLY information using ILDASM TOOL.

We can see the assembly information using ILDASM Tool.

we can USE GACUTIL TOOL to intall assemby in GAC FOLDER

we can use GACUTIL Tool to intall assemby in GAC folder

major.minor.build.revision

major.minor.build.revision

Struct is of value type. If we pass it across methods in layers, a new object will be created in the STACK THUS increasing memory and PROCESSING requirement.

So class should be USED for creating ENTITY like Employee, Supplier etc.

Struct is of value type. If we pass it across methods in layers, a new object will be created in the stack thus increasing memory and processing requirement.

So class should be used for creating entity like Employee, Supplier etc.

Use Stack.

If you use Stack, we can just GET the NEXT slot by using stack.Pop()

If you use LIST, we have to iterate through all list and check the status and RETRIEVE. So stack would be advantageous.

Use Stack.

If you use Stack, we can just get the next slot by using stack.Pop()

If you use List, we have to iterate through all list and check the status and retrieve. So stack would be advantageous.

USE
INT SUM = list.Reverse().TAKE(3).Sum();

Use
int sum = list.Reverse().Take(3).Sum();

ADO.NET is stateless mechanism. I can treat the ADO.Net as a separate in-memory database where in I can USE RELATIONSHIPS between the TABLES and SELECT insert and updates to the database. I can update the actual database as a BATCH.

ADO.NET is stateless mechanism. I can treat the ADO.Net as a separate in-memory database where in I can use relationships between the tables and select insert and updates to the database. I can update the actual database as a batch.

USING pagination option in DataGrid CONTROL. We have to set the NUMBER of RECORDS for a page, then it takes CARE of pagination by itself.

Using pagination option in DataGrid control. We have to set the number of records for a page, then it takes care of pagination by itself.

CLIENT SIDE is DONE by default. Server side VALIDATION is also possible. We can switch off the client side and server side can be done.

Client side is done by default. Server side validation is also possible. We can switch off the client side and server side can be done.

The web is stateless. But in ASP.NET, the state of a PAGE is MAINTAINED in the page itself automatically. The values are ENCRYPTED and SAVED in hidden controls. this is done automatically by the ASP.NET. This can be switched off / on for a single CONTROL.

The web is stateless. But in ASP.NET, the state of a page is maintained in the page itself automatically. The values are encrypted and saved in hidden controls. this is done automatically by the ASP.NET. This can be switched off / on for a single control.

a language should COMPLY with the COMMON Language Runtime standard to BECOME a .NET language. In .NET, CODE is compiled to Microsoft Intermediate Language (MSIL for short). This is called as Managed Code. This Managed code is run in .NET environment. So after compilation to this IL the language is not a barrier. A code can call or use a function written in another language.

a language should comply with the Common Language Runtime standard to become a .NET language. In .NET, code is compiled to Microsoft Intermediate Language (MSIL for short). This is called as Managed Code. This Managed code is run in .NET environment. So after compilation to this IL the language is not a barrier. A code can call or use a function written in another language.