-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExePackage elements need DetectCondition attribute #3
Comments
Will do. With previous releases there was no cheap way to detect extensions' presence but the new query API could make that possible now for v3s (doesn't have to load the entire Extension Manager API). Is that something BA functions could enable? |
Actually, that still wouldn't work for previous extension versions or on previous releases. If the DetectCondition were always false, it would at least attempt to install the extension each time which is almost a no-op (incurs detection time across all installed versions) to VSIXInstaller of the extension is installed. |
This came up today in a discussion. Basically, there's no conceivable way to author a However, to support uninstall, would it be possible to rely on a BA function? It seems, however, only a single BA function is supported and not something that can be provided by an extension. |
I have been trying to incorporate the bootstrapper into a WiX bundle for our internal extensions. It has been rather troublesome so far. We've had issues with the installer failing if we're just doing something like: <ExePackage DisplayName="VS Ext 1" Id="Vsix1" SourceFile="VSIXBootstrapper.exe" InstallCommand="/q ext1.vsix" Permanent="yes" DetectCondition="WixBundleInstalled">
<PayloadGroupRef Id="Vsix1" />
<ExitCode Behavior="success" Value="0" />
<ExitCode Behavior="success" Value="2" />
<ExitCode Behavior="success" Value="2003" />
</ExePackage> I don't exactly know why, but it sometimes this fails if the extension is already installed, so I proceeded to add this: <ExePackage DisplayName="Remove VS Ext 1" Id="RemoveVsix1" SourceFile="VSIXBootstrapper.exe" InstallCommand="/q /u:MY-GUID" UninstallCommand="/q /u:MY-GUID" DetectCondition="WixBundleInstalled">
<PayloadGroupRef Id="VSIXBootstrapper" />
<ExitCode Behavior="success" Value="0" />
<ExitCode Behavior="success" Value="2" />
<ExitCode Behavior="success" Value="1002" />
</ExePackage> That has worked, except that an upgrade now uninstalls the extension, installs the extension, and then runs the uninstaller of the previous version, which uninstalls the extension again. Got another bug report today. The uninstaller failed:
Some kind of .NET exception happened in the VSIX Installer, then the cache directory... got cleared? No real idea what's happening there, but we can't uninstall. Actual guidance on how to use the VSIX Bootstrapper in a WiX bundle would be nice because that wiki page is just wrong and leaves everyone trying to implement such an installer to a lot of guesswork. I'm almost tempted to just write my own VSIX bootstrapper that does all this stuff internally because trying to wrap WiX around this utility is painful to say the least. |
The VSIXBootstrapper is just a thin wrapper around VSIXInstaller. If VSIXInstaller failed, as you noted above, please file a bug report at https://developercommunity.visualstudio.com. |
I'm aware that I should file a bug report there for that specific issue, but thanks for mentioning it. I'll try to gather more data about that issue and might post the bug report then. |
How to write the DetectCondition expression? Colud you provide the example? I'm confused with this attribute. |
@yang-shuaijun please see https://wixtoolset.org for docs and support of WiX. |
In the example in the Samples wiki, the
ExePackage
element does not have aDetectCondition
attribute. You need aDetectCondition
forUninstallCommand
to be called. Honestly it is a long standing mistake in the WiX Toolset that theDetectCondition
was not required that is planned to be fixed in WiX Toolset v4.Would be good to add the
DetectCondition
attribute to the example.The text was updated successfully, but these errors were encountered: