AppDomain for Multiple Instances?

[Richard MSL]

I have an application that works, now I want to make the user able to run
several menu options at the same time. So they could choose option A from the
menu, be interacting with it, then choose option B also, and switch between
the two of them. The two options share the same code, but I do not want them
to interact at all in terms of sharing data.

Is the use of AppDomains the right way to do this? I would run
AppDomain.ExecuteAssemblyByName, and it would start a new domain with option
A, then when the user chooses option B, it would have its own AppDomain for
B. Is that what AppDomains are for?

I have not worked with AppDomains before, I just wanted some indication that
this was what they are for, and the right way to do this, before I spend a
lot of time learning how they work. Thanks very much.

[Richard MSL]

Thanks for your reply. The application is basically WinForms, with some C and
C++ functions that it uses. We have attempted to make separate data, but we
have lots of interactions between the sessions. Would starting a thread for
it help, it seemed to me that another thread would share the data anyway,
unless it was in a separate AppDomain. Thanks.

"Vadym Stetsyak" wrote:

Hello, Richard!

What application you're talking about, WinForms?

Why can't you create 2 copies of data and let each option work with its
own copy?

IMO AppDomains isn't the option for you.

RMI have an application that works, now I want to make the user able
RMto run
RMseveral menu options at the same time. So they could choose option A
RMfrom the
RMmenu, be interacting with it, then choose option B also, and switch
RMbetween
RMthe two of them. The two options share the same code, but I do not
RMwant them
RMto interact at all in terms of sharing data.

RMIs the use of AppDomains the right way to do this? I would run
RMAppDomain.ExecuteAssemblyByName, and it would start a new domain
RMwith option
RMA, then when the user chooses option B, it would have its own
RMAppDomain for
RMB. Is that what AppDomains are for?

RMI have not worked with AppDomains before, I just wanted some
RMindication that
RMthis was what they are for, and the right way to do this, before I
RMspend a
RMlot of time learning how they work. Thanks very much.
--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot

[Vadym Stetsyak]

Hello, Richard!

In what form data "lives" in your application? How do you access it?

Is it possible to make a copy of that data?

You wrote on Thu, 9 Nov 2006 11:40:01 -0800:

RMThanks for your reply. The application is basically WinForms, with
RMsome C and
RMC++ functions that it uses. We have attempted to make separate data,
RMbut we
RMhave lots of interactions between the sessions. Would starting a
RMthread for
RMit help, it seemed to me that another thread would share the data
RManyway,
RMunless it was in a separate AppDomain. Thanks.

RM"Vadym Stetsyak" wrote:

>Hello, Richard!

>What application you're talking about, WinForms?

>Why can't you create 2 copies of data and let each option work with
its
own copy?

>IMO AppDomains isn't the option for you.

> RMI have an application that works, now I want to make the user
able
RMto run
RMseveral menu options at the same time. So they could choose option
A
RMfrom the
RMmenu, be interacting with it, then choose option B also, and
switch
RMbetween
RMthe two of them. The two options share the same code, but I do not
RMwant them
RMto interact at all in terms of sharing data.

>RMIs the use of AppDomains the right way to do this? I would run
RMAppDomain.ExecuteAssemblyByName, and it would start a new domain
RMwith option
RMA, then when the user chooses option B, it would have its own
RMAppDomain for
RMB. Is that what AppDomains are for?

>RMI have not worked with AppDomains before, I just wanted some
RMindication that
RMthis was what they are for, and the right way to do this, before I
RMspend a
RMlot of time learning how they work. Thanks very much.

>--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot

--
With best regards, Vadym Stetsyak.
Blog: http://vadmyst.blogspot.com

[Richard MSL]

Most of the data is in a SQL database, so it is fine, it handles multiple
users. There is also program data, that is on the C side. The C program calls
into C#, the C# does not have data saved from call to call. But the menu is
in C#, which calls different C functions, which in turn call C# functions for
the user interface. It appears that what we need is for the multiple threads
of C to be more independent of each other, which is what led me to an
AppDomain. Thanks for the help.

"Vadym Stetsyak" wrote:

Hello, Richard!

In what form data "lives" in your application? How do you access it?

Is it possible to make a copy of that data?

You wrote on Thu, 9 Nov 2006 11:40:01 -0800:

RMThanks for your reply. The application is basically WinForms, with
RMsome C and
RMC++ functions that it uses. We have attempted to make separate data,
RMbut we
RMhave lots of interactions between the sessions. Would starting a
RMthread for
RMit help, it seemed to me that another thread would share the data
RManyway,
RMunless it was in a separate AppDomain. Thanks.

RM"Vadym Stetsyak" wrote:

Hello, Richard!

What application you're talking about, WinForms?

Why can't you create 2 copies of data and let each option work with
its
own copy?

IMO AppDomains isn't the option for you.

RMI have an application that works, now I want to make the user
able
RMto run
RMseveral menu options at the same time. So they could choose option
A
RMfrom the
RMmenu, be interacting with it, then choose option B also, and
switch
RMbetween
RMthe two of them. The two options share the same code, but I do not
RMwant them
RMto interact at all in terms of sharing data.

RMIs the use of AppDomains the right way to do this? I would run
RMAppDomain.ExecuteAssemblyByName, and it would start a new domain
RMwith option
RMA, then when the user chooses option B, it would have its own
RMAppDomain for
RMB. Is that what AppDomains are for?

RMI have not worked with AppDomains before, I just wanted some
RMindication that
RMthis was what they are for, and the right way to do this, before I
RMspend a
RMlot of time learning how they work. Thanks very much.

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot

--
With best regards, Vadym Stetsyak.
Blog: http://vadmyst.blogspot.com