I've been trying to do this seemingly simple task for over a day now. So I would appreciate if someone can shed some light on what am I missing here?
I wrote an Outlook 2007 add-in (in Visual Studio 2008, C# project) and now I'm trying to write an MSI installer for it (using WiX). The installation process also requires VS Tools For Office Runtime to be installed, which I do separately.
Then, the following are registry keys, that I've been testing it with for the current user. Using WiX mark-up:
<Component Id="RegistryRegAddin" Guid="{GUID}">
<RegistryKey Id="RegKey_AddIn" Root="HKCU" Key="Software\Microsoft\Office\Outlook\Addins\$(var.ProductThis)" ForceCreateOnInstall="yes" ForceDeleteOnUninstall="yes">
<RegistryValue Type="string" Name="Description" Value="$(var.AppDescr)" />
<RegistryValue Type="string" Name="FriendlyName" Value="$(var.ProductThis)" />
<RegistryValue Type="integer" Name="LoadBehavior" Value="3" />
<RegistryValue Type="string" Name="Manifest" Value="[INSTALLFOLDER]AddInName.vsto|vstolocal" />
</RegistryKey>
</Component>
So this works just fine for the current user.
But now I'm trying to change it so that the add-in is installed for all users. I modified HKCU to HKLM in the WiX registry markup above. But in that case, the MSI installs fine (on a 32-bit Windows 7 Pro), but my add-in doesn't load into Outlook.
Why!????
Then if I go in Outlook to Tools -> Trust Center -> Add-ins -> my add-in is in the "Inactive Application Add-ins" but when I try to check it to enable it, Outlook shows this message:
The connected state of Office Add-Ins registered in HKEY_LOCAL_MACHINE
cannot be changed.
Argh!!!!
But in that case, the MSI installs fine (on a 32-bit Windows 7 Pro), but my add-in doesn't load into Outlook.
There are multiple reasons why your add-in may not be loaded. Among them you can find the following points and possible diagnostic ways:
Make sure all the prerequisites were installed correctly.
No exceptions are thrown at startup. Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the
Startup event handler in your VSTO Add-in is executing.
Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again.
Use the Fuslogvw.exe utility for checking whether the right assemblies are loaded. See Assembly Binding Log Viewer for more information.
The MSI engine failure. Try to take a look at the MSI log files.
You may also find a similar case described on the VSTO AllUser addIn fails to load on several clients page.
I think this is specific to Office 2007. Try adding the following code fragment to your code:
<Component Id="EnableLocalMachineVSTO" Permanent="yes">
<Condition>ALLUSERS=1</Condition>
<RegistryKey Root="HKLM" Key="Software\Microsoft\Office\12.0\Common\General">
<RegistryValue Name="EnableLocalMachineVSTO" Value="1" Type="integer" KeyPath="yes" />
</RegistryKey>
</Component>
The EnableLocalMachineVSTO is the keyword you can put in the search box to learn more. This is one of the common issues with "my add-in works when installed as current user but doesn't when installed as local machine", AFAIK.
Related
ENVIRONMENT
VS2022
OFFICE 365
log4net 2.0.15
ISSUE:
I wrote a VSTO Add-In for Outlook and installed log4net as a NuGet package.
What I noticed is that when the Add-In is installed under HKCU, log4net writes to my log files just fine;
this includes internal debugging.
However, we would like to have the Add-In installed on a per-machine basis (HKLM). Under HKLM log4net does not write anywhere; even when I turn on the internal debugging.
NOTE: The following snippet works fine when the VSTO Add-In is installed under HKCU
<log4net>
<appender name="RollingFileAppenderAddin" type="log4net.Appender.RollingFileAppender">
<file type="log4net.Util.PatternString" value="%envFolderPath{UserProfile}\\MyLogs\\MyLog.txt" />
I have installed wix as a plugin in Visual studio. I am trying to search for if MATLAB Version 9.2 exists on the PC then allow installation or else abort. To achieve this I do like this
<Property Id="MATLABRUNTIMEEXISTS">
<RegistrySearch Id="Matlab_runtime_search"
Root="HKLM"
Key="SOFTWARE\MathWorks\MATLAB Runtime\9.2"
Name =" MATLABROOT"
Win64="yes"
Type="raw"/>
</Property>
<Condition Message="This application requires RUNTIME 9.2. Please install the Matlab runtime 9.2 then run this installer again.">
<![CDATA[Installed OR MATLABRUNTIMEEXISTS]]>
</Condition>
It works fine, and installer is halted when there is no MATLAB on PC. But even after installing MATLAB it stops the installer.
The MATLABROOT key is "REG_SZ" and "C:\Program Files\MATLAB\MATLAB Runtime".
So what I want to test is actually only the presence of MATLABROOT key.
I saw in other questions people are using <util:RegistrySearch>, but I am not able to use that. I receive error "unsupported extension element", even though I have UtilExtension as reference already added.
Could anyone suggest me what I need to do to actually make it work?
I'm trying to install a VSIX Extension into Visual Studio 2017 from a Setup created with the WIX Toolset.
I found this page:
http://wixtoolset.org/development/wips/5433-add-support-to-detect-and-install-vsix-packages-into-vs15/
But its not fully clear whether the "proposals" on that page were really implemented. I did a number of experiments, with no success.
Have the features posposed on the above page been implemented in WiX v3.11.1?
There seems to be some support for VS2017 in WIX v3.11.1, but when I use the VSExtension:VsixPackage element in my Product.wxs file, it seems that the latest VSIXInstaller.exe (of my VS2017 community) isn't found and my Setup Fails.
Can someone provide a working example for this?
Thanks!
I can only tell you my strategy for IsWiX:
https://github.com/iswix-llc/iswix
iswix/Source/Application/IsWiXNewAddIn/
iswix/Source/Installer/IsWiXNewAddInMM/
iswix/Source/Installer/IsWiX/Code/Product.wxs
I'm able to install to VS2013-2017 this way.
What is IsWiX?
https://github.com/iswix-llc/iswix-tutorials
PS- 60 min complimentary dev to dev screenshares are available.
Installing extensions in Visual Studio versions newer than 2015 is not supported by WiX, despite it being able to detect VS 2017 and VS 2019 instances … which is kind of odd to be honest.
There is still the option of using the detected installations to launch the installer, though that might break unexpectedly.
You can try this:
Add WiX VSExtension (obviously):
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:VSExtension="http://schemas.microsoft.com/wix/VSExtension">
Define and set a property containing the VSIX Installer location (done here for Visual Studio 2019):
<Property Id="Vs16VsixInstaller" Value="0" />
<SetProperty Action="SetVs16VsixInstaller" Id="Vs16VsixInstaller" Value="[VS2019_IDE_DIR]VSIXInstaller.exe" Sequence="both" After="AppSearch" />
Define a component containing the extension:
<Component Id="MyVSExtension" Directory="VisualStudioExtensionsFolder" Guid="PUT-GUID-HERE">
<RegistryValue KeyPath="yes" Root="HKMU" Key="Software\[Manufacturer]\[ProductName]" Name="MyVSExtensionInstalled" Type="string" Value="" />
<VSExtension:VsixPackage File="MyVSExtension.vsix" PackageId="PUT-PACKAGE-ID-HERE" VsixInstallerPathProperty="Vs16VsixInstaller" />
</Component>
This worked in my case and I don't think there is a much better way of doing this while also keeping the solution simple.
I have a WIX installer which I need to also install the VC++ 2015 runtime executable. I'm using the vcredist_x64.exe as opposed to the merge modules (see this thread). I can successfully launch the vcredist_x64.exe after my msi finishes installing my application by using a custom action... however, what I'd like to do is first check to see if the runtime files already exist. If they do, then I'll just finish without running the vcredist_x64.exe. Otherwise, I'll run the custom action to install the runtimes as well.
It took some digging, but I was able to find out that the 2015 runtimes have a registry key shown below:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x64
with an Installed value of 1 if they exist.
So, in my .wxs file I have the following registry search:
<!-- Visual C++ 2015 x64 -->
<Property Id="VCREDISTRUNTIMES2015INSTALLED">
<RegistrySearch Id="VCREDISTRUNTIMES2015SEARCH" Root="HKLM" Key="SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x64" Name="Installed" Type="raw" />
</Property>
Now, what I'd like to do is show a message on my exit dialog which says that if the runtimes aren't detected, then it will launch an installer to install them upon exit. Something like this:
<Property Id="WIXUI_EXITDIALOGOPTIONALTEXT" Value="Visual C++ Redistributable for Visual Studio 2015 is Required. Installation will proceed on exit.">
<Condition>VCREDISTRUNTIMES2015INSTALLED</Condition>
</Property>
However, this doesn't work. I get an error on the conditional tag and the project wont build. Assuming my registry search is setup correctly, can someone tell me how to properly add a conditional message on my exit dialog? Thanks!
Answering my own question... but here goes. It turns out that my registry search was just fine... but I needed to use "SetProperty" instead. So, something like this:
<SetProperty Id="WIXUI_EXITDIALOGOPTIONALTEXT" After="AppSearch" Value="The Visual C++ Redistributable Package for Visual Studio 2015 is Required. Installation will now install run-time components that are required to run C++ applications built using Visual Studio 2015.">
NOT VCREDISTRUNTIMES2015INSTALLED
</SetProperty>
Now, if the VCREDISTRUNTIMES2015INSTALLED is null (or false) then it will show the message on the exit dialog. Otherwise, there will be no message shown. Hope that helps.
I need to deploy a software setup targeting both, Windows 64bit and 32bit. I have two separate Windows Installer databases (created with WiX) for each platform, and I am using dotNetInstaller to combine both into a single installation bootstrapper executable.
I'm currently using version 1.10 of dotNetInstaller and set auto_close_if_installed=True, because I want to comletely hide the bootstrapper from the user. Still, dotNetInstaller insists on displaying a sill progress bar window while my installer is running, and doesn't really auto-close. The user needs to confirm a dialog box telling him that the application was successfully installed. But the real deal-breaker is that it doesn't support Windows 8 (yet).
Upgrading to a later version of dotNetInstaller seems to break auto_close_if_installed, so it's even worse.
So my question is: what is the current state of the art to deploy both setups in a single executable. Would Wix Burn be an option?
I know that in an ideal world, I simply provide my customers with separate installers for either platform. But they happen to be completely unaware of such subtleties, most of them don't even know what platform they are using.
I would definitely use Burn in this scenario. Something akin to the following:
<Wix>
<Bundle...>
<BootstrapperApplicationRef Id='WixStandardBootstrapperApplication.HyperlinkLicense' />
<Chain>
<MsiPackage InstallCondition='NOT VersionNT64' SourceFile='path\to\x86.msi' />
<MsiPackage InstallCondition='VersionNT64' SourceFile='path\to\x64.msi' />
</Chain>
</Bundle>
</Wix>
This is exactly one of the scenarios Burn was designed to handle.
You can do it in a single Wix via Conditions and Features.
<Feature Id='X86' Level='1'>
<ComponentRef Id='X86Feature1' />
<Condition Level="1">NOT VersionNT64</Condition>
</Feature>