Split a large application

[Mike TI]

Nov 13, 2007

Hi all

I have an application that comprises of three modules.

Initially a screen is displayed. Upon selection from a menu on this screen,
module 1, module 2 or module 3 is invoked. Please note here that some
variables defined as public in the initial screen are used by the modules.

Now my question is that is there a way I can split the application. If yes
what should I do so that the EXE is as small as possible.

Thank you.

Mike TI

[rowe_newsgroups]

On Nov 13, 8:37 pm, "Mike TI" <[e-mail]:

Nov 13, 2007

Hi all

I have an application that comprises of three modules.

Initially a screen is displayed. Upon selection from a menu on this screen,
module 1, module 2 or module 3 is invoked. Please note here that some
variables defined as public in the initial screen are used by the modules.

Now my question is that is there a way I can split the application. If yes
what should I do so that the EXE is as small as possible.

Thank you.

Mike TI

What do you mean by split and why exactly do you want to split the
application? I'm guessing this is old old legacy application, which in
my opinion it's framework should either be kept as-is with minimal
changes (to prevent subtle bugs from creeping in) or to rewrite it
with a new "split" framework. Changing an application's structure is
rather dangerous (imo) and shouldn't be done without a very good
reason.

Thanks,

Seth Rowe

[Spam Catcher]

"Mike TI" <ta*****@creativepk.comwrote in
news:uN*************@TK2MSFTNGP04.phx.gbl:

Now my question is that is there a way I can split the application. If
yes what should I do so that the EXE is as small as possible.

You can load parts of the application dynamically using pluggable DLLs.
Very easy to do in .NET once you understand how reflection works.

[Cor Ligthert[MVP]]

Seth

Completely my idea, this to show that the answer from Spam Catcher is that
completely not.

:-)

Cor

[Michel Posseth [MCP]]

Wit the information given by the TS i believe that Spam Catcher`s answer is
pretty good , i could have given the same answer

Fact is that using Reflection wil give him a smaller exectutable , faster
startup of the main executable , a modulair design ( wich is enforced by the
interfaces that need to be used with reflection ) and even the posibility
to upgrade the main app by just simply extending some dll`s ( plugin
design )

Ofcourse the TS could also split his app to a multi tier design ( if
possible ) or what we do in our curent project create a main interface
executable that starts child executables each with there own specific tasks
..

"There are many roads to Rome , but if i need to bring something to France
first it is foolish to go through Germany"

So unless the TS gives some more detailed info about how the curent state is
, requirments , current problems etc etc etc every answer given here could
be striked away as a wrong answer if you have enough fantasy to fill in the
above gaps

just my thoughts :-)

Michel

"Cor Ligthert[MVP]" <no************@planet.nlschreef in bericht
news:65**********************************@microsof t.com...

Seth

Completely my idea, this to show that the answer from Spam Catcher is that
completely not.

:-)

Cor

[Cor Ligthert [MVP]]

Michel,

Is it not more efficient to make first from the modules non static Classes
if real modules are used as written by the OP.

That would in my idea be a better start, however you was asking about more
information and that was in my idea the best to do before giving an answer.

What do you mean by split and why exactly do you want to split the
application? I'm guessing this is old old legacy application, which in
my opinion it's framework should either be kept as-is with minimal
changes (to prevent subtle bugs from creeping in) or to rewrite it
with a new "split" framework. Changing an application's structure is
rather dangerous (imo) and shouldn't be done without a very good
reason.

Cor

[Cor Ligthert[MVP]]

Sorry for mixing you and Seth

Please read my message how it was intended.

Cor

[Michel Posseth [MCP]]

Well i already thought your previous answer was a bit odd :-)

But i also hope you get my point , Seth is making an asumption of what the
situation of the TS is , if he is right well then he might point him in the
right direction with his provided answer .

However the TS did not provide enough info, so it could be that Spam
catcher`s answer is more right as Seth`s as it is aiming at a total
different situation ,
that is the situation where the program can be easily broken up in self
containing modules and started when needed .

As i mentioned above in the thread there ar more design posibility`s to
acomplish the TS`s goal ( creating a smaller executable ) however wich one
i would choose would depend on the situation, wich is by this time unknown
to all of us.

Regards

Michel Posseth

"Cor Ligthert[MVP]" <no************@planet.nlschreef in bericht
news:B6**********************************@microsof t.com...

Sorry for mixing you and Seth

Please read my message how it was intended.

Cor