This may sound like a simple topic, however for someone who is quite new to .NET and used to Visual Studio 6 (VB6!!!) this was quite a difficult thing.

To set the scene, developers who have created ActiveX DLL's in Visual Studio 6 know that you can just run the DLL within the IDE.  You can then reference the DLL, as per normal, within any other application. You can then add break points, watches and use the immediate window to aid debugging.  You can even have multiple copies of Visual Studio 6 running, and have them reference each other.  This was easy, intuitive and the way it was done.

However, within .NET things are a little different.  You cannot just run the DLL, and access it from an external app, within the IDE and get all of the debugging features.

To begin with, you cannot create an ActiveX DLL project you have to tell the compiler (using code) that the class can be exposed as COM.  Thus, the IDE cannot tell (until things are compiling\running) what your intentions are for the class.

If you try running a class library, Visual Studio will tell you:

"A project with an Output Type of Class Library cannot be started directly.

In order to debug this project, add an executable project to this solution which references the library project."

It is my understanding that DLL's do not run within their own process, they must be hosted by another application.  If your solution does not have an application, Visual Studio cannot spawn a process to host the DLL.  

While creating a dummy executable application, within the solution, allows some rudimentary testing of the classes it is not as good as getting the data directly from the calling application.  I want to be able to see what data was passed into the DLL, what functions were called, when and in what order.

Some might think that you can create the dummy application, run it and host the DLL and then be able to access the DLL from another application.  Unfortunately, a COM interface run by Visual Studio is not registered and thus only the spawning application (your dummy app) has access to the DLL.  You cannot run a dummy application within your solution and expect applications outside the solution to be able to access the DLL.

To debug a .NET COM DLL within the IDE, and access it from another application, it must be that external application which spans\hosts the DLL.  You must tell the IDE what process is going to spawn/host the DLL.

To do this:

• right-click on the COM project, and select "Properties".
• select the Debug tab
• select "Start external program" option, under "Start Action"
• browse for, and find, the application that calls your COM DLL
• if need be, add "Command line arguments"

Image below is of an example setup.