Hello -

We have run into an issue here where an add-in that was written using
VSTO2005 for Outlook is running into a conflict with OVC if OVC and the
Outlook Client are both running at the same time. It appears to be
because they share the same process.

I won't bore you with too many details but, we are running Office 2003
pro sp2 and have all the prerequisites for the add-in to function
properly (which it does) as long as you are accessing it from either
OVC or the client... not both.

Additionally, if the Outlook client is not running, OVC does not
instantiate the add-in. Is this expected behavior?

Is there a way to force OVC to use it's own explorer process?

Thoughts welcome.

Thanks in advance
-Steve

As soon as the OVC is instantiated (runtime AND design time), the Outlook.exe
process will run, although there will be no visual Outlook window (but any
Reminders may pop up!). There's no way around this - it's effectively a
window into an instance of Outlook, not a completely separate application.

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


" wrote:

Hello -

We have run into an issue here where an add-in that was written using
VSTO2005 for Outlook is running into a conflict with OVC if OVC and the
Outlook Client are both running at the same time. It appears to be
because they share the same process.

I won't bore you with too many details but, we are running Office 2003
pro sp2 and have all the prerequisites for the add-in to function
properly (which it does) as long as you are accessing it from either
OVC or the client... not both.

Additionally, if the Outlook client is not running, OVC does not
instantiate the add-in. Is this expected behavior?

Is there a way to force OVC to use it's own explorer process?

Thoughts welcome.

Thanks in advance
-Steve

I understand that. My question is not about functionality. I am
intimately familiar with the functionality.

I know that I can programatically force multiple instances of a single
application (depending on the application). It may be the full version
of an application of a partial version of the application - that is
inconsequential.

I need to isolate the Outlook.exe process that OVC uses and keep it
separate from the Outlook.exe process that the outlook client uses. Is
this possible? If so, what is the best method of doing so?

Thanks
-Steve


Eric wrote:
As soon as the OVC is instantiated (runtime AND design time), the Outlook.exe
process will run, although there will be no visual Outlook window (but any
Reminders may pop up!). There's no way around this - it's effectively a
window into an instance of Outlook, not a completely separate application.

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


" wrote:

Hello -

We have run into an issue here where an add-in that was written using
VSTO2005 for Outlook is running into a conflict with OVC if OVC and the
Outlook Client are both running at the same time. It appears to be
because they share the same process.

I won't bore you with too many details but, we are running Office 2003
pro sp2 and have all the prerequisites for the add-in to function
properly (which it does) as long as you are accessing it from either
OVC or the client... not both.

Additionally, if the Outlook client is not running, OVC does not
instantiate the add-in. Is this expected behavior?

Is there a way to force OVC to use it's own explorer process?

Thoughts welcome.

Thanks in advance
-Steve

Why would multiple instancess of the Outlook.exe process matter? What
conflicts are you experiencing with your OVC if one or more instances of
Outlook.exe are running? What exactly are you trying to do with the OVC?

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


"CannedWolf" wrote:

I understand that. My question is not about functionality. I am
intimately familiar with the functionality.

I know that I can programatically force multiple instances of a single
application (depending on the application). It may be the full version
of an application of a partial version of the application - that is
inconsequential.

I need to isolate the Outlook.exe process that OVC uses and keep it
separate from the Outlook.exe process that the outlook client uses. Is
this possible? If so, what is the best method of doing so?

Thanks
-Steve


Eric wrote:
As soon as the OVC is instantiated (runtime AND design time), the Outlook.exe
process will run, although there will be no visual Outlook window (but any
Reminders may pop up!). There's no way around this - it's effectively a
window into an instance of Outlook, not a completely separate application.

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


" wrote:

Hello -

We have run into an issue here where an add-in that was written using
VSTO2005 for Outlook is running into a conflict with OVC if OVC and the
Outlook Client are both running at the same time. It appears to be
because they share the same process.

I won't bore you with too many details but, we are running Office 2003
pro sp2 and have all the prerequisites for the add-in to function
properly (which it does) as long as you are accessing it from either
OVC or the client... not both.

Additionally, if the Outlook client is not running, OVC does not
instantiate the add-in. Is this expected behavior?

Is there a way to force OVC to use it's own explorer process?

Thoughts welcome.

Thanks in advance
-Steve

The OVC is being embedded into a web application to display the user's
calendar. We have built an add-in to allow users to search for
customer records and associate them to an appointment record - this is
launched from the appointment form off of a new menu.

Without the OVC instantiated, no issues with the add-in. With it
instantiated, however, strange issues have appeared. Namely, with OVC
instantiated and the Outlook client open - close the outlook client -
open a new appointment from the OVC - the new add-in menu disappears.
There are others as well.

I have traced this particular issue down to Outlook sending the
shutdown event to the add-in once the client is closed. However, with
the Outlook.exe process still active, the startup event is never fired
again (since it is the same process and already started) and Outlook
believes it is closed so the add-in will not load.

If we were to isolate the processes, their events would be separated
hence solving the issue.

Hope that clarifies.
-Steve


Eric wrote:
Why would multiple instancess of the Outlook.exe process matter? What
conflicts are you experiencing with your OVC if one or more instances of
Outlook.exe are running? What exactly are you trying to do with the OVC?

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


"CannedWolf" wrote:

I understand that. My question is not about functionality. I am
intimately familiar with the functionality.

I know that I can programatically force multiple instances of a single
application (depending on the application). It may be the full version
of an application of a partial version of the application - that is
inconsequential.

I need to isolate the Outlook.exe process that OVC uses and keep it
separate from the Outlook.exe process that the outlook client uses. Is
this possible? If so, what is the best method of doing so?

Thanks
-Steve


Eric wrote:
As soon as the OVC is instantiated (runtime AND design time), the Outlook.exe
process will run, although there will be no visual Outlook window (but any
Reminders may pop up!). There's no way around this - it's effectively a
window into an instance of Outlook, not a completely separate application.

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


" wrote:

Hello -

We have run into an issue here where an add-in that was written using
VSTO2005 for Outlook is running into a conflict with OVC if OVC and the
Outlook Client are both running at the same time. It appears to be
because they share the same process.

I won't bore you with too many details but, we are running Office 2003
pro sp2 and have all the prerequisites for the add-in to function
properly (which it does) as long as you are accessing it from either
OVC or the client... not both.

Additionally, if the Outlook client is not running, OVC does not
instantiate the add-in. Is this expected behavior?

Is there a way to force OVC to use it's own explorer process?

Thoughts welcome.

Thanks in advance
-Steve

Some thoughts:

- if this is a COM Add-In, you should never have to declare an
Outlook.Application object with the New keyword; this may, but shouldn't,
create additional outlook.exe processes
- review this article for some ideas you can use on handling outlook.exe
processes:

Using Micro Eye AddInMon in an Outlook COM Add-in:
http://www.microeye.com/resources/res_addinmon.asp

Also, if you're add-in is creating custom menus or toolbar buttons, be sure
to use Inspector and Explorer collections to handle multiple instances of
Outlook windows or Outlook item windows.

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


"CannedWolf" wrote:

The OVC is being embedded into a web application to display the user's
calendar. We have built an add-in to allow users to search for
customer records and associate them to an appointment record - this is
launched from the appointment form off of a new menu.

Without the OVC instantiated, no issues with the add-in. With it
instantiated, however, strange issues have appeared. Namely, with OVC
instantiated and the Outlook client open - close the outlook client -
open a new appointment from the OVC - the new add-in menu disappears.
There are others as well.

I have traced this particular issue down to Outlook sending the
shutdown event to the add-in once the client is closed. However, with
the Outlook.exe process still active, the startup event is never fired
again (since it is the same process and already started) and Outlook
believes it is closed so the add-in will not load.

If we were to isolate the processes, their events would be separated
hence solving the issue.

Hope that clarifies.
-Steve


Eric wrote:
Why would multiple instancess of the Outlook.exe process matter? What
conflicts are you experiencing with your OVC if one or more instances of
Outlook.exe are running? What exactly are you trying to do with the OVC?

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


"CannedWolf" wrote:

I understand that. My question is not about functionality. I am
intimately familiar with the functionality.

I know that I can programatically force multiple instances of a single
application (depending on the application). It may be the full version
of an application of a partial version of the application - that is
inconsequential.

I need to isolate the Outlook.exe process that OVC uses and keep it
separate from the Outlook.exe process that the outlook client uses. Is
this possible? If so, what is the best method of doing so?

Thanks
-Steve


Eric wrote:
As soon as the OVC is instantiated (runtime AND design time), the Outlook.exe
process will run, although there will be no visual Outlook window (but any
Reminders may pop up!). There's no way around this - it's effectively a
window into an instance of Outlook, not a completely separate application.

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


" wrote:

Hello -

We have run into an issue here where an add-in that was written using
VSTO2005 for Outlook is running into a conflict with OVC if OVC and the
Outlook Client are both running at the same time. It appears to be
because they share the same process.

I won't bore you with too many details but, we are running Office 2003
pro sp2 and have all the prerequisites for the add-in to function
properly (which it does) as long as you are accessing it from either
OVC or the client... not both.

Additionally, if the Outlook client is not running, OVC does not
instantiate the add-in. Is this expected behavior?

Is there a way to force OVC to use it's own explorer process?

Thoughts welcome.

Thanks in advance
-Steve

Thanks for the pointers, all the things you have listed have been done
within the add-in.

I will review the article to see if that helps.

Thanks
-Steve


Eric wrote:
Some thoughts:

- if this is a COM Add-In, you should never have to declare an
Outlook.Application object with the New keyword; this may, but shouldn't,
create additional outlook.exe processes
- review this article for some ideas you can use on handling outlook.exe
processes:

Using Micro Eye AddInMon in an Outlook COM Add-in:
http://www.microeye.com/resources/res_addinmon.asp

Also, if you're add-in is creating custom menus or toolbar buttons, be sure
to use Inspector and Explorer collections to handle multiple instances of
Outlook windows or Outlook item windows.

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


"CannedWolf" wrote:

The OVC is being embedded into a web application to display the user's
calendar. We have built an add-in to allow users to search for
customer records and associate them to an appointment record - this is
launched from the appointment form off of a new menu.

Without the OVC instantiated, no issues with the add-in. With it
instantiated, however, strange issues have appeared. Namely, with OVC
instantiated and the Outlook client open - close the outlook client -
open a new appointment from the OVC - the new add-in menu disappears.
There are others as well.

I have traced this particular issue down to Outlook sending the
shutdown event to the add-in once the client is closed. However, with
the Outlook.exe process still active, the startup event is never fired
again (since it is the same process and already started) and Outlook
believes it is closed so the add-in will not load.

If we were to isolate the processes, their events would be separated
hence solving the issue.

Hope that clarifies.
-Steve


Eric wrote:
Why would multiple instancess of the Outlook.exe process matter? What
conflicts are you experiencing with your OVC if one or more instances of
Outlook.exe are running? What exactly are you trying to do with the OVC?

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


"CannedWolf" wrote:

I understand that. My question is not about functionality. I am
intimately familiar with the functionality.

I know that I can programatically force multiple instances of a single
application (depending on the application). It may be the full version
of an application of a partial version of the application - that is
inconsequential.

I need to isolate the Outlook.exe process that OVC uses and keep it
separate from the Outlook.exe process that the outlook client uses. Is
this possible? If so, what is the best method of doing so?

Thanks
-Steve


Eric wrote:
As soon as the OVC is instantiated (runtime AND design time), the Outlook.exe
process will run, although there will be no visual Outlook window (but any
Reminders may pop up!). There's no way around this - it's effectively a
window into an instance of Outlook, not a completely separate application.

--
Eric Legault (Outlook MVP, MCDBA, MCTS: Messaging & Collaboration)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/


" wrote:

Hello -

We have run into an issue here where an add-in that was written using
VSTO2005 for Outlook is running into a conflict with OVC if OVC and the
Outlook Client are both running at the same time. It appears to be
because they share the same process.

I won't bore you with too many details but, we are running Office 2003
pro sp2 and have all the prerequisites for the add-in to function
properly (which it does) as long as you are accessing it from either
OVC or the client... not both.

Additionally, if the Outlook client is not running, OVC does not
instantiate the add-in. Is this expected behavior?

Is there a way to force OVC to use it's own explorer process?

Thoughts welcome.

Thanks in advance
-Steve