I have a VSTO-Add-In for Outlook and need the information when i have to provide the VSTO-Runtime with the installation of the Add-In.
I have already found this article describing the prerequisites but I could construct cases which do not fit this description:
The article says "If Office 2010 Service Pack 1 (version 14, build 6029) or any newer Office version is installed, Office will take care of configuring the VSTO runtime."
=> This is telling me I do not need to provide the VSTO-Runtime in this case.
In the case that I have installed Office 2010 and manually install the ServicePack 2 I have the buildversion 7015 in my Outlook which is a greater version than 6029.
My installer recognizes this and does not provide the VSTO-Runtime.
But on starting Outlook after the installation I get an error saying, the .vsto-file could not be read.
This error only disappears after installing the VSTO-Runtime. Then the AddIn works fine.
What are the real cases in which i need to provide the VSTO-Runtime?
if you're using windows installer, just add it as prerequisite, which will create a Setup.exe, and add it as Launch Condition in your installer to show an error message, that Setup.exe should be run, or just make the Setup.exe run always, it will launch your .msi
have a look here - I guess this is also valid for Office 2013 .. just use the right components IDs !
Related
I've seen tons of posts and sites that address this issue. I've tried every solution I've found but none of them work (I've been trying to figure this out for days now). I have seen many posts with the same exact sounding issue, but either the solution didn't work for me or isn't applicable. With that said...
I have an add-in for Outlook 2007 that is intended to add text to the an email's title and body. It is installed for all users using an .msi file. There is an older version that I deployed last year that works fine. The new version I created has only a few minor input/output changes, nothing major. This new version works perfectly on my development computer in both debug from Visual Studio and from an actual install. However, I can't get it to work on a non-development computer. Here are the details on the program and target computer (development computer and target computer details are the same other than the fact that the target computer doesn't have Visual Studio):
-Using Visual Studio Professional 2013
-Written in Visual Basic
-Target Framework is .NET 4.0
-The add-in is only run once the "send" button on an email is clicked.
-Outlook version is Outlook 2007
-Operating system is Windows 7 Enterprise SP1 32-bit
The problem is that the add-in won't load on the target computer(yes, I know, a bazillion other people have had the same issue). As I said previously, it works fine on my computer in both debug and installed versions. This made me think that the other computer is missing something, so I tried installing the .NET 4.0 framework onto the target computer but it told me that it was already installed. I ran through everything I could think of to get it to work with no avail. Here's how it behaves:
-Installs fine with no errors.
-HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/Outlook/Addins/EmailMarkTool/LoadBehavior = 3 after installation.
-VSTO_LOGALERTS = 1
-VSTO_SUPPRESSDISPLAYALERTS = 0
-Outlook opens with no apparent errors.
-LoadBehavior = 0 immediately after Outlook is opened.
-Shows up in the Add-ins under "Inactive Application Add-ins."
-Never shows up under "Disabled Add-ins."
-In the "COM Add-Ins" dialog where I can check which add-ins to use, it shows the correct directory and the Load Behavior is "Unloaded."
-The add-in can be checked. When I click "OK" I don't get any errors. When I go back to the Add-ins, it is unchecked and "Unloaded" again.
-Setting the LoadBehavior to 3 doesn't help because it goes back to 0 as soon as Outlook is started again.
-I inserted a try-catch block into the New() function of the add-in that has a MsgBox pop-up and a Throw.
-I get absolutely no errors anywhere.
-No log file is generated.
I have tried uninstalling, rebuilding, and reinstalling multiple times all with the same result. I just can't figure out why it will work on my development computer but not the target computer. Thanks for reading all of this. I know it's a lot, but I needed to get the details out. Thanks in advance for any input!
[UPDATE]: I just created a brand new minimal add-in just to test if it would work but got the same results.
I found the problem!
The problem may be unique to Outlook 2007. It turns out Microsoft Office 2007 SP1 and SP2 had a bug that prevented it from running VSTO addins. Microsoft released a hotfix that fixes this issue (https://support.microsoft.com/en-us/kb/976477). This was added in to the release of Microsoft Office SP3. However, to activate the fix, a new registry flag must be created but that isn't automatically done with the fix, making the fix useless until you manually activate it (instructions and download here). So...
To enable VSTO addins in Outlook 2007, you have to add a subkey to this registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Common\General\
and add a DWORD "EnableLocalMachineVSTO" with the value set to 1.
I did this, restarted the computer for good measure, installed my addin for the 23rd time, and it installed and ran perfectly! I'm not sure how previous versions worked, though. It's possible that our system admins removed that subkey in an effort to bolster security at some point.
The loadbehaviour key problem you are experiencing is strange. Whilst I think this is probably not your solution, it could be, so its worth a try.
The target computer will need to have VSTO tools for office runtime installed.
You can download these tools are the following link - https://www.microsoft.com/en-GB/download/details.aspx?id=48217
I have the dreaded issue from my attempted installation of an MSI:
MSI (c) (98:B0) [18:01:22:818]: Invoking remote custom action. DLL: C:\DOCUME~1\sspencer\LOCALS~1\Temp\1\MSI19.tmp, Entrypoint: CheckFX
MSI (c) (98:FC) [18:01:22:833]: Cloaking enabled.
MSI (c) (98:FC) [18:01:22:833]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (98:FC) [18:01:22:833]: Connected to service for CA interface.
Action ended 18:01:22: DIRCA_CheckFX. Return value 3.
After quite a bit of digging, this is actually indicating that the DLL failed to load outright, the CA server was unable to connect and start hitting the DLL entry points.
I used orca and 7zip to extract the custom action for the DIRCA_CheckFX which is inserted by Visual studio when the deployment project builds. I grabbed the DLL and then executed Dependency Walker in the host system (Server 2003 R2) which gave the error:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
I recompiled the system using the VS 2010 compiler, extracted the DLL and ran dependency walker on it, which did not create the same error. I.e VS 2010 compilation works, VS 2013 compilation fails as the included DLL won't load in the target environment.
My question is how do I troubleshoot which DLL(s) are missing in order to troubleshoot that error reported by Dependency Walker.
Must be installed VS 2010 from which you can get the valid file "dpca.dll".
Close Visual Studio 2013
Copy file with replace dpca.dll from
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\Deployment to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\VSI\bin.
Open Project
Rebuild
The preview of the .vdproj resurrection uses DLLs that don't support Windows XP or Server 2003. Microsoft posted an update that might have fixed that bug.
Here's what I did to workaround this issue for a 32-bit deployment project.
Build the setup project in VS2010 once. This package is not dogged by the issue but I didn't want to have to keep building in a different VS version.
Open the resulting msi with Orca, select the Binary table and export the content of MSVBDPCADLL to a file.
Now after you build it in VS2013 use Orca to import the exported data into Binary\MSVBDPCADLL to fix the package.
I have to do a similar thing with the 64-bit project but in this case it's to import the correct InstallUtil binary (being C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtilLib.dll).
Visual Studio deployment projects were so horrible that Microsoft removed them from Visual Studio 2012. Developers were so ignorant as to why they were horrible that they begged and begged for them to come back. The smart guys at Microsoft who understand MSI left the building and the people remaining caved to the developers asking for it to come back.
One of those really smart guys summed it up perfectly in a tweet:
The return of vdproj: Headshots, people, or they come back as walkers.
I wrote an article on my feelings: Visual Studio Installer Resurrection
So let's talk about the way the tool is failing you this time. Take a moment to read this article written by one of the other really smart ones to leave MSFT:
Zataoca: Custom actions are (generally) an admission of failure.
VDRPOJ created a custom action to do something MSI could have done natively and now it's failing. So let's say you find the DLL and fix it to work on your machine. What happens when you ship your MSI to 1,000,000 machines? How many machines will it fail out there? How many support calls will you get? How many tweets will you get that your product sucks?
Simply put, I'd redo your installer using a better tool such as Windows Installer XML and Industrial Strength Windows Installer XML. If you have the money to spend InstallShield Professional is a good choice also.
I have a WinForm program developed in VB.Net with Visual Studio 2005. The program needs Microsoft Office Runtime installed atleast on the computer to allow the application to run without any errors.
Is their a way to check the computer to see if the minimum of the Runtime or Microsoft Office is installed on the computer? If either isn't I would like to display a message to the user on the startup of the application that states to atleast go to Microsot's site (I have full link to Runtime Download) and download the runtime for free.
Or is their a way to include the runtime as a component with my install for the application so if it isn't installed on the computer already it will install when the application is installed?
Thanks
If you more specific details please specify the exact runtime you are interested in. Office has lots of them.
For a launch condition you can try this approach:
select your setup project in solution explorer
go to its Launch Conditions Editor
create a registry search which determines if the runtime is installed or not
create a new launch condition
add the registry search property as the condition
This way the installation stops and shows the message you specify if the search doesn't find anything.
Another approach is to include the runtime as a prerequisite:
select your setup project in Solution Explorer
right-click it and select Properties context menu
click Prerequisites button in the property page
check the prerequisite you want
If the prerequisite you want is not in this list, you will have to configure it manually.
I'm trying to diagnose why my Outlook plugin written in C#/VSTO 3.0/VS 2008 doesn't load after being installed.
The plugin works awesomely on my development machine, which has Visual Studio 2008 installed. I can't expect all my users to have all the prerequisites though so I went through these steps to write an installer:
http://msdn.microsoft.com/en-us/library/cc563937(loband).aspx
I installed the add-in on a fresh Windows XP SP 2 machine with a fresh install of Outlook 2007. It installs all the prereqs ok (.NET 3.5, VSTO 3.0 runtime, Windows Installer 3.1, 2007 PIAs). Outlook starts but the add-in isn't run. If I go to the Add-ins tab in the Trust Center, I see my add-in in the "Inactive Application Add-ins" section with the message "Not loaded. A runtime error occurred during the loading of the COM Add-in.".
Not sure how to find the specific error so I can fix it.
The reg keys look ok. Under HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\BlahAddin I see Description, FriendlyName, LoadBehavior (set to 3 until it fails after which if becomes set to 2), and Manifest.
Tried the VSTO_SUPPRESSDISPLAYALERTS environment variable trick and then launched Outlook from the command line but no output came out.
I have remote debugging more or less working but I'm not sure what to look for. I don't see my DLL loaded when I attach to Outlook, but then again maybe managed DLLs don't show up the same way in VS.
Any other ideas on next steps I could follow to produce a specific error I can diagnose?
Solved my problem after weeks of pain. The "Manifest" reg key was getting corrupted to some junk value during the setup build. It was a known Visual Studio bug that supposedly got fixed in Visual Studio 2008 SP 1, but apparently wasn't for me. Renaming the project name to be different from the plugin name fixed the problem. Random, huh?
Make sure you have try-catch handlers at the top level of all methods called by Outlook and log any exceptions you are unable to handle in some way. Focus your troubleshooting on methods like the Startup method and other methods called during initialization.
You probably want to debug this using the remote debugger. Share out the MSVCMON.EXE folder from your developer machine (in your Visual Studio folders in Program Files) on your test machine (share it with a UNC path), and launch Outlook under the debugger trapping (.NET) exceptions in your modules and putting breakpoints in your methods.
If you need to clean your test computer each time before you install your solution, you should probably run XP under a Virtual PC 2007 VM (free download) and switch to a differencing HD after setting up everything but your plugin to snapshot your pre-installed state once so you don't have to keep uninstalling/reinstalling as you make changes to your program to fix bugs.
Are you installing Debug builds or Release builds? Perhaps one flavor has different requirements. Just guessing.
-Mike [MSFT Office Dev]
On your machine, when you run the addin from Visual Studio, it should create a registry key in HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion{SomeGuid}. Make sure that these registry settings are also being deployed with your addin. They are the ones that allow your code to be trusted.
I just, quite anxiously, downloaded the spankin new WCF REST starter kit. The installed failed. Anyone else had this problem?
http://msdn.microsoft.com/en-us/netframework/cc950529.aspx
Edit: The install fails during the template installation. The VS JIT debugger window pops up. Nothing else is running the PC, I am running as an admin on XP Pro, and the error occurs from either the EXE or the MSI.
Yes, it just failed for me too. Got a warning about replacing an existing file during the template install, then a hard crash after I told it to continue.
EDIT: Just tried again - it worked. Did 3 things different:
Closed all running VS2008 SP1 instances
Read the install guide closer and chose to run setup.exe instead of the msi, and did "Run As Administrator"
Didn't close the MSI installer until the delayed template installer had completed.
Here's the Install Guide:
SYSTEM REQUIREMENTS:
Windows Vista OR Windows Server 2008 OR Windows Server 2003
Visual Studio 2008 SP1
INSTALL AND USAGE STEPS:
Before installing, remember to uninstall any versions you have installed on the machine (see the Uninstall section below for steps to uninstall).
Run the setup.exe in administrator mode (right click on setup.exe and select 'Run as Administrator')
The install process will launch a visual studio installer. Remember to click through the visual studio installer to install the templates. NOTE: You may miss the vsi that is launched, so be sure to finish both the vsi and setup.exe installs to ensure that the whole install process is complete.
While running the vsi, you will get a prompt, which you can safely accept to continue.
Once installed, build the Microsoft.ServiceModel.web project installed on your machine.
You need to reference the Microsoft.ServiceModel.Web.dll assembly from the template generated projects, as well as from the samples. Please remember to verify this while using your templates and projects.
Note that you may also use a project reference instead.
There is a solution that includes all the samples provided in the "WCF REST Starter Kit\Samples\WCF REST Starter Kit Samples" location. This gives you a way to easily try out all the samples from one place.