DLL in use at next deploy

[Philip Grace]

Hi,

I am building an application that uses the dotNetRemoting library. The dll's
(ISerial.dll etc) associated are sent down with each deploy to the device
(not a probem since they're quite small). However, when I run my app, the
dll's stay loaded when it terminates, which means that the only way I can
deploy again is to warm boot the device (Symbol MC70).

Anyone got any thoughts as to how this can be made a little easier.

Cheers,
Philip.

 

[Paul G. Tobey [eMVP]]

Are you sure that the application *is* being terminated? The X on the title
bar, of course, does *not* terminate the application. That's the typical
confusion...

Paul T.

 

[Delicioustian]

Settings->Memory->Running Applications->Close All.

..X. means this.Hide() not this.Dispose()

 

[Philip Grace]

Hi,

Now you mention it no.

I decided to start just copying the exe file rather than rebooting which is
when I discovered that the exe was still in use too. This is despite the
fact that it does NOT appear in the Settings->Memory->Running Applications
list ?

I am not closing the app with the title bar X, rather with a VB close()
command.

Phil.


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:[email protected]...

 

[Philip Grace]

Should also mention that when my application closes, the "egg timer" cursor
is visible for AGES afterward.

Philip


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:[email protected]...

 

[Guest]

Settings->Memory->Running Applications simply shows the captions of top
level forms. It's not at all an idicator of processes running.

Calling Close() may work, but it's not necessarily the best route. It
simply closes the form. *if* the Form was the one passed to Application.Run
(which VB nicely hides for you in a default project) then Application.Run
will then return. In *most* applications execution will then leave Main and
the app will shut down.

There are times when that's not the case though:

1. If you have a thread running that's not a background thread (which is any
thread in CF 1.0). This thread may not necessarily have been explicitly
created by you.
2. If the Close call was made for a form other than what was passed to
Application.Run. Only that form instance can stop the message pump.
3. If code exists after the Application.Run call that might block


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

Hi,

Now you mention it no.

I decided to start just copying the exe file rather than rebooting which
is when I discovered that the exe was still in use too. This is despite
the fact that it does NOT appear in the Settings->Memory->Running
Applications list ?

I am not closing the app with the title bar X, rather with a VB close()
command.

Phil.


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:[email protected]...

Are you sure that the application *is* being terminated? The X on the
title bar, of course, does *not* terminate the application. That's the
typical confusion...

Paul T.

 

[Philip Grace]

Thanks for the pointers, I managed to find the cluprit (Barcode scanner
component was still active and I imagine it runs in it's own thread), and
all is now ok.

Philip.

Settings->Memory->Running Applications simply shows the captions of top
level forms. It's not at all an idicator of processes running.

Calling Close() may work, but it's not necessarily the best route. It
simply closes the form. *if* the Form was the one passed to
Application.Run (which VB nicely hides for you in a default project) then
Application.Run will then return. In *most* applications execution will
then leave Main and the app will shut down.

There are times when that's not the case though:

1. If you have a thread running that's not a background thread (which is
any thread in CF 1.0). This thread may not necessarily have been
explicitly created by you.
2. If the Close call was made for a form other than what was passed to
Application.Run. Only that form instance can stop the message pump.
3. If code exists after the Application.Run call that might block


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

Hi,

Now you mention it no.

I decided to start just copying the exe file rather than rebooting which
is when I discovered that the exe was still in use too. This is despite
the fact that it does NOT appear in the Settings->Memory->Running
Applications list ?

I am not closing the app with the title bar X, rather with a VB close()
command.

Phil.


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:[email protected]...

Are you sure that the application *is* being terminated? The X on the
title bar, of course, does *not* terminate the application. That's the
typical confusion...

Paul T.

Hi,

I am building an application that uses the dotNetRemoting library. The
dll's (ISerial.dll etc) associated are sent down with each deploy to
the device (not a probem since they're quite small). However, when I
run my app, the dll's stay loaded when it terminates, which means that
the only way I can deploy again is to warm boot the device (Symbol
MC70).

Anyone got any thoughts as to how this can be made a little easier.

Cheers,
Philip.