By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,333 Members | 1,022 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,333 IT Pros & Developers. It's quick & easy.

Running DLLs

P: n/a
In VB6, it's possible to create a project with a class library within it.
The project can then be run with F5, and it sits and waits for an external
process to create an instance of one of its objects. This is extremely
useful, as it allows me (for example) to create a PlugIn class running in
source, and call it from a host application that is running as an
executable.

In VB.NET, I'm not allowed to run class library projects, I simply get an
error message: "A project with an Output Type of Class Library cannot be
started directly. In order to debug this project, go to the Debugging tab
under Configuration Settings in Project Properties, and set the Start Action
to Start External Program or Start URL. Alternatively, you can add a
non-library project to this solution that uses a reference to this project
and set it as the startup project."

This is really frustrating. I can obviously launch the host app via the
Start Action, or I can add the host app's source code to my solution, but in
either case I need to close the host app in order to get back into the
PlugIn source to make any changes. The app in question has a fairly involved
and slow startup procedure, and re-running and then closing the application
over and over again gets very tedious very quickly.

Some questions:

- is there a better way to do this?

- does this scenario change at all in VS2005?

My thanks in advance,

--

(O)enone
Nov 21 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Don't worry, there is a way!

Under the Debug menu, there is Processes menu option. This lists all the
currently running processes on the machine. If there is an application
using your dll, select this process and click Attach.

Point to note:

In order to debug the dll, prior to running the .exe, you'll need to compile
the dll in DEBUG mode and put the dll and pdb file in the same directory as
the exe.

You can do this with a VB6 app running in the IDE too. Simply attach to the
VB6 process.

L.
"Oenone" <oe****@nowhere.com> wrote in message
news:Ov**************@tk2msftngp13.phx.gbl...
In VB6, it's possible to create a project with a class library within it.
The project can then be run with F5, and it sits and waits for an external
process to create an instance of one of its objects. This is extremely
useful, as it allows me (for example) to create a PlugIn class running in
source, and call it from a host application that is running as an
executable.

In VB.NET, I'm not allowed to run class library projects, I simply get an
error message: "A project with an Output Type of Class Library cannot be
started directly. In order to debug this project, go to the Debugging tab
under Configuration Settings in Project Properties, and set the Start Action to Start External Program or Start URL. Alternatively, you can add a
non-library project to this solution that uses a reference to this project
and set it as the startup project."

This is really frustrating. I can obviously launch the host app via the
Start Action, or I can add the host app's source code to my solution, but in either case I need to close the host app in order to get back into the
PlugIn source to make any changes. The app in question has a fairly involved and slow startup procedure, and re-running and then closing the application over and over again gets very tedious very quickly.

Some questions:

- is there a better way to do this?

- does this scenario change at all in VS2005?

My thanks in advance,

--

(O)enone

Nov 21 '05 #2

P: n/a
Landley wrote:
Don't worry, there is a way!

Under the Debug menu, there is Processes menu option. This lists all
the currently running processes on the machine. If there is an
application using your dll, select this process and click Attach.


Thanks for that -- that's very interesting and nearly does what I want. :-)

The only problems I'm having with this are:

- the assembly I'm debugging (in the IDE) is actually loaded (by the hosting
..exe) using Reflection.Assembly.LoadFrom(), pointing it at the .dll that has
been compiled in the bin/ directory. This works fine, but the running .exe
appears to be locking the .dll file. Once I've done this once, further
compilations fail because it can't copy the compiled .dll to the output
directory. Is there something I need to do to prevent this file lock from
occurring?

- having to compile the DLL, open the Processes window, select the running
..exe and then close the window is a LOT more work than just pressing F5. Is
there some way to automate this so that I can just use a single keypress to
get all these steps to execute?

Many thanks,

--

(O)enone
Nov 21 '05 #3

P: n/a
When compiling the DLL in debug, you must ensure that anything using this
DLL is not running.

Once compiled, run the application and then attach to the process.
Attaching to the process will not rebuild or need write access to the DLL.

As for attaching to a process being a lot more work, like with everything
else in .NET, it's more work but you have more flexibility!

Landers.


"Oenone" <oe****@nowhere.com> wrote in message
news:eL*************@TK2MSFTNGP15.phx.gbl...
Landley wrote:
Don't worry, there is a way!

Under the Debug menu, there is Processes menu option. This lists all
the currently running processes on the machine. If there is an
application using your dll, select this process and click Attach.
Thanks for that -- that's very interesting and nearly does what I want.

:-)
The only problems I'm having with this are:

- the assembly I'm debugging (in the IDE) is actually loaded (by the hosting .exe) using Reflection.Assembly.LoadFrom(), pointing it at the .dll that has been compiled in the bin/ directory. This works fine, but the running .exe
appears to be locking the .dll file. Once I've done this once, further
compilations fail because it can't copy the compiled .dll to the output
directory. Is there something I need to do to prevent this file lock from
occurring?

- having to compile the DLL, open the Processes window, select the running
.exe and then close the window is a LOT more work than just pressing F5. Is there some way to automate this so that I can just use a single keypress to get all these steps to execute?

Many thanks,

--

(O)enone

Nov 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.