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
Wednesday, August 25, 2004
Tuesday, August 24, 2004
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.
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...
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...
Subscribe to:
Posts (Atom)