Thursday, December 16, 2004

MSDN Magazine Download Link

http://msdn.microsoft.com/msdnmag/issues/YY/MM/MSDNMagYYMM.chm

Tuesday, November 16, 2004

SQL DMO - Distributed Management Objects

Dim objsqlserver As New SQLDMO.SQLServer

Private Sub Command1_Click()

objsqlserver.LoginTimeout = 30
objsqlserver.Connect "SERVER_Name", "sa", "sa"
MsgBox "Connected!!"
End Sub

Private Sub Command2_Click()
Dim TestTable As SQLDMO.Table
Dim colAge As New SQLDMO.Column

colAge.Name = "Age"
colAge.Datatype = "char"
colAge.Length = 10
colAge.AllowNulls = True
Set TestTable = objsqlserver.Databases("DB_Name").Tables("Test_Table")
TestTable.BeginAlter
TestTable.Columns.Add colAge
TestTable.DoAlter
End Sub

Thursday, September 23, 2004

.NET FAQ's

http://www.geocities.com/santhosh0123/faq/faqcsh.htm

Thursday, September 16, 2004

DevDays 2004 Downloads

http://www.microsoft.com/india/msdn/devdays/devdaysdownload.aspx

Wednesday, September 15, 2004

Web Forms DataGrid and DataSet Programming

http://www.developerfusion.com/scripts/print.aspx?id=3801

DataGrid,Data List and Repeater - Which to Use When...Good Question

Fundu artcle by scott Michel (ASP.NET Guru...I m saluting to this guy....)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnet-whenusedatawebcontrols.asp

Wednesday, August 25, 2004

Crystal Report.NET......Alag Duniya!!

Useful Links..

1. Regarding Deployment
http://support.businessobjects.com/communityCS/TechnicalPapers/crnet_deployment.pdf

2. Regarding Licence
http://www.businessobjects.com/products/reporting/crystalreports/net/licensing.asp

3. General Stuff - Reporting Decisions in .NET!!
http://www.c-sharpcorner.com/Code/2004/Feb/ReportsInDotNet.asp

Tuesday, August 24, 2004

.NET Books...Here we go!!

http://sudhirmangla.i6networks.com/dotnet/books.htm

Basic ASP.NET Funda

Good Info......

http://www.takempis.com/aspnet_fundamentals.asp

Thursday, August 12, 2004

Value Types Vs reference Types

Introduction:

There are basically two types of variables in Common Type System ?
1) Value Type: Get Stored on Stack Memory.
2) Reference Type: Get Stored on Managed Heap Memory

How this Works?
Value types get stored on stack and shared the same process memory, however the Reference Types get stored on Heap and their memory address value gets stored on the stack as value type.

Question: When an object (child Object) is instantiated inside an object (parent Object) where does it get stored?
Answer: The value of child object (Reference type) gets stored in another random memory area on the managed heap and its reference (memory address value) gets stored in the managed heap of the Parent Object as Value Type.

The value of child object (Value type) gets stored in the Parent object's memory area of the managed heap.

For Example:
Module Module1 'Main Entry
Sub Main()
Dim i As Integer = 50
Dim objA As classA = New ClassA
Dim j As Integer = 25
End Sub
End Module


Public Class ClassA 'Parent Class
Dim obj As New ClassB
Dim MoreInfo As String = "sample"

End Class

Public Class ClassB 'Child Class
Public name As String
Public age As Integer

End Class

Value of the ObjA gets stored in the Managed Heap and its memory address value gets stored on the Stack. But, in case of ObjB the value of the ObjB gets stored at another location in the Managed Heap and the memory address value of this location gets stored as a value type in ObjA Managed Heap.

Monday, August 09, 2004

Good Article/Funda of CLR Internal

Here goes the very good article from MSDN India:

Its good for basic understanding........

Ever wondered what happens behind the scenes when we click a managed executable (.EXE). Yes, the application starts, but how does it starts and what all happens behind the scene. Here we will talk, what all happens when a managed application is launched. But before that we’ll go through a basic overview of CLR Hosting!

CLR Hosting defines how the CLR is loaded into the process, the transition from unmanaged environment to managed environment and execution of applications. There is a Runtime Host, an unmanaged code shim, which loads the CLR into the process. This runtime host first creates an Application Domain called “Default Application Domain” where the runtime is loaded. Then the control is transferred to this managed runtime and it further creates more application domains, load managed user code and executes them without using any unmanaged code. This execution of user code into the managed environment without any calls going to unmanaged environment gives us a performance increase because making calls from managed to unmanaged is expensive. Another feature of Hosting is that it provides some unmanaged APIs also with which we can write our custom runtime host specifically designed for our application.

Now we will explain the process which happens behind the scene before the application starts. When a managed EXE is clicked, first the CLR is loaded into the process. When the runtime is loaded, then the control is passed from unmanaged code to manage code. This managed code further creates application domain and loads the user code into these application domains. CLR then checks the user code for verification, type safety, security checks, etc. After it finishes, the Class Loader finds the class (the entry point) inside the assembly, loads it and loads other classes which are directly called from the entry point method. JIT compiles this managed code to native CPU instruction set and let the processor executes these instruction sets. JIT does not compile all the managed code into the native code at once. It does it on demand basis. Means during the execution time of the user code, if the runtime engine needs to use the code of another assembly or same assembly, it converts into native code at that time, not during the first JIT. Let see this process in detail.

Loading the runtime into the process

Before any managed code is executed, the runtime must be loaded into the process and initialize the common language runtime. This loading of runtime into the process is to be done by an unmanaged code because for executing a managed code, we still need the runtime into the process and this is what we want to do. So we have an unmanaged code stub from where we start. This unmanaged code stub is in the “mscoree.dll” file placed in “%windir%/system32”. .NET Framework provides a set of unmanaged APIs called “Hosting APIs” which helps us in loading the runtime. An unmanaged method, CorBindToRuntimeEx, is called for hosting the runtime into the process. This method have few parameters which defines which version of runtime is to be loaded, which runtime build to load (server or workstation), which garbage collection technique to be used (concurrent or non-concurrent) and other details. Also this unmanaged code stub creates a default application domain where the runtime is to be loaded because in .NET Framework, managed code is loaded into application domains (logical process which restrict the application boundary) and executed there hence required.

Transition from unmanaged code to managed code

Once the default application domain is created, there is a need to transfer the control from the unmanaged code to managed code. There are few reasons for that. Firstly, if we don’t transfer the control, then the user code would be loaded in a managed environment and any call originating from the user code need to cross the managed environment to the unmanaged environment and this is expensive. There will be a performance hit in this case. Moreover if the user code is managed by runtime in the managed environment only, it provide more security and easily manageable without any interoperability layer coming in between.

Once the default application domain is created, the runtime host gets a pointer to that default domain and loads the runtime into that default domain. To get the pointer to the default domain, we have an interface called ICorRuntimeHost which enables the host to accomplish task like configuration setting, getting default domain, etc. Once the host gets the pointer of the default domain it loads the managed portion of runtime into the default application domain. When the transition is complete, the unmanaged stub is no longer required as our runtime manages everything from this point.

Runtime create App Domains and loads the user code

To load the user code and execute it, there should be more application domains beside the “default application domain”. In “Default application domain” only hosts the runtime and domain-neutral assemblies can reside. For user code, the runtime have to create more application domains specific to the application. The runtime decides where the application domain is to be created depending on the application memory requirement and isolation factor. Again the runtime sets the user application domain configuration settings like setting the root directory from where the application domain will be looking for private assemblies. Isolation is an important factor because if the applications are not isolated properly, then breakdown of one application may lead to breakdown of other application sharing the application domain. When the application domain is created and its configuration is set, the managed user code (Assembly) is loaded in the application domain. Here managed user code means any code that is not part of the host. The user code is loaded into the application domain using System.Appdomain.Load () method which is overloaded with various inputs or emitting a dynamic assembly using System.Reflection.Emit namespace.

Runtime verifies the assembly loaded; checks for type safety, security

Any user code which is loaded into the application domain has to pass the verification test done by runtime unless it is configured to be bypassed by the administrator. In verification, the runtime checks the MSIL and Metadata to find out whether the code can marked as type safe which means that every object in the code refers to a known and authorized memory location. It also checks if the referencing object is strictly compatible with the object that is being referenced to. These are the basic checks that are done by runtime for type safety. Also security checks are done here. It checks if the caller has the permission to execute this code. All security checks are done for every method in the assembly.

Class Loader loads the classes from the assembly

The loader reads the metadata and code modules, identifies the “entry point” (method that is executed when the code is first run). This incorporates a complex process of loading a class from a physical file from hard disk/network, from a dynamic assembly which is in the memory, caching the Type information, performing some JIT and garbage collection housekeeping, and then passing control to the JIT compilers. This loader basically figures out the number and type of fields so that runtime can create instances for the same. It also has to check the classes it is loading, does it have any relationship with other classes like is it a derived class or a parent class because some of the member might be overridden from the base class in child class. Then these classes are forwarded to JIT to native compilation. The loader doesn’t forward all the code to JIT. When the method is needed, only then it is given to JIT for compilation. So the method which are not called directly from the entry points, there stubs are created and when these methods are called, these stubs passes the control to JIT.

JIT compiles the MSIL to native managed code

JIT a synonym for “Just In Time” Compiler converts the MSIL to native CPU instruction set. The instruction set to which the MSIL is converted is specific to the CPU where the code is being executed. This helps in using the extended instruction set specific to that CPU Architecture and model. JIT compilation thinks that some code would never be executed so it just compiles the necessary code to start into native code. Rest all the code is compiled on demand basis, means as and when the method needs to be executed; the stub attached to the method passes the control to JIT to compile the MSIL code. Once the MSIL code is converted to native code, it need not convert it again and again on subsequent calls. This native code is cached and used for subsequent calls.

Now the MSIL is converted into native code, the application starts and we see our User Interface for the application; may it be Web application or Windows based Application. I have tried to give you an idea what all happens behind the scene including the CLR internals as to how it works.


Maja aaya ya Nahi....????? I hope u Njoyed it...


Wednesday, July 28, 2004

.NET Developer's Guide to Windows Security

Hi,

This is really good book for Security......Now a days I m in love with it.......

A .NET Developer's Guide to Windows Security, by Keith Brown

http://www.pluralsight.com/keith/book/html/book.html

Fundoooooooooooooooooooo......Maja aa gaya......!!!!

Tuesday, July 13, 2004

Funda No.2: What are Static/Type Constructors? Good Question!!

Even I came to know about it Today!!!

Static/Type Constructors

You are already familiar with constructors, which are responsible for setting an object instance to its initial state. In addition to instance constructors, the Microsoft® .NET common language runtime (CLR) also supports type constructors (also known as static constructors, class constructors, or type initializers). A type constructor can be applied to interfaces, classes, and value types. It allows the type to perform any initialization required before any members declared within the type are accessed. Type constructors accept no parameters and always have a return type of void. A type constructor only has access to a type's static fields and its usual purpose is to initialize those fields. A type's constructor is guaranteed to run before any instance of the type is created and before any static field or method of the type is referenced.
Many languages (including C#) automatically generate type constructors for any types you define. However, some languages will require you to implement the type constructors explicitly.

To understand type constructors, examine the following type (defined in C#):

class AType {
static int x = 5;
}

When this code is built, the compiler automatically generates a type constructor for AType. This constructor is responsible for initializing the static field x to the value 5. If you're using ILDasm, you can easily spot type constructor methods because they have a name of .cctor (for class constructor).
In C#, you can implement type constructors yourself by defining a static constructor method in your type. The use of the static keyword makes the constructor a type constructor rather than an instance constructor. Here is a very simple example:

class AType {
static int x;

static AType() {
x = 5;
}
}

This type definition is identical to the previous one. Note that a type constructor must never attempt to create any instances of its own type, and the constructor must not reference any of the type's nonstatic members.
Finally, if you give the C# compiler the following code, it generates a single type constructor method.

class AType {
static int x = 5;

static AType() {
x = 10;
}
}

This constructor first initializes x to 5 and then initializes x to 10. In other words, the resulting type constructor generated by the compiler first contains the static field initialization code, which is then followed by the code in your type constructor method.


Kyon Kaisee rahi.........

Bye Deepak.....Watch out for funda No.3............

Funda No.1 : Sealed Modifier in C# - Really Good

Hi Guys,

Look into it.....

Funda No.1 :

In Beta 1, the Sealed modifier, when used on method overrides, yielded a compiler error: "The modifier 'sealed' is not valid for this item." In Beta 2, the compiler recognizes the Sealed modifier.

Sample Code Snippet:
public class B : A
{
public B()
{
}
sealed public override string Method1()
{
return "Override";
}
}

Use of the Sealed modifier, in conjunction with the override method, will prevent anything classes derive from class B from further overriding Method1(), which originally was provided by the base class A.

So Hows That....

Tuesday, June 15, 2004