Invoke a Class in a DLL

[DGS]

:confused:

 

Hi

 

Does anyone know how I can invoke a class in a DLL (which actually displays a Windows form) but leave that class running after the calling application closes? I'm using VB.NET 2003.

 

Many thanks,

David.

[Rodenberg]

If I understand your question correctly that wouldn't be possible, as the invoked class would only exist within the application domain of the calling method, which would be cleared from memory when the application closes.

 

If you don't mind elaborating a bit on what it is you are trying to accomplish, maybe someone could suggest some more suitable alternatives for you to consider.

[DGS]

Hi - My thoughts too.

 

The problem at hand is to run an update to the executable and its associated assemblies into the current location.

 

As the executable is executing it can't be overwritten. Hence I want to start the update process - shut down the calling assembly but let the called assembly continue its work.

 

I've achieved this perfectly well with an EXE and using the process.start methodology - however it would be neater to bundle this function as a DLL so interested users don't double-click the updater.exe assembly just to "see what happens"!

 

I think that creating a Win32 DLL and calling it via Rundll32 might be an option - but I've no idea if this can be created from VB.NET? ;)

[mooman_fl]

I've achieved this perfectly well with an EXE and using the process.start methodology - however it would be neater to bundle this function as a DLL so interested users don't double-click the updater.exe assembly just to "see what happens"!

Make your separate EXE and call it normally with an undocumented commandline argument Like "update.exe -updateme"... when update.exe is started it will check for the -updateme argument. If it isn't there then it shuts down before displaying the update dialog. If it is there then it knows it was called by your program and continues as normal.

[DGS]

Hi

 

This is pretty much what I've done. There are four command line parameters used to invoke the job correctly. If any are missing the form never appears. Sadly - I know what some users are like.

 

Imagine: Double-click. Nothing happens. Double-click. Nothing happens. Call support "What's this program..."

 

Hence my desire to wrap it all up in a library! :)

[mooman_fl]

LOL... put it in your FAQ

[Nerseus]

We use a similar approach, but there are no command line args. Instead, an XML config file is delivered with the "loader" application. The "loader" reads the XML file to figure out where to find the latest EXE (in fact, what the EXE's name is and more).

 

If the config isn't found, a "default" server can be searched for the config file. So if compiled with the right "default" server, you could conceivably only deliver the EXE. In practice, our "deployment" requires both the EXE and config file.

 

Want to talk cool? Have the "loader" detect updates and update itself (new default server, new config files, etc.).

 

-nerseus