I have an Outlook Add in where I am using Microsoft.Office.Interop.Outlook.Storageitem to save my settings.
Most of my tests access the settings to set or get the configuration for contacting the server.
On my local machine all of the tests are running fine. But when I check in my project into TFS and run the tests there all of them fail with the Error:
System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).
The error occurs when the test is calling the following codeline.
Folder inbox = (Folder) new Microsoft.Office.Interop.Outlook.Application().GetNamespace("MAPI").GetDefaultFolder(OlDefaultFolders.olFolderInbox);
I asume that the error appears because the test tries to access an Application of Outlook and does not have the permission.
Outlook is instaled on the Windows Server 2012 where TFS is running.
Also Outlook was started once with having no Mailaccount configured. (The test runs fine when i start it manually on a machine with a Outlook with no Mailaccount configured.)
The C:\Windows\SysWOW64\config\systemprofile\Desktop folder exists.
I already have set all permissions for the user NETWORK SERVICE in Controlpanel->Administrative tools->Component Services->computers-> myComputer->DCOM Config->Microsoft Outlook
I also found this question which has no answer to my problem.
Are there any other steps i could try to give my tests access to run the tests sucessfully?
Outlook is instaled on the Windows Server 2012 where TFS is running.
I already have set all permissions for the user NETWORK SERVICE in Controlpanel->Administrative tools->Component Services->computers-> myComputer->DCOM Config->Microsoft Outlook
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.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
No Office app (Outlook included) can be used in a service. I don't think actually creating an instance of Outlook.Application is a good idea in a unit test.
Try changing the TFS build server to run as a user with admin rights on the box. I would not suggest leaving this configuration.
Related
I have a .Net C# application that manipulates Word documents.
I am using Microsoft.Office.Interop.Word.dll, part of Office 2010, product version 14.0.xxx. Invoking:
using Microsoft.Office.Interop.Word;
...
Application app = new Application();
causes the following error:
Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
I also noticed that when this error is generated, an instance of WINWORD.EXE is created and hangs, but the file is associated to Office 365, product version 16.0.xxx.
I am assuming that the (at least one) source of the error is the incompatibility between the .dll I'm using and the version of Word installed on my development machine.
QUESTION
Is it possible to perform office automation without having Microsoft Office installed on the server?
You don't need to install MS on your Server to use Office Automation!.
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.
Is it possible to perform office automation without having Microsoft Office installed on the server?
No, it is not possible. Instead, you may consider using the Open XML SDK if you deal with open XML documents only. Otherwise, you may consider using any third-party components designed for the server-side execution, for example, Aspose.
The Considerations for server-side Automation of Office article states the following:
All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.
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.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
i have developed a website that allows users convert existing word file to PDF and download it, included references to Office.interop.word, and the site works fine on my development machine. When I uploaded it to my production server the functions not working in the server, In the server also installed MS-word.
even i tried below methods
In the command line put DCOMCNFG
Component Services -> Computers -> My Computer -> DCOM Config
Find "Microsoft Word 97 - 2003 Document" (If it is missing check if your Word is also 64 bit (if your Windows is))
Right click -> Properties
Go To Tab Security and Edit the "Customize" radio buttons so that IIS_IUSRS could have rights for launch and access
Go to Tab Identity and choose "The interactive user"
all this fails then i have tried to tab "General" and in "Authentication Level" drop down choose "None".
still the error continue...
Error : "Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error:
80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE))."
Can any one help me?
You have reached a dead end. Running Office programs inside an ASP.NET webserver is not supported:
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.
I would suggest to find other ways to do what you want. There are a lot of libraries capable of reading and writing Office documents without using Office itself.
Core Problem
The problem I am having is that connectivity to Exchange from Outlook is blocked while executing an integration test through the Microsoft Test Agent (i.e. Outlook is in the disconnected state). The test is launched through Microsoft Test Manager.
Below is the code for the integration test I am having problems with and I simplified the code as much as possible to rule out code within the integration test causing the problem. I also eliminated all other tests from running.
[TestMethod]
public void LaunchOutlook()
{
Process.Start(new ProcessStartInfo(#"C:\Program Files (x86)\Microsoft Office\Office14\Outlook.exe"));
Thread.Sleep(120000);
}
I can change how long Outlook is blocked by changing the Thread.Sleep timeout. While the test is running, I can restart Outlook and Outlook is still blocked. After the test ends while Outlook is still running, connectivity to Exchange is restored. This happens for Outlook 2010 and Outlook 2013. If I run the integration test within a console app, Outlook connectivity is not blocked. If I run the test code manually through MSTest.exe, Outlook connectivity is not blocked. The only way it’s blocked is if the integration test is executed by the Microsoft Test Agent which is the required approach for integration testing.
More details on the problem
Outlook is running on a machine that is part of a Hyper-V Lab with network isolation enabled. There are other machines within the same lab that have Outlook instances pointed against the same Exchange server. Executing the test on one machine causes Outlook connectivity issues with other machines within the same lab where the Outlook instances are pointed at the same Exchange server.
I have small Hyper-V lab with network isolation enabled which is very similar to the lab mentioned above. The major difference is that it only has one machine with Outlook installed. This Outlook is able to connect to Exchange while executing the test above through Microsoft Test Manager. It is very clear that this is an environmental issue since it works in one lab and not the other. Both labs have the same Exchange server installed, and the same Microsoft Test Agent installed on all machines within the lab.
I have ruled out the Outlook version as being the issue since the larger lab contains the same Outlook version as the Outlook version in the smaller lab.
During test run
Notice that Outlook is in the disconnected state.
After test run.
Notice that Outlook is not connected to Exchange.
Environment Information
Outlook 2010 Version: (14.0.7113.5000) SP2 (14.0.1740.5002) 64-bit or 32-bit
Outlook 2013 Version: (15.0.4667.1000) MSO (15.0.4675.1002) 64-bit or 32-bit
Windows 7 Version: 6.1 (Build 7601: Service Pack 1)
Exchange 2013 Version: 15.0 (Build 847.32)
Windows Server 2008 R2 Version: 6.1 (Build 7601: Service Pack 1)
Microsoft Test Manager 2013 Version: 12.0.31101.0
TFS 2013 Update 4 Version: 12.0.31101.0
Microsoft Test Agent Version: 12.0.31101.0 Update 4
Troubleshooting Steps
I launched procmon and looked for failed TCP and UDP operations for indication of network failures and found none.
I turned on enable troubleshooting logging in Outlook and nothing within the logs looks obvious.
Pinging the Exchange server while the test is running still works.
I ran the integration test through the command line using MSTest.exe and outlook connectivity is not blocked.
Requesting Help
Can you please help me troubleshoot this problem? I see two approaches to identifying the problem.
1. Looking for differences between the two environments
2. Obtaining logs or other information that would expose the core problem.
I am open to suggestions or ideas especially if you have a different approach to solving the problem. Feel free to ask for other information related to the problem like logs, PowerShell commands, and registry values.
If you are short on time, can you at least post some suggestions or ideas related to resolving this problem?
Thanks,
Keith
After installing fiddler I figured out what the problem was. The Microsoft Test Agent was activating a proxy server which was blocking connectivity to exchange. The proxy server was activated due to having the ASP.Net Client Proxy for IntelliTrace and Test Impact turned on.
Below is a link to the article with the exact same problem.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/ecc0b342-8e4d-436c-90c2-5f11bce1e9d8/proxy-server-settings-being-set-automatically-which-is-causing-me-not-to-be-able-to-run-manual-test?forum=vsmantest
Situation: I have web application in my pc, who manipulates docs to generate pdfs with no problem. I configured my dcomcnfg to work fine because I had the problem with access permissions the COM.
The problem: I have to put the website in the server. The server has Win8 Enterprise. Doesn't have Visual Studio installed, only framework 4.0 and the Word Office. When I try to generate pdf it always return this error: Retrieving the COM class factory for component with CLSID ...
I run dcomcnfg and customized all permissions to IIS service (doesn't work and put to) Everyone. I Set all Launch and Activation permissions to allow Everyone, I also set Access Permissions and configuration permissions.. And still don't work.
I have to register the dll in server?(How I do it?)
I need more configurations?
I Have to install all Office?
ps: Office 2013
while it is not recommended to use this on server, there is a possible solution:
impersonate the admin in the asp.net application:
http://msdn.microsoft.com/en-us/library/aa292118%28v=vs.71%29.aspx
it may have security issue.
I am creating a simple asp.net web site that use office 2007/2010 automation .. when i published the website on the iis 7 on my local machine (window 7) have an exception
Retrieving the COM class factory for component with CLSID
{000209FF-0000-0000-C000-000000000046} failed due to the following error:
80080005 Server execution failed (Exception from HRESULT: 0x80080005
(CO_E_SERVER_EXEC_FAILURE)).
I have searched for this exception and i found that i have to set some permissions to office in DCOM Config.
I have opened the component services and opened DCOM Config, but i have not found Microsoft Word Document i have found only office word 97 - 2003.
can any one tell me how to solve this problem.
Found the answer here: DCOM Failure of Office Automation
If you are running a 64-bit server with 32-bit Office, you may have trouble finding this DCOM setting. You will need to run "MMC -32" from the command prompt to launch 32-bit MMC and then add 'Component Services' from the 'File > Add / Remove Snap-ins' menu.
Yes, office word 97 - 2003 is a right name of DCOM document (resp. application) Word 2007 or 2010. Don't ask me why...
Where could be the trouble?
The user must have access to desktop. If Word is called from ASP.NET, it has probably not this access. So set in dcomcnfg.exe an account explicitly. Don't use The launching user (it is a IIS identity, it hasn't its own desktop) and don't use The interactive user (it works only if some user is logged in).
In my solution I have set:
I have created new user (in user group), called WordUser
I have created in IIS new application pool with WordUser permission; Load User Profile must be true
DCOM I have set to use WordUser, on Security tab I've added WordUser wit Launch and activation Permission and Access Permission
Maybe another way is possible, but this should work.