I have an Outlook Add-in(under development) which was working fine on my old system. I decided to migrate to a new system(for better performance), when I have done so(IN DEBUG MODE), I saw that after some time the Add-in is not visible in Outlook(neither in COM AND disabled window).
Specifications I am using:
System type is 64-bit OS, x64-based processor
Microsoft Visual Studio Community 2019 Version 16.5 with .NET framework 4.7.2
Microsoft Office 365(16.012730.20144) 32-bit
Troubleshoots I tried:
1) Checked Build Office solutions, for verifying all items are generating and working properly.
Registry entry is generating correctly.
VSTO file(bin/debug) is getting installed successfully(when I manually double click that)
2) Troubleshooting by Event Viewer:
No error's related to Outlook(as a source).
Possibly related error's:
i) Source - DistributedCOM : The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{6B3B8D23-FA8D-40B9-8DBD-B950333E2C52}
and APPID
{4839DDB7-58C2-48F5-8283-E1D1807D0D7D}
to the user NT AUTHORITY\LOCAL SERVICE SID (S-1-5-19) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.
ii) Other Errors are from source PerfNet and NDIS(Which I suppose is not related to this topic)
3) Troubleshooting by Process Explorer:
Their is no outlook Add-in DLL present in process explorer.
4) Troubleshooting by Process Monitor:
I am new with procmon, so just used some basics like, applied a filter with Outlook process name(including registry, file system, Network, process and thread activities).
And the results were SUCCESS, BUFFER TOO SMALL, NAME NOT FOUND, NO MORE ENTERIES other. Their was nothing I can relate with my issue.
Other Information
After this issue, I made a same new project and it worked fine, but the same happened(Add-in not visible) after some time. And I have done this(Created new project) four times till now. What I observed is, when I create a new Add-in with same name, the issue is same, so I have to choose different name every-time.
I am not able to find any error description for this. So can anybody please tell me what is the issue here OR how I can troubleshoot more(with above tools or new one).
Thanks in advance.
If you don't see your add-in listed in the COM add-ins dialog of Office applications, the problem is related to Windows registry keys required. Read more about them in the Registry entries for VSTO Add-ins article.
It seems something is wrong with your add-in registry entries (maybe permissions). And the issue can be related to Windows/Office bitness. Most probably you had another Office edition (bitness) installed on the old system (or Windows).
Related
I am currently working with visual studio 2017 with 4.6.1 .net framework. I created setup file for my desktop application the setup installs and runs perfectly in my system. The issue is that the setup installs successfully in other computers but the application not getting opened.
edit
Downloaded .net framework in client system but still same issue occurs.
edit 2
I ran a dependency scan using Dependency walker. It said there were a bunch of files the system could not find - error opening file. The system cannot find the files specified.
API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
DCOMP.DLL
IESHIMS.DLL
Also, there was an error with modules with an x86 type found - including the setup.exe - but I am unaware how this happened. I have selected 64 wherever I saw the option listed. Please find the screenshot. If this is indeed the issue, how do I solve this?
Application Launch Problems: Here is a short version: WPF application crashes when I launch. Chattier version. Nice one from Martin Prikryl: Application does not work when installed with Inno Setup
Logs: Always check all event logs, application logs and MSI logs - if available. Just to mention it. Maybe try to attach debugger for testing as described here - provided the application gets off the ground at all. Then step through code.
The Usual Culprits: You probably just lack a runtime (example), have a bitness problem (32/64-bit) or insufficient permissions / privileges, or configuration errors (ini, xml, registry, etc...).
To summarize - torpedos, full spread below - nothing too dumb not to mention :-):
Missing Runtimes: First, always check for missing runtimes. For example: .Net, .Net Core, Java, Silverlight,
Direct X (used even for applications now), VC++ Runtime, MS-XML (legacy), etc.... Remember that they come in different versions and some can not co-exist on the box whilst others
can run side-by-side.
Error Code: Looking up error codes and exception messages.
"The Magic Number Database" - online lookup.
Checking Error Codes - several tools and approaches.
Debugging Tools: Some information on debugging tools.
Tools to debug dependency issues - ProcMon.exe, VS, Dependency Walker, etc...
COM dependency errors
Essential service debugging tools:
Event Viewer, Task Manager, Services.msc
Process Explorer, NET command, SC.exe
Windows Services Frequently Asked Questions (FAQ)
ProcMon.exe: The tool of the trade. The one-size-fits-all
tool. The bee's knees, the topper-most, the quantum leap, the cat's
pajamas (yes, it is a Top Gear Hamster allusion). It can be a challenge to use it effectively, but it is the
best general-purpose debugging tool that is free.
Quick, Rudimentary Sample
Hanselman's longer video sample
Other Ideas:
Configuration Settings?
Dev-box sins: Hard coded references? Test Servers / UAT links?
Manifests, INI files and XMLfiles?
Registry settings? HKLM / HKCU
Connection strings. See Authentication & Authorization section below as well.
Platform & Bitness? (ARM, Intel 32 / 64, etc...).
Very common to read from wrong registry hive (the classic time waster):
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MyApp\MySettings (32-bit)
HKEY_LOCAL_MACHINE\SOFTWARE\MyApp\MySettings (64-bit)
Prerequisites & Dependencies?
On the topic of dependency scanning and debugging.
Dependency Walker: Types of dependencies.
Does Fuslogvw.exe tell you anything? (.NET assembly binding failures for a .NET application). How the Runtime Locates Assemblies
Quick check: Visual Studio modules view
Missing / Broken Registration (indirect dependencies)
Missing COM, COM Interop (regasm.exe), registrationless COM (manifest based)
Calling a .NET Component from a COM Component
Calling COM Components from .NET Clients
Broken Side-By-Side Win32 Assembly Manifest (obscure, can be caused by sloppy corporate application repackaging, may strike seemingly random PCs)
GAC installation?
Two GACs exist.
GAC / WinSxS Commit Issues: GAC / WinSXS files don't get installed into the GAC until the commit phase which is after StartServices.
Permissions & Privilege? - local - ACL permissions and NT privileges?
ProcMon.exe
Resolving Permission Denied:
System.UnauthorizedAccessException while running .exe under program files
WiX after installation my exe file doesn't work by double click, only run as administrator work
Authentication / Authorization - network related
Local user, domain user, Active Directory: group membership, group policy, etc...
Launching User: User profile issues? Maybe try with another user logged on where it fails?
Authentication Mode: Windows Authentication. SQL Server Authentication, etc...
General Network & Proxy issues? (proxies, WINS, DNS and all the complexities involved in networking. UNC paths reachable?)
Licensing? (conceivably related to hardware dongles and drivers)
Security software interference? (software / hardware firewall, anti-virus, encryption tools and suites, etc...)
OS version or edition? (Windows 7 problems)
Localization? Non-English systems?
Drivers?
Hardware?
Encoding?
System corruption? (wrong time, disk errors, file and path names are too long, disk full, "wrong something")
Target Machine Nature? Virtuals? SOE? Are the target machines real machines? Test machines?
Locking / Blocking / In-Use files and registry keys?
Malware? Can cause practically anything in terms of problems.
Links:
WiX Toolset PermissionEx Problem - App Does Not Run After Installation
EXE file is not working
make sure that the 4.6.1 .net framework is installed on the client system.Because the application requires .net frame work installed on the computer
To successfully deploy an application, you must also deploy all components that are referenced by the application.View the Deployment Process
Users might need administrative permissions or similar user permissions on the computer to install bootstrapped components. For ClickOnce applications, this means that the user might need administrative permissions to install the application regardless of the security level specified by the application. After the application is installed, the user can run the application without administrative permissions.
I am assuming you and your client are running install and application run as Administrator.
Possible root cause:
System prerequisite is not meet, you should check all dependencies is ready on the target client system, or add the prerequisite to your installation guide
Privilege issues, you might copy files or change registry locally with administrator rights, but the client is not. If so, you need change files to "C:\Users{username}\AppData\Roaming" or install with administrator privilege on the client system.
In such a situation, app possibly crashed in client system:
Check your application log if any errors
Check windows Log if any errors
Dump system info using WinDbg.exe and debug it
I also faced that kind of problem before.
Just try to install another location not inside the program file of C:\ Drive. You may choose different drive or you may install in C drive also but not inside the program files.
Unlike the test tool for Windows 10, which is part of the Windows 10 SDK, Microsoft went out of their way to make the certification tool for Windows Server 2016 complicated.
I installed my test application and specified the path to the Inno Setup installer, off the Downloads folder, and specified the location of the binary files, namely the Program Files location, and the screen shown, I specified the process name, basically the executable file name. At least System Internal's Process Monitor utility said that was the name.
As you can see, I got thrown an error.
Log Time: 12/04/2018 08:57:21
MethodName:: ApplicationRunningViewModel.VerifyApplication
Message:
No running application's process found after your application installation.
==================================================================
Log Time: 12/04/2018 08:57:58
MethodName:: ApplicationRunningViewModel.VerifyAppProcess
Message:
Process not found in snapshot file.
==================================================================
How do I resolve the error? Basically, how is the steps to use this test tool?
Background:
I had previously certified my application for Windows 10 in the Windows Platform Ready / Winqual area of Microsoft and obtained the Microsoft Gold Application Development competency.
I was expecting to simply pay the yearly extortion fee, $5400, when I logged into the portal, saw the new redesigned Partner Center, and went to the Competency Summary section, where I saw the message that I am in danger to lose the competency. Microsoft apparently did away application certification based competencies for Application Development. Talking to MS external support, I was told what I already saw on my own that the Silver ISV is the only path forward testing against Windows Server 2016. My attempts to talk to a real Microsoft employee or find a real solution failed miserably. I think talking to Google is easier. I hope that MS straightens things out for next year. By the way, the Platform Ready / WinQual area disappeared as well as all certifications.
That brings me to my question. I am trying to use the Windows Server 2016 test tool (2019 was not available last week for download, hence 2016).
I already installed the application. It works fine on Windows Server 2016, just Microsoft did not make application verification easy.
How do I resolve this error? What piece of information does it want and how do I obtain it?
I found the same error while testing my application using the Certification Test Tool 1.0 for Windows Server for Windows Server 2019.
I just changed the sequence of the test. I did launch the tool and then installed my application. If you cancel the test your application must be reinstalled in order for the test tool to recognize your process. Everything worked as expected
I got another error while using the Certification Test Tool Preview for Windows Server 2016. He couldn't validate my signed assemblies because the tool verify the aseemblies signature usign the signtool.exe instead of sn.exe. If you signed your assemblies using the sn.exe, neither of the test tools for Windows server 2016 & 2019 will validate your signed assemblies. I had to check the log file generated by the test tool and sign the assemblies manually using the signtool.exe.
I hope this information help someone havign the same issues.
Greetings
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 a PowerPoint 2010 application-level add-in developed using VS2012 and VSTO. It works with PowerPoint 2007 too. I built an installer for it using the (terrible) InstallShield LE crippleware provided with VS2012. I've been able to install it on various test machines, but now that I'm trying to deploy it to a client, they can't install it on some machines.
One user at the client's site can install it, but that user works in IT and has admin rights on his machine. However, when the IT admins try to install it on a "normal" user's machine, the install seems to go OK but the add-in is not loaded by PowerPoint.
The "COM add-ins" dialog shows the message:
Load behavior: Not loaded. The Managed Add-in Loader failed to initialize.
[In case it's relevant, this client uses Office 2007. Note however that it works OK on Office 2007 both on my test hardware and for that one user at the client.]
Is there anything I can do to figure out why? Is there anything obvious that I should be doing as part of the installation? Clearly the registry entries are being set, because the add-in is listed in the COM Add-ins dialog. And I assume that all the required files are installed, because the installer works fine on other machines.
I guess it may be a security-related issue. I should note that I'm not doing anything security-wise, and I don't think the InstallShield thing is doing anything helpful in this regard. I don't know whether it's necessary to digitally sign my code (I haven't), or somehow set some security policy stuff (I wouldn't know how). I've seen some stuff on-line about using CasPol (?) to apply security settings to add-ins, but that applied to older versions of VS and/or ClickOnce, and I wasn't sure whether I needed any of that.
It turns out that the VSTO runtime is not installed with Office 2007 (it is installed with Office 2010). The IT user who could load the add-in already had it because he'd installed something else that included it (I guess). The other users did not have it.
So, I updated my installer to include it, and it now works.
We have an Excel workbook which has c# VSTO code in it and two .NET DLLs that sit behind it. The spreadsheet used to work for all users in the organisation.
Recently our IT department had a problem with the OU which deleted all user accounts. The accounts were restored but since then users in our London office have not had the added functionality when they load the spreadsheet. Only users in the New York office and one developer (who has compiled the solution since) can use the functionality.
The files are all held in one directory on a shared network drive.
We have adjusted the manifest to reflect this location.
We have added the directory as a trusted site for code access security on the machine.
The office 2003 PIAs are installed and working as we have another application level extension installed on the machines and this is working correctly.
The .NET framework 3.5 is installed on all machines - as evidenced by the application extension.
VSTO 2005 SE Runtime is installed.
We've followed several how-to's from the internet to no avail, including:
http://msdn.microsoft.com/en-us/library/bb332051.aspx#8
We have a suspicion that there is a security problem as the first line of our code is a logging message and this is not being hit.
No error message is given by excel, the spreadsheet opens and is usable but there is no access to any code and all buttons are disabled.
Any help would be massively appreciated as we've spent many hours trying to figure this out!
Thanks
***************EDIT******************************
Here's the actual cause of the problem from my IT Dept:
...was caused by the Organisational Unit container they were held in being
deleted. This was restored and group memberships and distribution lists access
for individual accounts were then added manually
Turns out the problem was that over the weekend IT had downgraded all our versions of Excel from Professional to Standard. Not all VSTO works in Excel Standard, but it doesn't tell you this, it just doesn't work.
After upgrading we're all happy again!
Cheers