Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel DLL
If I virtualize Excel 2007 via App-V application virtualization component of
Microsoft, can I programmatically access the virtualized Excel DLL using COM? -- |
#2
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel DLL
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? -- |
#3
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel
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? -- |
#4
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel
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? -- |
#5
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel
I'm not familiar with 'smohan'
It is not an application (did you think that?), but the NG name of the OP :-) RBS "Peter T" <peter_t@discussions wrote in message ... 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? -- |
#6
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel
Well spotted, I got that wrong didn't I !
I read "I work with 'smohan" and didn't connect Thanks! Peter T "RB Smissaert" wrote in message ... I'm not familiar with 'smohan' It is not an application (did you think that?), but the NG name of the OP :-) RBS "Peter T" <peter_t@discussions wrote in message ... 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? -- |
#7
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel
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? -- |
#8
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel
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? -- |
#9
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel
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? -- |
#10
Posted to microsoft.public.excel.programming
|
|||
|
|||
App-V - Excel- Programmaticaly accessing the virtualized Excel
Additionally, with Excel Services you cannot CREATE a workbook.
"Michael Y" wrote: 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? -- |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Autofilter used programmaticaly causes error | Excel Programming | |||
How to Programmaticaly Delete or disable minimize and Maximise but | Excel Programming | |||
accessing excel 2003 functions with excel 2007 | Excel Worksheet Functions | |||
Why Excel is accessing Internet & Slowing Excel Performance | Excel Discussion (Misc queries) | |||
programmaticaly test more then 1000 excel files for "opening Errors" | Excel Programming |