MSCOREE.DLL

From Nikhilesh ..

 

Microsoft Component Object Runtime Execution Engine

 

This DLL holds the definition of _CORDLLMAIN and _COREXEMAIN methods. These methods will always be placed in a managed assembly.
These methods are used to load the managed environment if the assembly is called from unmanaged environment.

 

 

Schedule

So this is what I need to do eh ..?

Lets see how far I go with this one .. :)

Still havent got the schedule up adn running but atleast

after listing these down I feel a lot better. Now I know I am doomed :)

 

 

UML
	Diagrams
	Views
Patterns
	Categorisation of Patterns
SDLC/Processes
	Processes
	Phases
Project Management
	Estimation
	Requirement Elicitation
	Requirement Management
	Planning and Scheduling
	Risk management
	Config Management
	etc
OOPS
OOAD
	Object Modelling
	OOAD with UML
COM/COM+
	MTS
	Deployment and management
	Diff between MTS and COM+
DCOM
	Creation
	Deployment and management
VB/ASP
	Migration techniques to .NET
	Interop
	VB - MultiThreading
.NET Framework/Internals
	CLR
	Assemblies
	etc.
C#
	Diff between C# and VB.NET
	Multithreading
Web Services
	Security
	Transaction
	SOA
	Comparison between Remoring and Webservices
Remoting
	Comparison between CORBA, RMI and COM/DCOM with Remoting
	Transaction
Serviced Components
SQL Server
	Usage of XML in SQL
	Security in SQL
	Performance Tuning
	Data Modeling
Whidbey/Indigo
Biztalk
Speech SDK
SPPS
XML
	XPATH
	XSLT
	DTD vs Schema
	XSL
ASP.NET
	State maintenance between ASP and ASP.NET
	Perf. Max. - all techniques

 

Soni

 

Interface or Class?

Some more info that i got on the net...

 

 Interfaces, like classes, define a set of properties, methods, and events. But unlike classes, interfaces do not provide implementation. They are implemented by classes, and defined as separate entities from classes. Even though class inheritance allows your classes to inherit implementation from a base class, it also forces you to make most of your design decisions when the class is first published.

Abstract classes are useful when creating components because they allow you specify an invariant level of functionality in some methods, but leave the implementation of other methods until a specific implementation of that class is needed. They also version well, because if additional functionality is needed in derived classes, it can be added to the base class without breaking code.

 

 

Interfaces vs. Abstract Classes
Feature	Interface	Abstract class
Multiple inheritance	A class may implement several interfaces.	A class may extend only one abstract class.
Default implementation	An interface cannot provide any code at all, much less default code.	An abstract class can provide complete code, default code, and/or just stubs that have to be overridden.
Constants	Static final constants only, can use them without qualification in classes that implement the interface. On the other paw, these unqualified names pollute the namespace. You can use them and it is not obvious where they are coming from since the qualification is optional.	Both instance and static constants are possible. Both static and instance intialiser code are also possible to compute the constants.
Third party convenience	An interface implementation may be added to any existing third party class.	A third party class must be rewritten to extend only from the abstract class.
is-a vs -able or can-do	Interfaces are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.	An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Damamation descendants are Dogs, they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not the things a class is.
Plug-in	You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the interface, you start from scratch without any default implementation. You have to obtain your tools from other classes; nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design.	You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad. Another issue that's important is what I call "heterogeneous vs. homogeneous." If implementors/subclasses are homogeneous, tend towards an abstract base class. If they are heterogeneous, use an interface. (Now all I have to do is come up with a good definition of hetero/homogeneous in this context.) If the various objects are all of-a-kind, and share a common state and behavior, then tend towards a common base class. If all they share is a set of method signatures, then tend towards an interface.
Homogeneity	If all the various implementations share is the method signatures, then an interface works best.	If the various implementations are all of a kind and share a common status and behavior, usually an abstract class works best.
Maintenance	If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method.	Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method.
Speed	Slow, requires extra indirection to find the corresponding method in the actual class. Modern JVMs are discovering ways to reduce this speed penalty.	Fast
Terseness	The constant declarations in an interface are all presumed public static final, so you may leave that part out. You can't call any methods to compute the initial values of your constants. You need not declare individual methods of an interface abstract. They are all presumed so.	You can put shared code into an abstract class, where you cannot into an interface. If interfaces want to share code, you will have to write other bubblegum to arrange that. You may use methods to compute the initial values of your constants and variables, both instance and static. You must declare all the individual methods of an abstract class abstract.
Adding functionality	If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method.	If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change.

 

Here are some recommendations to help you to decide whether to use an interface or an abstract class to provide polymorphism for your components.

 

If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

 

Soni

 

 

 

Soni

 

"Programs must be written for people to read, and only incidentally for machines to execute"

Abelson & Sussman, SICP, preface to the first edition

 

Structures in Detail

A struct type is a value type that can contain constructors, constants, fields, methods, properties, indexers, operators, events, and nested types.

The struct type is suitable for representing lightweight objects such as Point, Rectangle, and Color. Although it is possible to represent a point as a class, a struct is more efficient in some scenarios. For example, if you declare an array of 1000 Point objects, you will allocate additional memory for referencing each object. In this case, the struct is less expensive.
It is an error to declare a default (parameterless) constructor for a struct. A default constructor is always provided to initialize the struct members to their default values.

It is an error to initialize an instance field in a struct.
When you create a struct object using the new operator, it gets created and the appropriate constructor is called. Unlike classes, structs can be instantiated without using the new operator. If you do not use new, the fields will remain unassigned and the object cannot be used until all of the fields are initialized.

There is no inheritance for structs as there is for classes. A struct cannot inherit from another struct or class, and it cannot be the base of a class. Structs, however, inherit from the base class Object. A struct can implement interfaces, and it does that exactly as classes do.
Unlike C++, you cannot declare a class using the keyword struct. In C#, classes and structs are semantically different. A struct is a value type, while a class is a reference type. For more information on the features of value types, see Value Types.

Unless you need reference type semantics, a class that is smaller than 16 bytes may be more efficiently handled by the system as a struct.

More info here http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vcwlkstructstutorial.asp

What is the difference between a Struct and a Class?
· The struct type is suitable for representing lightweight objects such as Point, Rectangle, and Color. Although it is possible to represent a point as a class, a struct is more efficient in some scenarios. For example, if you declare an array of 1000 Point objects, you will allocate additional memory for referencing each object. In this case, the struct is less expensive.
· When you create a struct object using the new operator, it gets created and the appropriate constructor is called. Unlike classes, structs can be instantiated without using the new operator. If you do not use new, the fields will remain unassigned and the object cannot be used until all of the fields are initialized.
· It is an error to declare a default (parameterless) constructor for a struct. A default constructor is always provided to initialize the struct members to their default values.
· It is an error to initialize an instance field in a struct.
· There is no inheritance for structs as there is for classes. A struct cannot inherit from another struct or class, and it cannot be the base of a class. Structs, however, inherit from the base class Object. A struct can implement interfaces, and it does that exactly as classes do.
· A struct is a value type, while a class is a reference type.

Also,
There is no inheritance for structs as there is for classes. A struct cannot inherit from another struct or class, and it cannot be the base of a class. Structs, however, inherit from the base class Object. A struct can implement interfaces, and it does that exactly as classes do.

Some stuff from Nasar

The Five Components of Function Points

Data Functions

Internal Logical Files
External Interface Files 
Transactional Functions

External Inputs
External Outputs
External Inquiries

 

Worst Practices - To Avoid!
Make it unclear who is responsible for tasks; don't trust anyone with clear ownership, but ask several people to get the job done.

Keep yourself very busy, so team members will see how valuable you are, even if you have no time to supervise their assignments, solve problems, or monitor work methods.

Assign new team members to tasks without adequate task definitions, guidance or training; use the sink or swim method for work assignments.

Let poor performers continue without comment, and ignore gossip and dissension among project team members.

Reward your excellent performers by giving them an impossible workload; let them be the heroes to carry the project on their backs.

I'm not trying to be negative or sarcastic here, but it is sometimes helpful to describe negative behaviors we want to avoid to help us recognize them and not fall into the traps.

 

Webservices -  How to expose a Type from a webmethod which is not a .NET generic type

Whats the base namespace when you define a .NET class

What is an Architecture?

Can you parse XML data in SQL server. If so how?

 

Soni

 

How to Share Session State

Interesting article in MSDN ...

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

http://searchvb.techtarget.com/vsnetTip/1,293823,sid8_gci951935_tax293033,00.html

 

Maintaining Transactions in Web Services

The TransactionOption Property
If you've ever programmed MTS or COM+ components, you're probably comfortable with the idea of developing transaction-based services. A transaction can be thought of as any set of procedures (e.g., events, function calls) that collectively result in a change of state such as a success or failure. One example is a credit card processing system that authenticates a credit card number, charges the card, and triggers a fulfillment process. If any of these three steps fails (e.g., the card is declined), the transaction as a whole will fail, and each of the individual processes must be returned to its original state (e.g., cancel a fulfillment process if it has been started). All three steps are part of a transaction.

Microsoft includes support in the .NET platform for MTS or COM+ style transactions through the System.EnterpriseServices namespace. We're not going to get into the details of developing transacted services in this book; however, it is important to understand the difference between .NET-style transactions and what we'll call distributed web service transactions.

.NET transaction support is set through the TransactionOption property of the WebMethod attribute. The five possible settings for this property are:

Disabled

NotSupported

Supported

Required

RequiresNew

By default, transactions are disabled. If you decide to use .NET transactions, your web method will be able to participate only as the root object in a transaction. This means that your web method may call other transaction-enabled objects, but may not itself be called as part of a transaction started by another object. This limitation is due to the stateless nature of the HTTP protocol. As a result, the Required and RequiresNew values for TransactionOption are equivalent (and both declare a RequiresNew method that will start a new transaction). Disabled, NotSupported, and Supported all disable transactions for the web method, despite what their names imply.

Soni

"Programs must be written for people to read, and only incidentally for machines to execute"

Abelson & Sussman, SICP, preface to the first edition

Access Modifiers

http://weblogs.asp.net/cnagel/archive/2004/12/27/332733.aspx

The December version of Visual Studio 2005 / C++ now has an internal access modifier instead of using public private. This is different from my previous post. The access modifiers public protected and protected private are still the same as before:

C++	C#	VB	IL
public	public	Public	public
protected	protected	Protected	family
private	private	Private	private
internal	internal	Friend	assembly
public protected	internal protected	Protected Friend	famorassem
protected private	not possible	not possible	famandassem

public public is no longer supported, too. public is good enough ;-)

 

http://builder.com.com/5100-6373-1027680.html

 

Q: I'm confused about what some of the .NET access modifiers mean and when I should use them. Can you help me sort them out?

A: Well, I'll certainly try. The allowed access modifiers in .NET are public, private, protected, internal, and protected internal. These keywords control the visibility of class members (and other things), defining the circumstances under which a member may be accessed—hence their collective name as access modifiers. With the exception of the last, protected internal, it's illegal to combine two access modifiers. Let's look at what each of these mean in turn when used in a .NET class.

Access modifiers illustrated
Public means just that: public and visible to everyone and everything. A public member can be accessed using an instance of a class, by a class's internal code, and by any descendants of a class. This is illustrated in Figure A.

Figure A

A public class member

Private is also intuitively understood, meaning hidden and usable only by the class itself. No code using a class instance can successfully access a private member and neither can a descendant class, as illustrated in Figure B. Information or functionality that will not be needed or has no meaning outside of the context of a specific class should be made private.

Figure B

A private class member

Protected members are similar to private ones in that they are accessible only by the containing class. However, protected members also may be used by a descendant class. So members that are likely to be needed by a descendant class should be marked protected, as Figure C shows.

Figure C

A protected class member

Members marked as internal are public to the entire application but private to any outside applications. Internal is useful when you want to allow a class to be used by other applications but reserve special functionality for the application that contains the class. Figure D illustrates internal in action.

Figure D

An internal class member

Finally, we have the only compound access modifier allowed in .NET, protected internal, which is shown in Figure E. Members marked as protected internal may be accessed only by a descendant class that's contained in the same application as its base class. You use protected internal in situations where you want to deny access to parts of a class' functionality to any descendant classes found in other applications.

Figure E

A protected internal class member

Not limited to controlling class access
As I mentioned before, access modifiers aren't limited to use on class members but can be applied to a few other code constructs. The rules defining when modifiers may be legally assigned to a construct are dependant on the construct's container:

• Interface and enumeration members are always public and no access modifiers are needed (or allowed).
• Classes in namespaces are internal by default and may be either internal or public, while namespaces themselves are always public.
• Members of a struct are private by default and may be given public, internal, or private access modifiers.

In all cases, however, the modifier's meaning remains the same.

 

Soni

 

"Programs must be written for people to read, and only incidentally for machines to execute"

Abelson & Sussman, SICP, preface to the first edition

 

"How can I avoid turning into a pointy-haired boss?"

Read this somewhere .. guess we all need to decide at one point of time or the other.

"The pointy-haired boss is a manager who doesn't program. So the surest way to avoid becoming him is to stay a programmer. What tempts programmers to become managers are companies with old-fashioned corporate structure, where the only way to advance in salary and prestige is to go into management. So if you want to avoid becoming a PHB, avoid such companies, and work for (or start) startups.

I never had to manage anyone in our startup, even though I was the president. The other hackers were my peers, and would have given me the raspberry if I'd tried to "manage" them. We operated by consensus. And the rest of the company reported to our experienced COO, who was also more of a peer.

Why be a manager when you could be a founder or early employee at a startup?"

Inputs from Nikhilesh

To support the CLR, Microsoft has extended the PE/COFF file format to include metadata and IL code. The CLR uses metadata to determine how to load classes and uses the IL code to turn it into native code for execution. The extensions that Microsoft has added to the normal PE format include the CLR header and CLR data. The CLR header mainly stores relative virtual addresses (RVA) to locations that hold pertinent information to help the CLR manage program execution. The CLR data portion contains metadata and IL code, both of which determine how the program will be executed. Compilers that target the CLR must emit both the CLR header and data information into the generated PE file, otherwise the resulting PE file will not run under the CLR.

Looking at this text dump of a .NET PE file, you can see that a PE file starts off with the MS-DOS/COFF header, which all Windows programs must include. Following this header, you will find the PE header that supports Windows 32-bit programs. Immediately after the PE headers, you can find the code section for this program. The raw data (RAW DATA #1) of this section stores the CLR header, as follows:
RAW DATA #1 . . . clr Header: /* CLR HEADER */ 48 cb 2.00 runtime version 207C [ 214] RVA [size] of MetaData Directory 1 flags 6000001 entry point token 0 [ 0] RVA [size] of Resources Directory 0 [ 0] RVA [size] of StrongNameSignature Directory 0 [ 0] RVA [size] of CodeManagerTable Directory 0 [ 0] RVA [size] of VTableFixups Directory 0 [ 0] RVA [size] of ExportAddressTableJumps Directory
Section contains the following imports: mscoree.dll . . . 0 _CorExeMain . . .As mentioned earlier, the CLR header holds a number of pertinent details required by the runtime, including:
Runtime version Indicates the runtime version that is required to run this program
MetaData directory Is important because it indicates the location of the metadata needed by the CLR at runtime
Entry point token Is even more important because, for a single file assembly, this is the token that signifies the entry point, such as Main( ), that the CLR executes
Below the CLR Header, note that there is an imported function called _CorExeMain, which is implemented by mscoree.dll, the core execution engine of the CLR.[2] At the time of this writing, Windows 98, 2000, and Me have an OS loader that knows how to load standard PE files. To prevent massive changes to these operating systems and still allow .NET applications to run on them, Microsoft has updated the OS loaders for all these platforms. The updated loaders know how to check for the CLR header, and, if this header exists, it executes _CorExeMain, thus not only jumpstarting the CLR but also surrendering to it. You can then guess that the CLR will call Main( ), since it can find the entry point token within the CLR header.[3]

The common language runtime can either run garbage collection concurrently on a separate thread or on the same thread as the application. Use the element to specify how the runtime should run garbage collection. For example:
By default, the runtime runs garbage collection concurrently, which reduces performance. If your application is single-threaded and involves heavy user interaction, leave concurrent garbage collection enabled so the application does not pause to perform garbage collection. If your application is an ASP.NET server application, you do not need to alter the default value of the element.

A delegate is a data structure that refers to a static method or to an object instance and an instance method ofthat object.

A component container is a specialized class that acts as a means of organizing and containing components. Through a container you can track your components, communicate with them via the Site that hosts the component, and provide a means of common disposal after they are no longer needed.

What are ASHX Files

ASHX files contain HTTP handlers.
HTTP Handlers are nothing but software modules that handle raw HTTP requests received by ASP.NET
With .ASHX files one can easily deploy HTTP Handlers without modifying IIS metabase.

 

Soni

 

"Programs must be written for people to read, and only incidentally for machines to execute"

Abelson & Sussman, SICP, preface to the first edition

 

What is the maximum amount of memory any single process on Windows can address

Any process running under Windows gets a Virtual Address Space of 4 GB, no matter how much RAM is actually installed on the computer.
Actually, this is essentially the same for all operating systems running on 32 bit hardware that implement Virtual memory.
The only way to increase the size of the virtual address space beyond 4 GB is by using 64 bit hardware with an operating system and application built for that hardware.
In the normal, default Windows OS configuration, 2 GB of this address space are allocated to the process's private use and the other 2 GB are allocated to shared and operating system use.
The nub of it is, that no matter how much physical RAM is in the computer,the amount of memory available in the application's private part of thevirtual address space in 32 bit Windows implementations is limited to:
1. 2 GB - without the /3GB switch - this is the normal, default maximumprivate virtual address space or
2. 3GB with the /3GB switch AND a special application modification (more details below) or 3. any physical RAM not used by the OS and other applications by modifyingthe application to use the AWE (Address Windowing Extensions) API

More on address & memory allocation:
There seems to be a lot of confusion in the industry about what's commonly called the Windows “4GB memory limit.” When talking about performance tuning and server sizing, people are quick to mention the fact that an application on a 32-bit Windows system can only access 4GB of memory. But what exactly does this mean?
By definition, a 32-bit processor uses 32 bits to refer to the location of each byte of memory. 2^32 = 4.2 billion, which means a memory address that's 32 bits long can only refer to 4.2 billion unique locations (i.e. 4 GB).
In the 32-bit Windows world, each application has its own “virtual” 4GB memory space. (This means that each application functions as if it has a flat 4GB of memory, and the system's memory manager keeps track of memory mapping, which applications are using which memory, page file management, and so on.)
This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space.
This can cause problems in Terminal Server environments. On Terminal Servers with a lot of users running a lot of applications, quite a bit of information from all the users has to be crammed into the shared 2GB of kernel memory. In fact, this is why no Windows 2000-based Terminal Server can support more than about 200 users—the 2GB of kernel memory gets full—even if the server has 16GB of memory and eight 3GHz processors. This is simply an architectural limitation of 32-bit Windows.
Windows 2003 is a little bit better in that it allows you to more finely tune how the 2GB kernel memory space is used. However, you still can't escape the fact that the thousands of processes from hundreds of users will all have to share the common 2GB kernel space.
Using the /3GB (for Windows 2000) or the /4GT (for Windows 2003) boot.ini switches is even worse in Terminal Server environments because those switches change the partition between the application memory space and kernel memory space. These switches gives each application 3GB of memory, which in turn only leaves 1GB for the kernel—a disaster in Terminal Server environments!
People who are unfamiliar with the real meaning behind the 4GB Windows memory limit often point out that certain versions of Windows (such as Enterprise or Datacenter editions) can actually support more than 4GB of physical memory. However, adding more than 4GB of physical memory to a server still doesn't change the fact that it's a 32-bit processor accessing a 32-bit memory space. Even when more than 4GB of memory is present, each process still has the normal 2GB virtual address space, and the kernel address space is still 2GB, just as on a normal non-PAE system.
However, systems booted /PAE can support up to 64GB physical memory. A 32-bit process can "use" large amounts of memory via AWE (address windowing extension) functions. This means that they must map views of the physical memory they allocate into their 2GB virtual address space. Essentially, they can only use 2GB of memory at a time.