Don't worry. Not everyone knows it...

ArrayList alist = new ArrayList(); // From remote machine Process [] processes = Process .GetProcesses( "RemoteComputerName" );  // From local machine Process [] processes = Process .GetProcesses();     foreach ( Process process in processes) {        alist.Add(process.ProcessName); }

Following is the list of some shortcomings: Static/shared members: COM objects are fundamentally different from .Net types. One of the differences is lack of support for static/shared members. Parameterized Constructors: COM types don't allow parameters to be passed into a constructor. This limits the control you have over initialization and the use of overloaded constructors. Inheritance: One of the biggest issues is the limitations COM objects place on the inheritance chain. Members that shadow members in a base class aren't recognizable, and therefore, aren't callable or usable in real sense. Portability: Operating Systems other than Windows don't have registry. Reliance on Windows registry limits the number of environments a .Net application can be ported to.

Every once in a while, VS seems to take forever to display a screen to the point that it seems to hang. Most of the time, it hangs, while accessing Fonts and Colors page in Tools/Options dialog. The issue is not that there is some weird code that executes very slowly. It happens that this page is implemented using .NET components. Now the majority of VS is built with native code and during most of its execution,, the CLR is never loaded. However, when the user accesses one of these features, the CLR must be loaded, before we can begin executing the relevant IL. It is this process that is time-consuming and annoying to the user. There are two problems for the users here: first, there is no feedback during loading of the CLR; second: the problem can occur multiple times within a single session of VS. I am trying to figure out the reason for this second issue. Let me know, if any of you knows.

As we all know, C# doesn't support optional parameters(till framework 3.5) whereas VB does.In the same way, COM components don't support parameter overloading , so for each value in a parameter list, we've got to pass in something, even if it does nothing. Moreover, COM parameters are always passes by reference , which means we can't pass NULL as a value. In VB 2005, this is not really as issue because it supports optional parameters and we can just leave them out. But C# doesn't support this, so one have to create object variables and pass them in. See following code sample: u sing Microsoft.Office.Core; u sing Microsoft.Office.Interop.Excel;  // Must have office installed Application NewExcelApp = new Application; NewExcelApp.Worksheets.Add();       // This will not compile So, as a workaround, the Type.Missing field can be used and this field can be passed in with the C# code and the application will work as expected.  Check it in below code...

Following steps are necessary to make an assembly visible to a COM component: Set the Register for COM option under the build configuration Set the ComVisible attribute to true for each class you want exposed Set the ComVisible attribute to false for any class members you want hidden Set the ComVisible attribute to true for any class members that you want visible CodeProject

Foreach will be faster as it usually maintain no explicit counter, like while and do-while.  Foreach essentially say " do this to everything in this set ", rather than " do this x times ". This will potentially avoid off-by-one errors and make code simpler to read.

Assume that you are creating a strong named MyAssembly that will be used in several applications. The assembly will be rebuilt frequently during the development cycle. But one must ensure that every time MyAssembly is rebuilt, it works properly with all applications that use it. So, in order to obtain this, we are required to configure the computer on which we develop the assembly such that each application uses the latest build of MyAssembly. To accomplish the above task, take the following action: To point to the build output directory for the strong named assembly, create a DEVPATH environment variable Add the following element to the machine configuration file:   <developmentMode developerInstallation="true"> . T his element tells the CLR to use DEVPATH to locate assembly. CodeProject