I'm searching for some complete sample of wix project with reference to .NET dll (complete wix VS project, .net dll VS project, and compiled .net dll).
I'm trying to run SampleAskKeyNet and constantly I got error "There is a problem with this Windows Installer package. A DLL required for this installation to complete could not be run. Contact your support personnel or package vendor and I'm trying to find what I made wrong.
I created wix project in VS, .net dll project in VS, compiled dll project, copy over CheckPidPackage.dll to wix VS project directory and compile wix project. Then I run it and I get this error.
Link mentioned in accepted answer(by user431821) was indeed helpful but posting the exact thing which was helpful to me.
Custom actions project creates 2 dlls. If project is CustomActionProject, it will create CustomActionProject.dll and CustomActionProject.CA.dll
I was referencing to CustomActionProject.dll as below which is regular dll.
<Binary Id="CustomActionProject"
src="..\CustomActionProject\bin\$(var.Configuration)\CustomActionProject.dll" />
<CustomAction Id="MyAction"
Return="check"
BinaryKey="CustomActionProject"
DllEntry="Validate"/>
WIX creates CustomActionProject.CA.dll which is actually NOT the .NET managed assembly but unmanaged assembly. SO we have to refer to it instead of regular one.
<Binary Id="CustomActionProject"
src="..\CustomActionProject\bin\$(var.Configuration)\CustomActionProject.CA.dll" />
<CustomAction Id="MyAction"
Return="check"
BinaryKey="CustomActionProject"
DllEntry="Validate"/>
This solved my issue.
Maybe this could be useful: http://www.codeproject.com/KB/install/wixcustomaction.aspx
For me, it was my CustomAction DllEntry did not match my method name. i.e.
<CustomAction Id="CheckingPID" BinaryKey="CheckPID.CA" DllEntry="BadValue" />
public static ActionResult CheckPID(Session session)
I forgot to use MakeSfxCA.exe on dll in order to wrap it.
More details here Custom Action in C# used via WiX fails with error 1154 and here http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
Related
My wix wxs has a CustomAction written by c++: HSRInstall.dll. Inside this dll, windows swdevice.lib, new.lib are linked. So it requires running with vcruntime140.dll. When user execute this msi package on a clean install windows server 2019 datacenter, without a vcruntime140.dll in C:\Windows\System32, it will fail to be installed.
<Binary Id="HSRInstalldll" SourceFile="HSRInstall.dll" />
<CustomAction Id="deletehsrservicecache" BinaryKey="HSRInstalldll" DllEntry="HSRCustomAction" Execute="deferred" Impersonate="no" Return="ignore" />
When I add vcruntime140.dll as binary element in wxs, its file name is changed when installing. How to add the vcruntime library that the dynamic library depends on to the wix package? Thanks!
The best option is to statically link the C runtime (CRT) into your custom action dll. That way you do not have a dependency outside of your installation package.
We statically link the CRT in all the WiX custom actions.
I am using WixSetup project for my application, which generates msi as output successfully. Now, I have to add few more details-
Question 1: Check pre-requisites before installation:
As a part of pre-requisites, I have to check few conditions in product.wxs file (Similar to .NET Framework 4.0)
<PropertyRef Id="NETFRAMEWORK40FULL"/>
<Condition Message="[ProductName] requires .NET Framework 4.0.">Installed OR NETFRAMEWORK40FULL</Condition>
How to add pre-requisite condition in product.wxs file with registry entry check?
Question 2: Adding redistributable packages in msi
Also, I need to add couple of redistributable items in msi, which will be shipped with msi.
How I can add these packages in msi?
For the first point, the WiX documentation covers this exact scenario. See http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/read_a_registry_entry.html
With your second question, this is generally done by creating a bootstrapper bundle, which is a separate wix project that runs through a series of .msi files in sequence. Bootstrapper projects are generally quite simple to set up.
What's the point of the WixMbaPrereqPackageId and WixMbaPrereqLicenseUrl wix variables?
<WixVariable Id="WixMbaPrereqPackageId" Value="Netfx4Full" />
<WixVariable Id="WixMbaPrereqLicenseUrl" Value="NetfxLicense.rtf" />
Are they only required if your bootstrapper application is of type ManagedBootstrapperApplicationHost?
I've only seen examples with them having "NetFx" values:
is that always the case?
Does that imply that my custom bootstrapper library would always need the .NET framework as a pre-requisite?
In that case can't I just have a PackageGroup with a ExePackage for the .NET framework installer?
If there is official documentation about these two variables, where is it?
Yes the variables are only relevant for Managed Bootstrapper Applications.
I believe you can reference other package groups and include any packages as MBA prerequisites but I've never tried it.
No, only managed bootstrappers require the .Net framework. You can implement a native bootstrapper application (C++/COM).
http://wixtoolset.org/documentation/manual/v3/bundle/ba/
Remember that there is a difference between prerequisites of the installed application and prerequisites of the bootstrapper itself. For example, If your bootstrapper gathers and validates database connection info, then that database's API package will need to be installed before your bootstrapper is executed.
Not that I know of. But WiX is open source, you can check for your self.
I'm trying to register a library on COM using WiX installer, but it seems to be ignoring me.
What I've tried so far is:
Used heat.exe to harvest all the info corresponding to the .dll.
Created a fragment containing all the information that I harvested from heat.exe.
I copied all the harvested information into a single component, to make things easier.
I call the component using a ComponentRef that points to the component containing the related info for the dll to register.
I used a custom action to register it to the COM:
<CustomAction Id="RegisterComLibrary" Directory="ComPublishDllFolder" ExeCommand="regsvr32.exe /s [ComPublishDllFolder]MyLibrary.dll />
Insert the CustomAction in the InstallExecuteSequence:
<InstallExecuteSequence>
<Custom Action="RegisterComLibrary" After="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
But then, when I try to find the .dll in the COM using oleview or trying to use it with Visual Studio, I can't see it.
What I'm doing wrong?
NOTE: I'm getting the following message while trying to register it manually:
The module "MyComObject.dll" was loaded but the call to DllRegisterServer failed.
Ensure that "MyComObject.dll" is a valid DLL or OCX and try again.
Sorry, it was completely my fault. A misunderstanding of how .Net dlls published in COM work.
When I published my .Net compiled dll in COM and tried to use it in a .Net project, it launched a message saying that I can't use a COM library compiled in .Net, as it is a .Net library.
At first I thought it was a mistake, but actually, if I try to use the library in a C++ project (for example), it works fine.
The problem is that Visual Studio doesn't allow to consum COM libraries published in the same language that you built your project, apparently...
I am trying to write a custom actions class library for my WiX install package. I've read that I should use CustomActionAttribute to mark the methods that I am planning to call from install package. There is no Votive plugin for VS2010, so when I type [CustomAction] above my method name, VS2010 doesn't find it. So what should I do to write a custom action method?
There is Voitve support for Visual Studio 2010 in Wix 3.5 and up. With Votive you get a project template for creating managed custom actions which will set up all of the dependencies you need to add the CustomAction attribute.
You can add a reference to the Microsoft.Deployment.WindowsInstaller.dll to resolve the reference manually, but the project template sets up a few more needed steps to create the CA.
From this and other blog posts Rob has made, I thought WiX v3.5's Votive had VS2010 support, just not out of the box (last minute ship-decision?). Someone correct me if I'm wrong.