I created a Outlook 2010 Add-In in VS2012 . For creating a installer i used install shield. Installer got created successfully and is running fine on my (development) system. But the same addin throws a error on deploying it on another machine.
Error: Usual functionality of the add in are working but it throws a
error--- An attempt was made to load a program with an incorrect
format. (Exception from HRESULT: 0x8007000B)
Note: In my addin project i use a C++ dll for calling it's methods (through DLLImport). In my machine it works perfectly through the setup but in another machine it throws the error.
Some More Info : Both the system are 64 bit. The registry is getting created properly on target machine.
I have tried a lot but not able to find a result. Any help will be highly appreciated.
Related
I'm trying to add a reference to 'Microsoft Outlook 16.0 Object Library' in a C# .NET 4.6.1 WPF project, because I have office 2016 installed. Previous versions of the Object Library are incompatible with the 2016 version of office.
If I use Excel's VBA editor, 'Microsoft Outlook 16.0 Object Library' is listed, and exists in C:\Program Files\WindowsApps\Microsoft.Office.Desktop_16010.9126.2116.0_x86_8wekyb3d8bbwe\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\MSOUTL.OLB, as you can see below:
However, when I use Visual Studio, the COM tab does not list 'Microsoft Office 16.0 Object Library', and when I try to browse to C:\Program Files\WindowsApps, i get 'You dont currently have permission to access this folder', and clicking 'Continue' (to get access) results in 'You have been denied permission to access this folder'.
So basically, the Office 2016 dlls seem to have been tucked away in a folder that is inaccessible to man, dog, and local administrator.
All I'm trying to do is connect to the open Outlook application, and then send an email with an attachment, so perhaps another question to ask is, is there some new fangled way to communicate with Outlook 2016 that hasn't cropped up in my Googleathon?
Also worth noting is that my version of office is installed as a 'Windows Store Application' and therefore does not appear on the usual Add/Remove programs list, so I can't find any 'repair' options for the installation.
Thanks.
Further investigation reveals that I am doing the right thing - trying to add a COM reference to 'Microsoft Outlook 16.0 Object Library' is now the correct way to target Outlook ... https://stackoverflow.com/a/21018418/5040941.
I've checked the GAC, and the assemblies aren't registered. I've done a repair via the 'Apps and Features' right-click start menu option, and they still aren't appearing - it's as if the Windows Store apps just shove their dlls into the Program Files\WindowsApps\* folder, and don't bother to register them in the GAC.
In answer to the much appreciated comments!
Using the following code
Outlook.Application application = (Outlook.Application)Marshal.GetActiveObject("Outlook.Application");
If I use the nuget Microsoft.Office.Interop.Outlook package, i get a System.Runtime.InteropServices.COMException: 'Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))' exception.
If I try using Microsoft Outlook 15.0 Object Library or Microsoft Outlook 14.0 Object Library references via the Assemblies/Extensions tab of Add Reference, I get a System.Runtime.InteropServices.COMException: 'Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))' exception.
I don't think accessing the WindowsApps folder is the way to go.
Firstly, it's locked down for some reason which typically indicates the potential for trouble if i start digging around and changing security permissions, not to mention the fact that maintaining a copy of the latest dll in my solution will undoubtedly add unnecessary complexity to my project.
Secondly, but more importantly, if I have office installed, and I can access 'Microsoft Outlook 16.0 Object Library' from Excel Vba, then why can't I access it from Visual Studio?
There is obviously some issue with the installation not registering the dlls properly, only Excel has some trick it uses to make the reference available anyway.
Has anyone reading this managed to install Office 365/2016 Windows Store and found a reference to 'Microsoft Outlook 16.0 Object Library' in Visual Studio?
Am I the only with this problem?! Because it affects multiple computers in my office running Windows 10 and Office 365 ...
In answer to RogerN (thanks), please see the image below - I don't have Microsoft.Office.Interop.Outlook version 16 listed, and Microsoft.Office.Core isn't listed either.
If I try to use the v15 library, I get the following error:
System.Runtime.InteropServices.COMException
HResult=0x80040154
Message=Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
Source=mscorlib
*AND THE ANSWER IS *
The two computers I bought from Dell are 64 bit, but they come preinstalled with 32 bit, windows store versions of MS Office 2016/365.
In order to fix the problem, I had to:
uninstall the store app from Settings > Apps > Apps&Features > Microsoft Office Desktop Apps > Uninstall
log into portal.office.com
select install office apps, advanced, choosing the 64-bit version
Quite why Dell think we want 32 bit versions installed on 64 bit machines, or why someone from Microsoft hasn't posted a solution to this problem, is beyond my understanding, but nevertheless, RogerN was correct. Thanks to everyone for taking time out their days to help me out.
Elaborating on my earlier comment: From what you've described, it sounds like you've installed a 32-bit version of Microsoft Office on a 64-bit machine. Only 32-bit COM objects would have been registered, and therefore a 64-bit .NET application would be unable to find them. If you search your registry, you ought to find that the 0006F03A-0000-0000-C000-000000000046 class ID is only registered under the Wow6432Node.
To resolve the issue, you could either install the 64-bit version of Office or force your .NET application to target the x86 platform.
I have been working on an outlook Addon using a visual studio VSTO project. When I run it as Debug or launch from within Visual studio Outlook (2016) launches and the addon works without an issue.
However, if I try to install it by navigating to the VSTO Deployment file and double click it I am presented with an error saying that ".net version 4 is not installed". I have attempted to run this as admin using the command line and am just presented with an error (this is because run as admin is missing if I right click on it).
The catch with this is that I've attempted to install the requested version of .net and am just told that it can't because I have a newer version installed.
Any help with this would be greatly appreciated.
Update: I have logged into a machine using admin credentials and it installed without an issue. So I think it might be a system or group policy issue.
We were able to deploy the application by invoking the application that is used to install VSTO files via the command line. This also allowed us to use a certificate when doing so.
The command used to install the certificate allowing it to run is winhttpcertcfg and then the exe VSTOInstaller.exe is ran with a path to the VSTO file as an argument using /i and then is done silently using /s.
I am having trouble with a MSBuild 14.0 issue. I am creating a UWP/x64 Application (we have written the source to be able to run on Windows 8.x, Windows 10 and now Windows 10 Mobile. My current environment is VS 2015 update 1 running on Windows 8.1. My code exists on a TFS 2013 local server. I have a build controller and build agent installed from TFS 2015 running on a separate server (server 2012 R2) assigned to my XAML Build Definition. I can build locally on my server within a Visual Studio 2015 session. When I Queue a Build. I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft.NetNative\Microsoft.Net.CoreRuntime.targets
(235): The "WireUpCoreRuntime" task failed unexpectedly.
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B) at
Microsoft.Build.Net.CoreRuntimeTask.WireUpCoreRuntime.CopyWin32Resources(String
lpPEFileToReadResourcesFrom, String lpPEFileToInsertResourcesInto)
at
Microsoft.Build.Net.CoreRuntimeTask.WireUpCoreRuntime.InternalExecute()
at Microsoft.Build.Net.CoreRuntimeTask.WireUpCoreRuntime.Execute()
at
Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at
Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
Initially I thought this was an environment issue with the build system not on a Windows 10 platform, however, if this was the case I would not be able to build locally in Visual Studio.
I have Disabled AV on my server for a build with no luck.
the build Configuration is x64/Release. I have also tried x64/Debug, ARM/Debug and ARM/Release. none of these build configurations work. I think it might have something to do with .NetNative but I cannot be certain.
This error usually occurs when the file image of a DLL or executable program is invalid, check following things first:
Make sure that you are not using a component that was created with a
different version of the .NET Framework.
Make sure that the file
image is a valid managed assembly or module.
Detailed information: Troubleshooting Exceptions: System.BadImageFormatException
Is there a way to make a COM or Interop work on IIS Server Deployed ASP.net MVC?
I created an MVC Site which have a reference to a custom maid Interop COM to a scanner machine.
It works on Debug mode on VS but, when I try to deploy it on IIS and access it. It gives me Retrieving the COM class factory for component with CLSID {3FEDB614-C25B-448C-AED3-2D38A6C95765} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
The Thing is, the dll it self is already installed on my Machine, I think it is working on debug mode cause the IIS from VS is running differently or because I have a reference of the DLL needed.
But in IIS Deployment. Error Occurs. Any Ideas?
My main goal here is, to run the site on a Local Network and everyone can communicate with that site that has the Scanner Installed on.
Easy Idea, but hard implementation for me. And I am not even sure, if the call that I am doing is going to be made in the Host, rather than the Client.
Looks like IIS application Bin folder doesn't have Interop dll, copy the Interop dll, it's named as Interop.[YourCom].dll. YourCom is nothing but original COM. So if the COM name is MyCom.dll, so Interop should be Interop.MyCom.dll. If it's working on Debug mode on VS, then it should be available in VS application Bin folder.
Prerequisite of Interop dll: COM should be register in same the system.
It ends up that, Even Registering it Manually, doesn't Help in my case, don't ask I HAVE NO IDEA WHY.
I resolve it by letting the VS studio Project Settings/Build Tab/ Register COM check mark do the Rest. But the trick is to Run VS in Administrator or you will have an error. Last step is right clicking the bin Folder and choosing add to project. Not really sure why it didn't work without it, because I am pretty sure it doesn't need to be in the current project since IIS will redirect anyway in the bin folder.
Interop name is already applied but like Maiti says, it is needed.
My company has login integration with GroupWise, and Exchange 5.5/2000+. The Exchange 5.5/GroupWise logic is done using wldap32.dll (win32), and so the login code is in a managed c++ class. When the configuration tool (or the backend service) tries to load the dll built off this managed c++ project on my XP development box, it works fine. On QA/Customer Windows 2003 boxes, a FileLoadException is thrown.
First off, this used to work fine. Secondly, I've validated the same working code on my box fails on the qa box.
How can I track down the cause of this exception?
Have you changed your development environment recently? In particular have you installed a service pack or new release of Visual Studio?
It appears you are linking against a C++ runtime that is not available on the client's server. You can use the Windows Event Viewer to identify the DLL failing to load, or if this shows nothing, use depends.exe to see what runtime DLLs are dependencies for your managed code.
Microsoft has moved to using side-by-side installation to handle "DLL hell", basically this allows multiple versions of a DLL to be installed (side-by-side) concurrently on a Windows installations and have applications load the correct version of the DLL at run-time. Recent releases of Visual Studio make use of this technology so I suspect this is the cause of your 'sudden' incompatibility.
Not to answer my own question, but support just updated the bug with the text following this paragraph. I'm still interested in thoughts on tracking down situations like this.
Resolved by downloading and installing the Visual C++ 2008 Redistributable
Package for Windows on the IMS:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&DisplayLang=en