Multiple Instances of Application

[Guest]

Hey gang.

This is a different question than most when it comes to multiple instances
of an application. We want to run multiple instances of our EXE.

In the past inside our "parent" application we would shell execute the EXE
multiple times and changing the window text was a "hack" which would allow us
to run multiple copies of our application at once.

It seems in the new .NET CF 2.0 SP2 this has changed and no longer works.
We've tried to create a new AppDomain and use the execute command but
unfortunately the parents application GUI window is non-functional when doing
this. And we also suspend that memory is shared within all of these multiple
applications since they are within the same process, which is also an issue
for us.

Does anyone have any knowledge or information on if this is possible via
other means?

We have some options such as copying our exe each time we want to run it
seperately but this isn't really a good approach. We would like to implement
a much cleaner approach if possible.

Any help would be greatly appreciated.

Thanks and take care,
Simon

 

[Paul G. Tobey [eMVP]]

Well, the cleaner approach is 'don't do that'. If you need multiple
windows, then implement your one application so that it has those. It
sounds like you're mixing us up between what you want to do (which sounds
like 'have multiple documents open'), and *how* you want to do it (which is
almost irrelevant). Give us some information about what you get from the
ability to run multiple copies of the app or how the user is going to get
goodies from it. I think that will get you the best answer.

Paul T.

 

[Guest]

Good afternoon Paul,

Thanks for the reply.

Unfortunately I can't disclose too much about what the application does but
it is an enterprise level mobile application which re-engineering the way
everything is laid out is not really an option at the moment since we are
late in our release cycle.

Basically we have 1 application which is running all the time. If you kill
it, it respawns. It is the parent application. From this application it can
execute he child application multiple times. When the child application is
complete, it simply exits.

The child application is very memory intensive and because of previous
process memory limits, having it in a seperate application helped us get
around this. Also to note we can't load/unload DLL's dynamically on the CF
(even if we could we would reach our process memory limit anyways).

After doing some research the #NETCF_AGL_PARK_(application path) window
title if changed does not seem to work as in the case previously.

After looking into the window class name I have a feeling it may be using
this. But I don't believe there is a way to dynamically change this class
name.

Is there any way to make this work? The real ugly hack is to dynamically
copy our EXE to app2.exe, app3.exe every time we want to launch the
application but this is not very clean and also takes up storage space for no
reason.

Any help would be greatly appreciated.

I'm not sure I understand why functionality like this is not available to
the developer. I understand why its a good idea for default applications, as
it makes the device seem much more snappy when things minimize rather than
close etc. However if the developer wants to explicitly define the
application to not behave in this manner and allow multiple instances of the
same application to run, shouldn't that be their option?

Sorry for the rant but I am a bit confused

As mentioned any help would be greatly appreciated and welcome any comments,
suggestions and information you may have.

Thanks and take care,
Simon

 

[Paul G. Tobey [eMVP]]

I'll ask around and see if anything surfaces (it's still morning here so
that gives me more time, right? ;-). You're doing this in .NET CF 2.0 or
2.0SP1? Or both?

Paul T.

 

[Guest]

Our initial development was done on CF1 now were trying to keep pace with
what devices come default installed so we've moved to CF2 and now CF2 sp2.

Ideally we would like to support as many frameworks as possible but as far
as I know this has been the first time this behavior has changed.

Thanks for the help, really appreciate it.

Thanks and take care,
Simon

 

[Paul G. Tobey [eMVP]]

Take a look at Daniel's Web site/blog:

http://www.danielmoth.com/Blog/2005/12/netcfagl.html

That might be enough to tell you what you are able to do. It seems pretty
clear that you aren't going to be able to have one set of code that will
work in both .NET CF 2.0 and 1.0 without having that code check which
framework it's running against.

Paul T.

 

[Paul G. Tobey [eMVP]]

Here's what came from the team itself. Since we don't really have much
detail on what you're doing, it's a bit hard to recommend "do this",
however:

Background: We did change the logic for detecting multiple instances of the
same application from looking for the parking window title to looking for
the parking window class name. This change was because find window by title
uses WM_GETTEXT messages which would hang if a window didn't respond to the
message.

-- Possible work-around for you: If the spawned application avoids creating
forms or any other UI elements (controls), no parking window class will be
registered for the application and multiple instances should be able to run.

So, if your child processes are data processing bits, not UI bits, this is a
nice easy fix for you. You'd have to change the type of application to
something with no head is all (console application).

-- And, if that won't work for you: If the spawned application must use
some UI, a potentially more palatable version of the workaround (not that
this is "recommended"), would be to create multiple copies of a minimal
shim/launcher (e.g. shim00.exe - shim19.exe) which then immediately calls
into the real workhorse code in a shared assembly. This would minimize the
impact on the file system of having multiple copies of the application.

So, if you're hell-bent on keeping everything as it is, this is how you'll
have to go, unless there's no UI in the child processes. I think I'd plan
some time in the next development cycle to really address this...

Paul T.

 

[Guest]

Good morning Paul,

Thanks for the reply. Your comments confirm what we had figured.

Unfortunately our child application is a GUI application so it looks like
our current codebase is not going to be easily compatible. We are going to
have to go with the multiple exe copies approach for now. Unfortunately we
are going to have to sign each one.

I would like to suggest however that I still believe the application
developer should be able to explicitly define if they wish their application
to run multiple instances. I can understand how the device should act this
way by default, but if I wish to set my own application to run multiple
times, I should be allowed to set this somehow.

As far as re-engineering the layout of our framework we will have to do this
for the next version however we are going to be doing much testing on memory
consumption and garbage collector performance & max memory per process before
doing so.

Again thanks so much for your help.

Thanks and take care,
Simon

 

[Paul G. Tobey [eMVP]]

So move the basic code for your UI child application into a shared assembly
and build a little shim program that you can rename into Program01.exe,
Program02.exe, etc. Each instance of that would then call into the share
assembly to run the actual code.

OK. I suppose that Microsoft is thinking that, since it's required that
only one copy of a program be running at a time in order to meet the
requirements for logoing for Windows Mobile, there's no reason to put a back
door in.

Paul T.

 

[Guest]

I suppose but I am asking why not allow the application developer the option
to explicitly set for their application.

I guess I don't understand why this has to be a hard set rule rather than a
default.

Thanks and take care,
Simon

 

[Paul G. Tobey [eMVP]]

*Very* few people have had complaints about it, so I think that Microsoft
would probably call it a design error on your end, rather than a severe
limitation on the part of the framework...

Good luck,
Paul T.