Module's of Running Processes show all the related API's

Let’s assume a programmer like you and me desires to write a program in WinForms. We open visual studio and use a programming language, like Visual Basic or C#. Whatever language we choose, the resources to write the program is called the .Net Framework. The .Net Framework is a collection of libraries that we write our code. If we write our program only using the .Net Framework libraries then our code is 100% managed code.

 

If we add any library or assembly to our visual studio project references other than the .Net Framework, then we have added unmanaged code. Common unmanaged assemblies would be like using MS Word, Excel, Access object libraries requiring the use Interop, but there are many others like PCOMM or Lenel PCOMM and Lenel are two that I am familiar with.

 

Example: using Excel = Microsoft.Office.Interop.Excel;

 

Example: PCOMM.autECLConnList connection = new autECLConnList();

 

PCOMM for example is not in the .Net Framework but it is an object library I could add via references and use its classes. This is unmanaged code.

 

The take away from this explanation is If one strictly uses the .Net Framework without any foreign reference then your project 100% managed code. Anything added outside the .Net Framework in unmanaged code.

 

Next concept:

 

In the .Net Framework library is a namespace called Reflection. Because the Reflection Namespace is in the .Net Framework its managed code.

 

I can use available classes in the Reflection namespace to inspect assemblies, just as you describe in your post.

 

You wrote the following:

“The user would be enable to select the running process and the monitoring of that process is started which shows the list of all the API's related to the modules of running processes. Now' i am stuck on a point that how i will show the list of API's that is being used in the running process.”

 

The Reflection Namespace would accomplish all this and more. There’s just one problem, however.

 

There are thousands and thousands of assemblies, APIs and Modules out there that are created not using the .NET Framework, in other words unmanaged code. The Reflection Namespace works best on managed code not unmanaged code. In other words, applications developed using the .Net Framework.

 

From Microsoft

“The System.Reflection namespace contains types that retrieve information about assemblies, modules, members, parameters, and other entities in managed code by examining their metadata. These types also can be used to manipulate instances of loaded types, for example to hook up events or to invoke methods. To dynamically create types, use the System.Reflection.Emit namespace.”

 

For example, if use the Assembly class in the Reflection namespace and attempt to open Notepad.exe in order to examine all Notepad.exe assemblies and dependencies, it going to crash. Why? Because Notepad is unmanaged code. It wasn’t develop using the .Net Framework.

 

Next Concept:

 

There is a free product called Dependency Walker.

 

http://www.dependencywalker.com/

 

Whoever wrote this application has figured out a proprietary means of examining all kinds of assemblies that outperforms the .Net Framework’s Reflection Namespace. Because someone has developed such a tool, its possible to write an application that does this, like the one you want to write.

 

I just don’t know how it can be one outside of the context of Visual Studio. You can accomplish this in Visual Studio as long as the assemblies being inspected are managed code. But again, how many assemblies out there are not written using Visual Studio’s .Net Framework. Realizing this, you may question if Visual Studio C# is the right tool for such an endeavor. You may have to use C++ and then find reliable, tested libraries in order to inspect any assembly regardless of how it was developed.