Thanks, Simon

We have looked at Excel Services very closely. Unfortunately, this option
does not support all the Excel features we need and that are available via
the native APIs.

When we tried to create an Excel instance per thread in our app, only a
single copy of Excel DLL was loaded into memory, and then we started having
reliablity issues when multiple concurrent threads were accessing the DLL.

We were hoping that the virtualization approach would allow us create
multiple copies of Excel clones in memory (yes, we do have a large machine),
and assign each concurrent thread to a private clone copy.

Hope this helps, thanks!

"Simon Murphy" wrote:

Have you had a look at Excel Services? It sounds purpose made for the
use you have in mind.
The full Excel client is never going to be supported on a server.
Workable - yes, reliable - no. ES on the other hand is specifically for
server scenarios.
VBA is not supported sadly.

I'm not clear why you need virtualised Excels, you can just create an
instance per thread assigned to a variable and access it that way.

I take you have a big machine for this?

Cheers
Simon
Excel development website: www.codematic.net


Michael Y wrote:
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?
--