.NET Basics

There are 2 things I would like to get cleared whose answers I could not find anywhere else:
1) Making different applications to communicate in a seamless way is one of the most important advantages on .NET. However, even COM makes this possible. But COM requires a lot of routine plumbing that .NET does not. But Windows (including the new Vista) still rely on COM heavily.
Does all this mean that .NET is completely foreign to COM. I dont mean to say, that they cannot communicate.
What I am asking is that the code that goes into the CLR, the Base Class Library etc. etc. itself uses COM internally or not

2) The second thing is that .NET applications ae JIT compiled at run-time. This provides them the advantage of being compiled specifically for the hardware they will run on. But this incurs a bit of performance loss, had they been translated to native code earlier.
Now, the hardware the application will run on is known when the application is installed on it. So, wouldn't it be a good idea to transalte the code to native code when the application is being installed, as that will provide a further performance boost at run-time
What is the reason that majority of .NET & Java applications are compiled only at run-time & not install time

.NET Development7

1] The .NET runtime is heavily dependent on COM to get its job done. The Marshal class, various COM attributes and the tlbimp.exe utility makes working with legacy COM components easy.
2] Ngen.exe was designed to do what you're asking for. While it will improve app startup time, it cannot yet meet the performance of JIT compiled code. Check this article for the details.

Thanx,
But can you explain a bit more on the COM aspect of .NET. I mean COM is associated with difficult, tricky interface programming. And .NET does an awesome job in that respect.
Why is that the designers of .NET had to use COM in .NET internally. Has it something to do with the way Windows itself is laid out, that you have to resort to COM for low-level plumbing jobs. And does that mean that COM will be with us forever, if not externally, than internally hidden behind layers of abstraction

While the .NET runtime presents a well designed and clean virtual machine model to managed code that doesn't require COM anymore, under the hood, there is a big chunk of unmanaged code to make that work. That code can be manipulated; it has interfaces for de****s, profilers and allows the runtime to be hosted (SQL 2005 for example). The only interop method available to do this in unmanaged code is COM.

Additionally, MSFT has a large investment in COM code that solves problems that the .NET runtime needs to solve too. Marshaling a delegate call into a thread for example. They used the COM API to get the job done.

Yes, COM is going to be around for a long time. For example, shell programming requires COM and cannot be safely done with .NET. I expect that someday MSFT will decide to break backwards compatibility and create a new shell that works with .NET. That's going to be a while though...

That was a great reply... Thank you very much...

I also expect MSFT to break that backward compatibility, but want them to do it soon..
Anyways, I still have some queries lurking in my mind... But as of now, I am trying to mold them into more sensible questions.
I will get back when I do that.
Thanxs again very much for those cool replies