I haven't done very well relating to your issue (my fault not yours) but
getting the idea now, though not entirely.

What's the overall objective. Is this merely for creating and/or amending
workbooks - is the new open XML format in 2007 of any use (I know XML is
also suggested for 2003 albeit slower and I think limited). For pre-2007
there's BIFF8 with plenty of tools out there.

Beyond that I will defer to Simon's better knowledge in this area!

Regards,
Peter T

"Michael Y" <Michael wrote in message
...
Thanks, Peter.

The reason I was saying that reentrant Excel is not supported by MS is
this
article:
http://support.microsoft.com/default.aspx/kb/257757
which says:

"Microsoft does not currently recommend, and does not support, Automation
of
Microsoft Office applications from any unattended, non-interactive client
application or component (including ASP, ASP.NET, DCOM, and NT Services),
because Office may exhibit unstable behavior and/or deadlock when Office
is
run in this environment."

One of the reasons they provide for the above statement is (quote):
"Reentrancy and scalability: Server-side components need to be highly
reentrant, multi-threaded COM components that have minimum overhead and
high
throughput for multiple clients. Office applications are in almost all
respects the exact opposite. Office applications are non-reentrant,
STA-based
Automation servers that are designed to provide diverse but
resource-intensive functionality for a single client. "

So, we were hoping that by virtualizing Excel, we can create a pool of
independent Excel instances, and then allow our app to grab an instance,
work
with it to create a workbook (possibly concurrently with other threads),
and
then release the instance, therefore avoiding the reentrancy limitations
of a
single Excel.

Hope this helps. Thanks, Mike.

"Peter T" wrote:

Simple terms! Seriously, I think you are making all this far more
complicated than necessary.

The term to be thinking about is "Automation". In essence this means
establishing an object reference to an instance of Excel, either one that
you have created or one that already exists. Thereafter you have pretty
much
full control of that instance to do with as you will, to the application
itself and to any workbooks open in that instance. You can also trap
events
in the referenced instance to respond to exposed events triggered by
actions
outside your control, eg the user opens a Workbook or changes cell data.

You can establish multiple object references to a single instance (say in
multiple instances of your own app), and/or your application can set
references to multiple Excel instances.

Having said that It is very difficult to reference to multiple instances
that already exist using (VBA/6) GetObject or equivalent in other
languages.
It's easy enough to find out how many instance are 'out there', but on
its
own GetObject will find only a random existing instance. That said, with
a
*lot* of work it is possible to find and reference all existing
instances,
though you'd need an extremely good reason to want to do that.

I don't understand what you mean by "Excel virtualization" or why that
should be necessary,
"MS not support concurrent access to Excel DLL". It does, as described
above
(dll?).

if we have a virtualized Excel Instance 1 and Instance 2, how
do we programmatically distinguish between DLLs in these

In VBA/6 (or equivalent in other languages)
Set xlApp1 = CreateObject("excel.application")
Set xlApp2 = CreateObject("excel.application")

You have now created two instance (why?), currently not visible entirely
under your control. You could use GetObject to find multiple existing
instances but, as said, with considerably more work.

After all that I still don't follow what you want to do, maybe you can
clarify in the framework described above. (I'm not familiar with
'smohan',
and if it provides the means to Automate applications such as Excel).

Regards,
Peter T



"Michael Y" <Michael wrote in message
...
Hi, Peter, I work with 'smohan', and the use case we are trying to
address
is
as follows. We are doing server-side Office automation by using COM to
access
Excel APIs from our application to create, populate, and manage
workbooks.
We
know that Excel is not reentrant and therefore we serialize all access
to
Excel DLL, ensuring that all access is single-threaded. However, this
approach is not scalable, therefore we would like to allow multiple
concurrent processes to use our application to invoke Excel APIs. We
understand that Microsoft does not support concurrent access to Excel
DLL
natively, but we were hoping to achieve our goal with the application
virtualization. If we create multiple instances of virtualized Excel
(one
for
each concurrent thread), then theoretically we can have each thread use
its
own instance of Excel without colliding with other instances. What we
do
not
know if we can access Excel DLL APIs via COM for each virtualized
instance.
In other words, if we have a virtualized Excel Instance 1 and Instance
2,
how
do we programmatically distinguish between DLLs in these instances and
invoke
the appropriate one? Thanks!

"Peter T" wrote:

Explain in simple terms what you want to do

Regards,
Peter T

"smohan" wrote in message
...
If I virtualize Excel 2007 via App-V application virtualization
component
of
Microsoft, can I programmatically access the virtualized Excel DLL
using
COM?
--