I am using WiX to create a MSI that calls a managed Custom Action (CA) written with Votive in VS 2008. The CA targets .NET 32 bit Framework 3.5. When I run the setup it fails loading the CA since it cannot find the right framework version. In the MSI installation log are the lines
MSI (s) (5C:C0) [10:25:00:680]: Hello, I'm your 32bit Impersonated custom action server.
SFXCA: Extracting custom action to temporary directory: C:\Windows\Installer\MSI34ED.tmp-\
SFXCA: Binding to CLR version v4.0.30319
I have worked out that the issue is the wrong framework version is being loaded. It seems to be the inverse problem mentioned when trying to run a version 4 CA and version 2 of the framework is loaded by MSIExec (I assume it is the MSIExec that decides to load the framework).
I have VS 2010 installed on the box as well, but for reasons beyond my control I must use VS 2008 for the project. If I upgrade the project to VS 2010 everything runs as expected, since the CA is then targeted to .NET 4.0.
Is there some way I can get MSIExec to load .NET 2.0/3.5 when calling the Custom Action?
UPDATE: I have changed the CustomAction.config so that it now has
<!--<supportedRuntime version="v4.0" />-->
<supportedRuntime version="v2.0.50727"/>
and it has made no difference.
I have also found that it is the act of trying to load the CA into the debugger that is causing the exception. If I run the msi without breaking on the method, it runs as expected (no errors). SO I can deploy the setup as a .NET 3.5 setup, I just cannot debug the CA.
It looks like you cannot override the version of .Net used by MSIExec.
Aaron Stebner's blog entry Don't use managed code to write your custom actions! says:
Also, if you author a managed DLL custom action you leave your fate in the hands of Windows Installer, because it will use the latest version of the .NET Framework on the machine in all cases
Related
I'm creating an installer for a Windows desktop app, which has a dependency on another product that requires .NET 3.5
When installing this on Windows 10, .NET 3.5 is included and has to be enabled in Add/Remove Windows Features. I don't think it is valid to install a downloadable version of .NET 3.5 on Windows 10 (correct me if I'm wrong!).
So, is there a way to get WiX to enable the .NET 3.5 "feature" rather than downloading and installing it?
Not sure whether this is the correct way but you can try a custom action with the following command
dism.exe /online /enable-feature /featurename:NetFx3
You can get a list of all available features by dism /online /get-features if you want to try other windows features.
There is a way to install .NET 3.5 on Windows 10 and the latest Windows Server: to update a group policy value that will allow to download .NET 3.5 (blog post).
...open the command prompt and type "gpedit". The "Local Computer Policy Editor" opens where we can locate the necessary setting under the "Computer Configuration" > "Administrative Templates" > "System". On the left side, under "Settings", we can find a setting named "Specify settings for optional component installation and component repair"
This is what we are going to modify. Let's open it and check "Enabled" and then check the second option – "Download repair content and optional features directly from Windows Update instead of Windows Server Update Services (WSUS)" and click "OK":
Now, if we retry adding the .NET Framework 3.5, we can see that it succeeds...
I personally then revert this policy setting to its original value, if it was different.
WiX Samples: Some potentially helpful links in general:
WiX Quick Start Suggestions (with sample links).
https://helgeklein.com/blog/2014/09/real-world-example-wix-msi-application-installer/
Alternative Tools: Maybe keep in mind that commercial tools have features that are easier to use to get your product out there quickly. WiX is great though.
MSI Tools (comparing different MSI tools)
On WiX, setup GUI and Commercial tools
Prerequisites: I would suggest you add a LaunchCondition to the package to abort installation if the .NET framework is not there. You can bundle the .NET framework with your application, but I really do not recommend that: Outdated prerequisites in packages.
LaunchCondition: The concept of LaunchConditions checks for a certain condition to be true before installation is allowed to continue:
Check if prerequisites are installed before installing a windows installer package (please check this link at the very least - if you don't check other links)
An earlier answer on LaunchConditions.
Quick, inline sample:
<Condition Message="The .NET Framework 2.0 must be installed">
Installed OR NETFRAMEWORK20
</Condition>
WiX and .NET Framework: Some built-in measures to detect the .NET framwork.
How To: Check for .NET Framework Versions (official WiX documentation)
How to check for .net framework 4.7.1 with Wix 3.11
How can I detect whether .NET Framework 4.6.1 or higher is installed in WiX?
Link:
Wix IIS Version check launch condition not working
LaunchConditions and missing runtimes
I have a .NET library (dll) of helper methods specific to installing my product, that targets .NET 4.
However, the "main" WIX project is targeting .NET 3.5 (as specified in the documentation) (meaning it runs on the 2.0 runtime). It has custom actions that call into the above 4.0 dll.
When running the generated MSI, i get "BadImageFormat" exceptions, when the WIX runtime (running on 2.0 runtime) tries to load my 4.0 dll.
If I had direct access to a .NET 3.5 .exe, I could convince it to load a 4.0 dll by using the trick in its app.config.
However, the WIX runtime is loaded (by msiexec), as far as I can tell from the stack trace, through Interop.
Does anybody have a suggestion on how I could get this to run?
PS. I also tried making the "main" Wix project target 4.0 directly instead of 3.5, but then my setup dialogs will just fail to show.
I don't know how you have this setup in wixsharp, but in Visual Studio WiX has a project template for C#/DTF custom actions. It automatically includes a CustomAction.config that you can use to put SupportedRuntime elements in to achieve what you are trying to do.
Take a look at WIX and Custom Actions
The BadImageFormat exception means that you are attempting a cross architecture call somewhere in your calling sequence, 32-bit to 64-bit or vice versa. That might be a consequence of getting the incorrect framework, but not necessarily!
I am very new to the installer world.
I have successfully made an .msi for my application and it is building with short-cuts and also uninstalls correctly.
My next goal is to package .Net 4.5 with the installer and have it be installed prior to the installation of my application.
I also have a third party application that needs to be installed. It is packaged as an msi.
From what I can gather I need to develop a Bootstraper solution to have these applications install in sequence.
Can anyone provide a guide as to how to implement an installer in such a way? My searches have come up with a bunch of partial implementations with an assumption of the design of a Wix Bootstrapper Project in Visual Studio.
I hope this helps someone. It took me 5 hours to figure it out. Maybe, my bad, but did not find anything about it in the docs or blogs.
So my scenario is: VS 2012, WIX 3.6 with Burn bootsrapper, create a Setup executable in order to check .NET Framework 4.5 and install it by downloading if not installed already. Sounds simple. And it is. Actually very.
Create your MSI installer project (WIX Setup Project), to produce an installer for your application.
Create a WIX Bootstrapper Project for your Setup executable.
Follow the instructions here, to create your Boundle.wxs
Add a reference to the WixNetFxExtension.dll which can be found in the WIX program directory.
Include the following line in your Chain:
<PackageGroupRef Id="NetFx45Redist"/>
Actually the WixNetFx extension contains a working install package definition for the .NET Framework 4.5.
As caveman_dick mentioned, Burn in WiX 3.6 supports this but you may also want to take a look at dotNetInstaller (http://dblock.github.com/dotnetinstaller/). We use it to install .NET 4.0 but I'm sure it works for installing 4.5 as well. It can also install other MSI dependencies very easily.
I've created my program successfully. Now, I want to publish it. I've created a Setup Project in order to make an installation file. I've added .NET 4.0 Client and Windows Installer as project prerequisites (via Setup Project Properties → Prerequisites). After that, I build my project.
This produces these files:
Setup files, .NET 4.0 Client, Windows Installer
But .NET 4.0 Client and Windows Installer make my project most biggest. So I would like to know if there is a way to make my setup file contain just the required libraries, i.e. the setup program won't install .NET on the target host?
No I don't think so - without the .net framework your are screwed here.
When you do this the .NET framework is not included in the MSI package and doesn't make the file any bigger. It is only a pre-requisite for the successful installation. So when you run the setup on the client computer if it already has the framework installed it won't do anything. If it doesn't it will ask the client to download it. You could of course remove this prerequisite but because your application is built with .NET if the client computer doesn't have the correct version installed your application won't run. So I would suggest you to leave this prerequisite in your setup project.
I've read every stackoverflow article on MSI installations, but I cannot find the solution to my problem:
I have a VS2010 solution with 5 projects, all targeting .NET 2.0:
DLL A, no project references
DLL B, references DLL
A Windows Forms App, references DLL B
Windows Service, references DLL B
Setup Project
DLL A and DLL B are set up as to be installed to the GAC at install time. I'd like to start the service once the installation has finished, but according to what I've read, the assemblies are not registered until the very last step. I have proven this by attempting to start the service on the AfterInstall event of my ServiceInstaller class and I get the following error:
Error 1001. Could not load file or
assembly 'DLL_B', version 1.0.0.1,
Culture=neutral,
PublicKeyToken=5e297270603814f4' or
one of its dependencies. The system
could not find the file specified.
But of course, once installation is complete, I can manually start the service and it runs fine. Also, in Windows XP, I can usually have the service started at application launch (I have a checkbox with Launch Application as the last step of the installer). But in Windows 7, permissions are no longer elevated at that time and starting the service throws an error.
How can I achieve the installation and starting of the service without forcing a reboot? To quote my client: "Its 2011 now and that shouldn't be necessary.", and I agree whole-heartedly.
Thanks ahead of time.
This is a well-known issue with the GAC. One option might be to use two separate installers and daisy-chain them. This is the way we have chosen to get around the problem of deploying Microsoft VC runtimes on Vista and later. If you use the merge modules, any services that depend on them won't start. So in effect you put your GAC-destined components in a pre-installer whose transaction will be completed and committed before you run a second install that installs and starts the services that depend on them. Ugly, I know, but better than a reboot.
A solution is to use a custom action which runs after InstallFinalize in InstallExecuteSequence table. This custom action should use the msidbCustomActionTypeAsync and msidbCustomActionTypeContinue flags so it runs in a separate process after the installation is finished.
This cannot be done with a Visual Studio setup project, but there are a lot of alternatives: Orca, WiX, a commercial setup authoring tool etc.
I worked around this issues slightly differently: I installed my assemblies not only in GAC, but also into the Application Folder. My GAC-bound assemblies were already found as dependencies, so I put those into GAC (and those indeed end up there only after all custom steps executed). I also added same assemblies as primary output to the Application Folder, where my InstallHelper DLL with custom actions also resides. This way during installation local copy from Application Folder is used.