EDN Admin
Well-known member
Hi Community,
Im a new member of the forums so please be gentle with me.
We have a large application that I am currently in the process of performing some bug fixing on. The development environment is VS2010 on Windows 7 and I also have MS Office 2010 installed locally.
Without getting into too much technical detail, a module within the application opens word to display a document and when the document is closed, word is closed down successfully as confirmed via the task manager.
All of the projects in the solution are set to target "anyCPU" and since a lot of our clients are still on Windows XP, we have to target .Net 2.0 for the client.
Now ... an issue was raised by one of our clients (customers). They are currently in a windows xp (32 bit) environment with ms office 2003 installed. When the call to MS word is made and then closed, ms word remains open. As you can
imagine after opening several documents and closing them, multiple instances of word are opened but never closed so memory is being eaten constantly.
I tested this issue on my local setup with win 7 and office 2010 and word closed as expected every time. I then created a virtual environment on my PC with win xp and office 2003 installed and copied the code from my win 7 and 2010 environment to the
virtual environment and I could recreate the issue every time (i.e. word doesnt close properly).
I installed VS 2010 into my virtual environment so I could debug the application. After compiling the source into a windows XP with office 2003 environment, I set about debugging the code to find that the issue had gone away. How confusing .....
Through experiments, I determined which dll was causing the issue so I decided to try another experiment. I compiled the source in my win 7 environment only this time I set the build target to x86. When the app had complied, I copied only that
dll across to my virtual environment and ran the app outside visual studio. Hey presto, the issue with word closing disappeared.
Now, the problem is, we have other clients who have all combinations of operating systems and versions of office installations so ideally we need to keep the build target at anyCPU.
Does anyone know a solution (or a work around) to this problem ? Creating versions targeted at different operating systems / ms office versions is not an option Im afraid. I am hoping there is a setting/precomiler directive/anything somewhere
I can use that will fix this issue.
Thanks in advance
Julian Holling
View the full article
Im a new member of the forums so please be gentle with me.
We have a large application that I am currently in the process of performing some bug fixing on. The development environment is VS2010 on Windows 7 and I also have MS Office 2010 installed locally.
Without getting into too much technical detail, a module within the application opens word to display a document and when the document is closed, word is closed down successfully as confirmed via the task manager.
All of the projects in the solution are set to target "anyCPU" and since a lot of our clients are still on Windows XP, we have to target .Net 2.0 for the client.
Now ... an issue was raised by one of our clients (customers). They are currently in a windows xp (32 bit) environment with ms office 2003 installed. When the call to MS word is made and then closed, ms word remains open. As you can
imagine after opening several documents and closing them, multiple instances of word are opened but never closed so memory is being eaten constantly.
I tested this issue on my local setup with win 7 and office 2010 and word closed as expected every time. I then created a virtual environment on my PC with win xp and office 2003 installed and copied the code from my win 7 and 2010 environment to the
virtual environment and I could recreate the issue every time (i.e. word doesnt close properly).
I installed VS 2010 into my virtual environment so I could debug the application. After compiling the source into a windows XP with office 2003 environment, I set about debugging the code to find that the issue had gone away. How confusing .....
Through experiments, I determined which dll was causing the issue so I decided to try another experiment. I compiled the source in my win 7 environment only this time I set the build target to x86. When the app had complied, I copied only that
dll across to my virtual environment and ran the app outside visual studio. Hey presto, the issue with word closing disappeared.
Now, the problem is, we have other clients who have all combinations of operating systems and versions of office installations so ideally we need to keep the build target at anyCPU.
Does anyone know a solution (or a work around) to this problem ? Creating versions targeted at different operating systems / ms office versions is not an option Im afraid. I am hoping there is a setting/precomiler directive/anything somewhere
I can use that will fix this issue.
Thanks in advance
Julian Holling
View the full article