More about trying to automation multiple Excel instances

[Sergei Emelyanenkov]

Hello,

There were already posts about impossibility to automate multiple Excel
instances (only first started instance is automated). But, actually, it's
vital for product we develop. So, I still don't lose hope

First question.
As I understand, functions which are used to obtain running Excel instance
(Marshal.GetActiveObject in .Net or GetObject in VBScript) look for it in the
Running Object Table (ROT). So, what is the main point - only first Excel
instance is registered in ROT? or thay all are registered, but the first is
returned? If all Excel instances are registered, can we use
IRunningObjectTable::EnumRunning method to enum them and bind to each of them?

Second question.
Can we at least ajust somehow Excel behavior (using its own settings) for it
to start as single instance (like Word)?

Thank you in advance!

 

[Jialiang Ge [MSFT]]

Good afternoon, Sergei. Welcome to Microsoft Newsgroup Support Service! My
name is Jialiang Ge [MSFT]. It's my pleasure to work with you in this issue.

According to the post, you wonder how to automate a specific instance of
Excel. As far as I know, there are at least two ways that meet the
requirement. Sergei, you mentioned the "impossibility to automate multiple
Excel Instances". Would you mind sharing me with these posts? There might
be some special limits that I am not aware of. Thanks.

For your first question, all the Excel instances are registered in ROT
(Running Object Table). The instance that is first registered in the ROT is
typically the instance that is returned by GetActiveObject. If you want to
get an Automation Reference to a specific running instance of Word, Excel,
or Microsoft Access, we can consider
Method 1. use BindToMoniker with the name of the file that is opened in
that instance.
- or -
Method 2. IRunningObjectTable::EnumRunning

Please allow me to demonstrate these two methods one by one:

*Method 1. Use BindToMoniker with the name of the file that is opened in
that instance.*
There is a very good KB article that provides examples of BindToMoniker for
Office and explains the Multiuse and Singe Use mechanisms of Office
products to help you have a clearer picture of COM and ROT:

How to use Visual C# to automate a running instance of an Office program
http://support.microsoft.com/kb/316126

I also write a code snippet for your reference:
(Suppose two instances of excel.exe have loaded Book1.xls and Book2.xls
repectively)
The code sets a value to the workbooks in different instances of Excel.

[STAThread] //STA thread declaration is necessary.
static void Main(string[] args)
{
Excel.Workbook xlwkbook1, xlwkbook2;
Excel.Worksheet xlsheet1, xlsheet2;

//Get a reference to the Workbook object by using a file
moniker.
//The xls was saved earlier with this file name.
xlwkbook1 =
(Excel.Workbook)Marshal.BindToMoniker(@"D:\Test\Book1.xls");
xlwkbook2 =
(Excel.Workbook)Marshal.BindToMoniker(@"D:\Test\Book2.xls");

xlsheet1 = (Excel.Worksheet)xlwkbook1.ActiveSheet;
xlsheet1.Cells[1, 1] = 111;

xlsheet2 = (Excel.Worksheet)xlwkbook2.ActiveSheet;
xlsheet2.Cells[1, 1] = 222;
}

For more readings about moniker, I recommend the book "Essential COM" by
DON BOX. In its Chapter 3, "Classes", Moniker is introduced in detail.

*Method 2. IRunningObjectTable::EnumRunning*
I searched online, and also found a very good article for EnumRunning.
Although the article is for "automating a specific instance of Visual
Studio.net", the principle is the same for Office.
http://www.codeproject.com/KB/cs/automatingvisualstudio.aspx
If you encounter any problem when converting its code to the use of Office,
please don't hesitate to let me know.

For your second question:
"Can we at least adjust somehow Excel behavior (using its own settings) for
it to start as single instance (like Word)?"

According to the KB article http://support.microsoft.com/kb/316126, Excel
is designed as a Single Use (Multiple Instances) server:
<quote>
Multiple instances of Word (Winword.exe), Excel (Excel.exe), and Microsoft
Access (MSAccess.exe) can run simultaneously. Therefore, these servers are
defined as Single Use (Multiple Instances) servers. Only one instance of
PowerPoint (Powerpnt.exe) can run at any given time. Therefore, PowerPoint
is a Multiuse (Single Instance) server.
</quote>
Therefore, as far as I know, there is no option to allow only one instance
of Excel in the machine. Even for Word, we are still able to create
multiple winword.exe instances by calling CreateObject("Word.Application")
for serveral times. Sergei, I will confirm this point with the product team
and get to you soon.

Please let me know if you have any other concerns, or need anything else.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Sergei Emelyanenkov]

Hello Jialiang, thank you for your quick response!

I think, Method 2. is a right direction to solve my problem. Let me try to
implement it and I reply again.

Conserning "impossibility to automate multiple Excel Instances" - my be I
have overstaded it a little Actually, I found only one post in this
newsgroup with subject "GetActiveObject("Excel.Application") for multiple
instances of Exc" (posted 6/18/2008). There was only one unfavourable reply
"If GetActiveObject works like GetObject() then I don't think there's any way
to get a specific instance of an application".

--
Best Regards,
Sergei Emelyanenkov

Good afternoon, Sergei. Welcome to Microsoft Newsgroup Support Service! My
name is Jialiang Ge [MSFT]. It's my pleasure to work with you in this issue.

According to the post, you wonder how to automate a specific instance of
Excel. As far as I know, there are at least two ways that meet the
requirement. Sergei, you mentioned the "impossibility to automate multiple
Excel Instances". Would you mind sharing me with these posts? There might
be some special limits that I am not aware of. Thanks.

For your first question, all the Excel instances are registered in ROT
(Running Object Table). The instance that is first registered in the ROT is
typically the instance that is returned by GetActiveObject. If you want to
get an Automation Reference to a specific running instance of Word, Excel,
or Microsoft Access, we can consider
Method 1. use BindToMoniker with the name of the file that is opened in
that instance.
- or -
Method 2. IRunningObjectTable::EnumRunning

Please allow me to demonstrate these two methods one by one:

*Method 1. Use BindToMoniker with the name of the file that is opened in
that instance.*
There is a very good KB article that provides examples of BindToMoniker for
Office and explains the Multiuse and Singe Use mechanisms of Office
products to help you have a clearer picture of COM and ROT:

How to use Visual C# to automate a running instance of an Office program
http://support.microsoft.com/kb/316126

I also write a code snippet for your reference:
(Suppose two instances of excel.exe have loaded Book1.xls and Book2.xls
repectively)
The code sets a value to the workbooks in different instances of Excel.

[STAThread] //STA thread declaration is necessary.
static void Main(string[] args)
{
Excel.Workbook xlwkbook1, xlwkbook2;
Excel.Worksheet xlsheet1, xlsheet2;

//Get a reference to the Workbook object by using a file
moniker.
//The xls was saved earlier with this file name.
xlwkbook1 =
(Excel.Workbook)Marshal.BindToMoniker(@"D:\Test\Book1.xls");
xlwkbook2 =
(Excel.Workbook)Marshal.BindToMoniker(@"D:\Test\Book2.xls");

xlsheet1 = (Excel.Worksheet)xlwkbook1.ActiveSheet;
xlsheet1.Cells[1, 1] = 111;

xlsheet2 = (Excel.Worksheet)xlwkbook2.ActiveSheet;
xlsheet2.Cells[1, 1] = 222;
}

For more readings about moniker, I recommend the book "Essential COM" by
DON BOX. In its Chapter 3, "Classes", Moniker is introduced in detail.

*Method 2. IRunningObjectTable::EnumRunning*
I searched online, and also found a very good article for EnumRunning.
Although the article is for "automating a specific instance of Visual
Studio.net", the principle is the same for Office.
http://www.codeproject.com/KB/cs/automatingvisualstudio.aspx
If you encounter any problem when converting its code to the use of Office,
please don't hesitate to let me know.

For your second question:
"Can we at least adjust somehow Excel behavior (using its own settings) for
it to start as single instance (like Word)?"

According to the KB article http://support.microsoft.com/kb/316126, Excel
is designed as a Single Use (Multiple Instances) server:
<quote>
Multiple instances of Word (Winword.exe), Excel (Excel.exe), and Microsoft
Access (MSAccess.exe) can run simultaneously. Therefore, these servers are
defined as Single Use (Multiple Instances) servers. Only one instance of
PowerPoint (Powerpnt.exe) can run at any given time. Therefore, PowerPoint
is a Multiuse (Single Instance) server.
</quote>
Therefore, as far as I know, there is no option to allow only one instance
of Excel in the machine. Even for Word, we are still able to create
multiple winword.exe instances by calling CreateObject("Word.Application")
for serveral times. Sergei, I will confirm this point with the product team
and get to you soon.

Please let me know if you have any other concerns, or need anything else.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Sergei Emelyanenkov]

So, I've carried out an investigation based on
http://www.codeproject.com/KB/cs/automatingvisualstudio.aspx
to discover how Excel is registered in ROT. Here is the summary:

Excel registers itself in ROT as item moniker with display name
"!{00024500-0000-0000-C000-000000000046}". Number of such monikers equals to
the number of Excel processes. BUT, comparing this monikers among themselves
using IMoniker.IsEqual returns S_OK! And receiving the instance of
Excel.Application from any of them gives again first started Excel instance.
It is confusing, but there is a workaround described below.

All opened Excel workbooks are registered in ROT as file monikers with
theirs full names as display names. Receiving Workbook object from these
monikers works fine. Application property of Workbook object gives us
Excel.Application object, corresponding to the Workbook's owner process. In
this way we can recive all Excel instances (at least .

This results are good enaugh for me to solve my problems.

Jialiang, thank you again for your help!

--
Best Regards,
Sergei Emelyanenkov

Hello Jialiang, thank you for your quick response!

I think, Method 2. is a right direction to solve my problem. Let me try to
implement it and I reply again.

Conserning "impossibility to automate multiple Excel Instances" - my be I
have overstaded it a little Actually, I found only one post in this
newsgroup with subject "GetActiveObject("Excel.Application") for multiple
instances of Exc" (posted 6/18/2008). There was only one unfavourable reply
"If GetActiveObject works like GetObject() then I don't think there's any way
to get a specific instance of an application".

--
Best Regards,
Sergei Emelyanenkov

Good afternoon, Sergei. Welcome to Microsoft Newsgroup Support Service! My
name is Jialiang Ge [MSFT]. It's my pleasure to work with you in this issue.

According to the post, you wonder how to automate a specific instance of
Excel. As far as I know, there are at least two ways that meet the
requirement. Sergei, you mentioned the "impossibility to automate multiple
Excel Instances". Would you mind sharing me with these posts? There might
be some special limits that I am not aware of. Thanks.

For your first question, all the Excel instances are registered in ROT
(Running Object Table). The instance that is first registered in the ROT is
typically the instance that is returned by GetActiveObject. If you want to
get an Automation Reference to a specific running instance of Word, Excel,
or Microsoft Access, we can consider
Method 1. use BindToMoniker with the name of the file that is opened in
that instance.
- or -
Method 2. IRunningObjectTable::EnumRunning

Please allow me to demonstrate these two methods one by one:

*Method 1. Use BindToMoniker with the name of the file that is opened in
that instance.*
There is a very good KB article that provides examples of BindToMoniker for
Office and explains the Multiuse and Singe Use mechanisms of Office
products to help you have a clearer picture of COM and ROT:

How to use Visual C# to automate a running instance of an Office program
http://support.microsoft.com/kb/316126

I also write a code snippet for your reference:
(Suppose two instances of excel.exe have loaded Book1.xls and Book2.xls
repectively)
The code sets a value to the workbooks in different instances of Excel.

[STAThread] //STA thread declaration is necessary.
static void Main(string[] args)
{
Excel.Workbook xlwkbook1, xlwkbook2;
Excel.Worksheet xlsheet1, xlsheet2;

//Get a reference to the Workbook object by using a file
moniker.
//The xls was saved earlier with this file name.
xlwkbook1 =
(Excel.Workbook)Marshal.BindToMoniker(@"D:\Test\Book1.xls");
xlwkbook2 =
(Excel.Workbook)Marshal.BindToMoniker(@"D:\Test\Book2.xls");

xlsheet1 = (Excel.Worksheet)xlwkbook1.ActiveSheet;
xlsheet1.Cells[1, 1] = 111;

xlsheet2 = (Excel.Worksheet)xlwkbook2.ActiveSheet;
xlsheet2.Cells[1, 1] = 222;
}

For more readings about moniker, I recommend the book "Essential COM" by
DON BOX. In its Chapter 3, "Classes", Moniker is introduced in detail.

*Method 2. IRunningObjectTable::EnumRunning*
I searched online, and also found a very good article for EnumRunning.
Although the article is for "automating a specific instance of Visual
Studio.net", the principle is the same for Office.
http://www.codeproject.com/KB/cs/automatingvisualstudio.aspx
If you encounter any problem when converting its code to the use of Office,
please don't hesitate to let me know.

For your second question:
"Can we at least adjust somehow Excel behavior (using its own settings) for
it to start as single instance (like Word)?"

According to the KB article http://support.microsoft.com/kb/316126, Excel
is designed as a Single Use (Multiple Instances) server:
<quote>
Multiple instances of Word (Winword.exe), Excel (Excel.exe), and Microsoft
Access (MSAccess.exe) can run simultaneously. Therefore, these servers are
defined as Single Use (Multiple Instances) servers. Only one instance of
PowerPoint (Powerpnt.exe) can run at any given time. Therefore, PowerPoint
is a Multiuse (Single Instance) server.
</quote>
Therefore, as far as I know, there is no option to allow only one instance
of Excel in the machine. Even for Word, we are still able to create
multiple winword.exe instances by calling CreateObject("Word.Application")
for serveral times. Sergei, I will confirm this point with the product team
and get to you soon.

Please let me know if you have any other concerns, or need anything else.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jialiang Ge [MSFT]]

Good morning, Sergei. Thank you for this great summary. According to the
test results, the only solution to automate multiple Excel instances seems
to be "file moniker", which was also mentioned in the "method 1" of my
initial reply, and was demonstrated in the KB article: How to get IDispatch
of an Excel or Word document from an OCX.
http://support.microsoft.com/kb/q190985/

Sergei, if you want to dig out the reason for the failure of "item moniker"
("!{00024500-0000-0000-C000-000000000046}".), I'm very willing to help. In
fact, I'm also interested in the product team's consideration behind this
design. My researches so far are at the bottom of this message. Though the
reason has not been found out, I am going to discuss it with the Excel
designers directly.

--------------------------------------------------
My researches so far:

I start two instances of Excel, open two workbooks (Book1.xls, Book2.xls)
respectively. In order to see the current ROT status visually, I use the
tool "ROT Viewer" shipped with VC6. ROT Viewer lists the following monikers
related to Excel:

{!00024500-0000-0000-C000-000000000046}
{!00024500-0000-0000-C000-000000000046}
D:\test\book1.xls
D:\test\book2.xls

where the first two are item monikers and the rest are file monikers. From
ROT Viewer, I also see the item monikers have the same properties, e.g.
Hash Value. To verify whether they indeed refer to the same instance, I
wrote a small program to enumrunnings, cast them to Excel.Application, and
as you found out, the automation code run on these Excel.Application
objects only happens to the first instance of Excel. That's to say, the two
instances refer to the same instance of Excel.

I'm holding further discussions with my colleagues, and I promise to be
back soon.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

 

[Sergei Emelyanenkov]

Hello Jialiang,
of course, it's interesting for me to know why Ecxel behave in this manner!

Waiting impatiently for the results of your investigations.

 

[Jialiang Ge [MSFT]]

Hello Sergei,

Thanks for your patience. I have almost found out the reason:

Let¡¯s start with a test I¡¯m taking.

In my computer, I start 2 instances of Excel to open 2 xls files
respectively. In the meantime, I open two Visual Studio 2005 processes for 2
solutions. The ROT status at the moment shows as this in ROT Viewer:

----------------------start------------------------
{!00024500-0000-0000-C000-000000000046}
{!00024500-0000-0000-C000-000000000046}
D:\test\book1.xls
D:\test\book2.xls

!VisualStudio.DTE.8.0:4600
!VisualStduio.DTE.8.0:4080
!{BA018599-1DB3-44F9-83B4-461454C84BF8}
!{BA018599-1DB3-44F9-83B4-461454C84BF8}
D:\test\solution1.sln
D:\test\solution2.sln
---------------------- end ------------------------

1. The two occurrences of {!00024500-0000-0000-C000-000000000046} are the
item monikers of Excel instances. They have the same hash value, and refer
to the same instance of Excel as we have already found.

2. D:\test\book1.xls and D:\test\book2.xls are the file monikers of the
Excel instances. We are able to differentiate the Excel instances with them.

3. !VisualStudio.DTE.8.0:4600 and !VisualStduio.DTE.8.0:4080 are the Item
Monikers for Visual Studio IDE. They have different displayed name (the
number to the right of the progID is the process ID), different hash value.
Using them to get a specific Visual Studio instance works very well as is
illustrated in the article
http://www.codeproject.com/KB/cs/automatingvisualstudio.aspx.

4. !{BA018599-1DB3-44F9-83B4-461454C84BF8} and
!{BA018599-1DB3-44F9-83B4-461454C84BF8}
These two are the important findings in my investigations. They are the
CLSID of Visual Studio IDE, just as {!00024500-0000-0000-C000-000000000046}
is the CLSID of Excel. They have identical displayed name, hash value, and
other properties. When I change the code in
http://www.codeproject.com/KB/cs/automatingvisualstudio.aspx to use
!{BA018599-1DB3-44F9-83B4-461454C84BF8} to search the VS entry in ROT, I get
the same result as Excel, i.e., all the entries refer to the same instance.

5. D:\test\solution1.sln and D:\test\solution2.sln are the file monikers of
VS instances. We are also able to differentiate the VS instances with them.

From the above test, I see VS actually did the same thing for ROT
registration as Excel, except the !VisualStudio.DTE.8.0:4600 ones. It seems
that VS registers the additional !VisualStudio.DTE.8.0:4600, and this
additional action enables us to differentiate the VS instances with Item
Moniker.

After further looking into it, I realize that the registration of
{!00024500-0000-0000-C000-000000000046} and
!{BA018599-1DB3-44F9-83B4-461454C84BF8} with the CLSID of the component is,
in fact, a standard process of ROT registration. They are the result of the
call ¡°RegisterActiveObject¡±.
http://msdn.microsoft.com/en-us/library/ms221551(VS.85).aspx
Base on my tests, RegisterActiveObject is designed to behave in this way:
when the CLSID has already been registered in ROT, the operation will be
neglected, i.e. the latter registration won¡¯t take effect. That¡¯s why our
use of {!00024500-0000-0000-C000-000000000046} always refers to the same (or
more precisely, the first) instance of Excel.

I believe the additional action of Visual Studio is the call of
¡°IRunningObject::Register¡±. This method allows us to define the customized
¡°displayed name¡± for each entry, e.g. !VisualStudio.DTE.8.0:4600, so that
each instance has a distinctive name. Because the ¡°standard¡± registration
of ROT only includes the call of ¡°RegisterActiveObject¡±, Excel and many
other application do not have the ROT entries like VS.

Sergei, is this explanation clear enough for you? I welcome your and other
community members¡¯ rectifications in case I make any mistakes in the
research.

By the way, Sergei. I get the product team¡¯s confirmation today about the
possibility of limiting Excel instance number to one. They tell me there are
no supported ways to do it because Excel is designed as a Single Use
(Multiple Instances) server.

Please let me know if you have any other concerns, or need anything else.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

 

[Sergei Emelyanenkov]

Jialiang, even though my COM/OLE skills leave much to be desired, I've
understood the main idea of your explanation. It seems, now we have a good
knowledge of multiple Excel instances automation. We know what we can and
what we can't to do. For justice' sake, there is one potential issue -
several Excel instances without opened books (please, don't think about me
the same what I think about our testers ... But, it's rather theoretical
problem then practical.

I'm completely satisfied with the answers to both my questions! My other
needs doesn't concern to this particular issue, so I'm going to submit it as
separate posts.

Thank you!

--
Best Regards,
Sergei Emelyanenkov

Hello Sergei,

Thanks for your patience. I have almost found out the reason:

Let¡¯s start with a test I¡¯m taking.

In my computer, I start 2 instances of Excel to open 2 xls files
respectively. In the meantime, I open two Visual Studio 2005 processes for 2
solutions. The ROT status at the moment shows as this in ROT Viewer:

----------------------start------------------------
{!00024500-0000-0000-C000-000000000046}
{!00024500-0000-0000-C000-000000000046}
D:\test\book1.xls
D:\test\book2.xls

!VisualStudio.DTE.8.0:4600
!VisualStduio.DTE.8.0:4080
!{BA018599-1DB3-44F9-83B4-461454C84BF8}
!{BA018599-1DB3-44F9-83B4-461454C84BF8}
D:\test\solution1.sln
D:\test\solution2.sln
---------------------- end ------------------------

1. The two occurrences of {!00024500-0000-0000-C000-000000000046} are the
item monikers of Excel instances. They have the same hash value, and refer
to the same instance of Excel as we have already found.

2. D:\test\book1.xls and D:\test\book2.xls are the file monikers of the
Excel instances. We are able to differentiate the Excel instances with them.

3. !VisualStudio.DTE.8.0:4600 and !VisualStduio.DTE.8.0:4080 are the Item
Monikers for Visual Studio IDE. They have different displayed name (the
number to the right of the progID is the process ID), different hash value.
Using them to get a specific Visual Studio instance works very well as is
illustrated in the article
http://www.codeproject.com/KB/cs/automatingvisualstudio.aspx.

4. !{BA018599-1DB3-44F9-83B4-461454C84BF8} and
!{BA018599-1DB3-44F9-83B4-461454C84BF8}
These two are the important findings in my investigations. They are the
CLSID of Visual Studio IDE, just as {!00024500-0000-0000-C000-000000000046}
is the CLSID of Excel. They have identical displayed name, hash value, and
other properties. When I change the code in
http://www.codeproject.com/KB/cs/automatingvisualstudio.aspx to use
!{BA018599-1DB3-44F9-83B4-461454C84BF8} to search the VS entry in ROT, I get
the same result as Excel, i.e., all the entries refer to the same instance.

5. D:\test\solution1.sln and D:\test\solution2.sln are the file monikers of
VS instances. We are also able to differentiate the VS instances with them.

From the above test, I see VS actually did the same thing for ROT
registration as Excel, except the !VisualStudio.DTE.8.0:4600 ones. It seems
that VS registers the additional !VisualStudio.DTE.8.0:4600, and this
additional action enables us to differentiate the VS instances with Item
Moniker.

After further looking into it, I realize that the registration of
{!00024500-0000-0000-C000-000000000046} and
!{BA018599-1DB3-44F9-83B4-461454C84BF8} with the CLSID of the component is,
in fact, a standard process of ROT registration. They are the result of the
call ¡°RegisterActiveObject¡±.
http://msdn.microsoft.com/en-us/library/ms221551(VS.85).aspx
Base on my tests, RegisterActiveObject is designed to behave in this way:
when the CLSID has already been registered in ROT, the operation will be
neglected, i.e. the latter registration won¡¯t take effect. That¡¯s why our
use of {!00024500-0000-0000-C000-000000000046} always refers to the same (or
more precisely, the first) instance of Excel.

I believe the additional action of Visual Studio is the call of
¡°IRunningObject::Register¡±. This method allows us to define the customized
¡°displayed name¡± for each entry, e.g. !VisualStudio.DTE.8.0:4600, so that
each instance has a distinctive name. Because the ¡°standard¡± registration
of ROT only includes the call of ¡°RegisterActiveObject¡±, Excel and many
other application do not have the ROT entries like VS.

Sergei, is this explanation clear enough for you? I welcome your and other
community members¡¯ rectifications in case I make any mistakes in the
research.

By the way, Sergei. I get the product team¡¯s confirmation today about the
possibility of limiting Excel instance number to one. They tell me there are
no supported ways to do it because Excel is designed as a Single Use
(Multiple Instances) server.

Please let me know if you have any other concerns, or need anything else.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

 

[Jialiang Ge [MSFT]]

Hello Sergei,

I can understand your concern on the "potential issue" - several Excel
instances without opened books. Let's imagine the following three test
scenarios:

Test Scenario 1. When several Excel instances are started without opened
workbooks.
"Without opened workbooks" means no workbook (even the default "new"
workbook) is present in the instances, and Excel is in an empty, grayed
background. For such a scenario, I agree it is a potential menace in that
no file moniker is registered in ROT. I had also considered enumerating
excel process ID and attach Excel object model to the process, but it would
not work either due to the different "working mechanisms". The possible
workarounds depend on your specific product context. If I'm proper to be
told the detailed reason/context for the automation of Excel instances
without opened workbooks, I may be able to find out some workarounds for
your references.

Test Scenario 2. When several Excel instances are started with a default
open.
"A default open" means that, when Excel is started, it has a "new" workbook
open by default. The "new" workbook will be registered as file moniker in
ROT with names "Book1", "Book2", etc. Therefore, we are still able to
differentiate the Excel instances with the names "Book1", "Book2", etc in
this scenario.

Test Scenario 3. When several Excel instances open the same workbook
simultaneously
The first open of the workbook register the file moniker in ROT. The
following Excel instances can only open the book in the mode of
"read-only", and they will not register the file moniker again, thus,
querying the file moniker in ROT can merely return the first instance of
Excel. Will this scenario influence your product context?

I'm completely satisfied with the answers to both my questions! My
other needs doesn't concern to this particular issue, so I'm going to
submit it as separate posts.

Thank you for the positive feedback. Delighting you with my support
services is my goal. I'd also thank you for the feedback of "theoretical"
and "practical", I will demo more practices in my future supports for you.

Regarding the "other needs", please DON'T hesitate to tell me. I'm with you
and can serve you at your conveniences.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

 

[Jeremy Leigh]

Hello Jialiang,

This is a very interesting thread, and I would like to revisit the research
here for the following reason -

I work in a corporation where users have many instances of excel running at
once.

I am also responsible for deploying an excel addin (.xla) to users machines.
Currently in order to deploy an updated version of the addin, all running
instances of excel must be closed.
However, it is also possibly to update the add-in without closing excel. The
way this can be done is to first unload the addin from all running instances
of Excel via Tools, Addins.
The old xla can then be overwritten with the new version, and the new add-in
can then be reloaded into excel via the Tools, Addins dialog by re-checking
the checkbox.

So what I want to do is create an auto-update macro. This macro would check
the current version of the installed XLA, and if it is out of date it would
do the following:

(1) Loop through all running instances of Excel.Application and,
(2) Uninstall the addin I am going to update using
Application.AddIns("myAddin").Installed = False
(3) Copy over the .xla file with the new version
(4) Loop through all running instances of Excel.Application and,
(5) Re-install the addin using Application.AddIns("myAddin").Installed = True

This is necessary because some workbooks in this banking environment take
15+ minutes to calculate, so closing excel for updating addins is extremely
inconvenient for users.

So obviously this looping would need to
(a) work with Excel Applications which have no open workbooks
(b) work with Excel Applications where the workbook has been opened more
than once - i.e. Read Only.
It is quite common for excel applications to be in one of the above states
on user machines.
Appreciate your advice on the matter.

Thanks,
Jeremy Leigh.

Hello Sergei,

I can understand your concern on the "potential issue" - several Excel
instances without opened books. Let's imagine the following three test
scenarios:

Test Scenario 1. When several Excel instances are started without opened
workbooks.
"Without opened workbooks" means no workbook (even the default "new"
workbook) is present in the instances, and Excel is in an empty, grayed
background. For such a scenario, I agree it is a potential menace in that
no file moniker is registered in ROT. I had also considered enumerating
excel process ID and attach Excel object model to the process, but it would
not work either due to the different "working mechanisms". The possible
workarounds depend on your specific product context. If I'm proper to be
told the detailed reason/context for the automation of Excel instances
without opened workbooks, I may be able to find out some workarounds for
your references.

Test Scenario 2. When several Excel instances are started with a default
open.
"A default open" means that, when Excel is started, it has a "new" workbook
open by default. The "new" workbook will be registered as file moniker in
ROT with names "Book1", "Book2", etc. Therefore, we are still able to
differentiate the Excel instances with the names "Book1", "Book2", etc in
this scenario.

Test Scenario 3. When several Excel instances open the same workbook
simultaneously
The first open of the workbook register the file moniker in ROT. The
following Excel instances can only open the book in the mode of
"read-only", and they will not register the file moniker again, thus,
querying the file moniker in ROT can merely return the first instance of
Excel. Will this scenario influence your product context?

I'm completely satisfied with the answers to both my questions! My
other needs doesn't concern to this particular issue, so I'm going to
submit it as separate posts.

Thank you for the positive feedback. Delighting you with my support
services is my goal. I'd also thank you for the feedback of "theoretical"
and "practical", I will demo more practices in my future supports for you.

Regarding the "other needs", please DON'T hesitate to tell me. I'm with you
and can serve you at your conveniences.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

 

[joel]

The best method for updaing applications on a Windows PC is to push th
update to every PC. Then have the updates get automatically installe
the next time the PC is restarted. For people who need the addi
installed immediately, then have them reboot the PC. For people wh
don't need the update immediately wait until they logoff.

Since you want to make sure all your companies PC get the lates
Microsoft Security Updates installed regularly on there PC, I asume yo
company weekly feboots all the PCs on your network. You can have you
addins updated at the same time the security updates get installed.

You shouldn't be re-inventing the wheel. Microsoft has developed
method of pushing updates to PCs and you shold follow the methodolog
that Microsoft has developed.

 

[Charles Williams]

I would suggest building your own addin loader. Then you could make it
autorefresh without closing Excel or rebooting, oin a timed basis if
needed.

Look at my Auto-reversioning addin loader for starters, feel free to
re-use the code - the password is dm

http://www.decisionmodels.com/downloads.htm

The Add-In Loader is designed to solve some of the problems of
maintaining and loading Add-Ins on a network:

Dynamic reversioning of add-ins with automatic link
updating.

Control from a central point which add-ins will be
automatically loaded when Excel starts.

Control from a central point which add-ins will be available
for on-demand loading.

Enable updated versions of an add-in to be placed on a
server at the same time as previous versions are in use.

Optionally specify and/or change the network path for each
add-in.

No Registry changes for load and unload.

The Add-In Loader helps the User:

Improve Excel start-up time by bypassing the loading of
add-ins that are only needed intermittently.

Minimize memory use by loading add-ins when needed and
easily unloading them when not needed.

Dynamically load the latest version of an add-in, whilst
unloading any version which is currently loaded.

Dynamically update any links that point to old versions of
loaded add-ins when a workbook is opened or an add-in is loaded.

Charles