I had an app A for which I created an installer A1. This has been in use for many months.
We now realized that AI used to package some files - d1,d2,d3 which are not needed.
Therefore we removed them from our project and created an installer A2 which does not package the above mentioned unwanted files. (atleast thats what we expect)
Things are ok when I use this installer the usual way...but when I use this for a silent install, I get the following error:
Error 1334. The file d1 cannot be installed because the file cannot be found in cabinet file 'myMedia1.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
I googled this and saw that people usually encounter this whn u release a patch or some installer release where some files are removed or moved around.
Apparently, msiexec tries to reference some cached version of these variables and since it still looks for the missing files in the new installer, install fails.
Is there a way to tackle this? - like some way to have msiexec use just the .msi file I provide in the input rather some cached version.
Thanks...
It sounds like you could receive this error if you haven't updated the PackageCode, ProductCode, or UpgradeCode for your A2 installer. If A1 is installed, and then A2 runs with the same PackageCode, ProductCode, and UpgradeCode the system thinks you are running the A1 installer again and will look for the cached A1 msi under C:\windows\installer.
For anyone else like me that is experiencing the same problem (Error 1334) when building a Setup project and didn't find any explanations or solutions, here's a thread that solved my problem:
https://www.itninja.com/question/1334-error-tried-just-about-everything-i-can-think-of-anyone-know-of-some-obscure-causes
Basically, the solution to the problem is to “touch” all the files referenced in the Setup project (that is, all the dependencies - DLLs and all else). You can find the list and path of all the files in the build output, on lines like these:
2> Copying file from "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Threading.dll" to "C:\Path\To\Your\Project\bin\Debug\System.Threading.dll".
To “touch” the files, you may use this technique or you may use some third-party file manager like Total Commander. You'll just need to run as administrator / accept UAC warning, because some files are in system folders.
EDIT: in my case, the problem with the Setup project began after updating some NuGet packages used by the main project.
P.S.: although I'm not using WiX, but Microsoft Visual Studio Installer Projects, the symptom was the same, so I hope this answer will be helpful for someone.
Related
I've tried for many hours to find the solution for my problem and couln't find it even here.
So I have that application.exe that I am writing the Wix Toolset installer for it. Unfortunately I have no access to the source code but I hope I can do my task without it.
The problem is that it runs correctly with vc_redist.x64 installed on the end user's machine, but not without it.
What I've tried:
I was trying to run it without those runtimes and got into "couldn't find vcruntime140.dll error"
So I pasted it in the app's folder and tried to move on with dll's and the next error occured as shown in picture:
the application was unable to start correctly (0xc000007b). Click OK to close the application
I've read those runtimes after installation go into eg. "C://Windows/System32"
so I tried to go to that location and
dir > before.txt
and
dir > after.txt
after installing the vc++ runtime.
and copy pasted the files that occured only after the installation.
I tried to use gumpbin.exe from Visual Studio that gave given output:
found some dependencies
and the Dependency Walker gave me kind of similar output.
Dependency Walker output the same libs as direct ones, but also gave imo about hundreds of indirect ones. So I thought copy/pasting all of them is a really hard job without software to help.
I was also thinking about forcing vc_redist.x64.exe to extract files to folder given by me so I could use them for my purpose and the only parameter that looked fine was /layout but it only copied the whole .exe to another folder. Didn't extract it.
My questions is:
is there an easy way of obtaining the vc_redist.x64 libraries so I could author only the needed ones in my installer?
Any help will be appreciated. Thanks in advance!
Edit:
My goal is to secure newbie end users from being unable to run the application when they accidentally uninstall the VC runtime, therefore having vc_redist.exe as prerequisite in bootstrapper is unfortunetely not the case
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
So here's the scenario: I have several wix projects that the exact same extra msbuild targets and tasks to automate some very tedious tasks: things like building a help file and authenticode signing the msi and output files using signtool.exe.
Having gotten tired of copying changes to these scripts into 5 different repositories every time I made a fix. So I got clever and I turned them into nuget packages with a .targets file in the build folder. A simple nuget restore turns a laundry list of packages into targets files.
The problem
Wix v3 doesn't like packages. It doesn't support package references so packages.config looks like the thing. Except that visual studio doesn't like packages.config. It will happily restore the packages (into the folder I specified with a nuget.config) but none of the .targets files are automatically imported.
Easy enough to fix: I just added an import statement into my wixproj file. Except that visual studio doesn't automatically re-evaluate the wixproj after running the restore operation. We can work with this, but it is really annoying to have to build, unload the project, reload the project, and rebuild any time the packages change.
So I tried to fix it
I crawled through the log output of a standard C# project build and discovered the Nuget.Targets file, which can be imported into a project to provide pack and restore targets. It also let me convert to packagereferences, which are somewhat more convenient and less messy than packages.config, but I still had to manually add the import statement for the nuget.g.targets and nuget.g.props files that were produced by the restore target.
And, since I had to manually import those files, I'm right back to the build, unload, reload, rebuild workflow.
Attempt number 2
I discovered through intense internet searching that msbuild recently added a /restore flag to their command line utility specifically to force a project re-evaluation after restoring packages. This works on the command line, but visual studio seems to be clueless. (Maybe because of something that wix v3 does behind the scenes in the Visual Studio template?) In any case, they mentioned in the issue notes that they are essentially using an msbuild task with new global properties to force a re-evaluation. So I attempted to add such a step to the pre-build event of my wixproj, but no sauce.
The question
How do I tell visual studio to re-evaluate this wixproj after running restore? Is there some sort of property or item group I need to add to the wixproj? Is there some kind of target I can insert into the build process?
Update 1:
Found a project property that looked promising: UseHostCompilerIfAvailable, but it didn't work. Still got the same problem.
I migrated my WIX project from V2 to V4 and then changed the namespace in the .WXS files
I replaced the below namespace
<Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
with
<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
Once the changes have been made when i run the build installer i am getting the below error:
error CNDL0199 : The Wix element has an incorrect namespace of
'http://schemas.microsoft.com/wix/2003/01/wi'. Please make the Wix element
look like the following: <Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
E:\Code\EMR\Wix\src\EMR_Registry_entries.wx
I replaced the new namespace but it is not reflecting. Once i run the build installer it is setting with the old namespace. I tried multiple times but it is always setting the old namespace.
Please help me to resolve the issue.
UPDATE: Question that came up from a second read of your question.
Source Control: "Once I run the build installer it is setting with the old namespace." - are you sure the build process doesn't
auto-magically 1) check the WiX source out of your source control system? Or 2) maybe it is doing some XML manipulation via the automation script?
WiX Version: Are you sure you are compiling with WiX 4? Maybe you are compiling with WiX 2 or WiX 3 unintentionally? Try hard coding the full path to the WiX binary in your build system - if you have one. Please see this (Sean is a WiX developer): Migrate Wix Project to version 4.0. Frankly I am not sure how well WiX handles multiple-version installations on the same box combined with migrated sources (identically named binaries of different versions - WiX 2, 3, 4 - globally applicable via the PATH variable? Not sure).
Visual Studio / Cmd.exe?: Are you compiling with Visual Studio or via the command line? (I am not quite sure reading your question). Maybe try via the command line (towards bottom) if you are using Visual Studio - or vice versa. Make sure you use the correct WiX binaries (in other words WiX 4).
Linked Files?: I don't have any WiX 2 sources to migrate, but I am wondering if you have several source files that are interconnected. Was that even possible in WiX 2? I can't remember. In either case, I would make sure you have updated all WiX source files that are pulled in during the build process. Please read the log carefully. Maybe try to compile them with Candle.exe directly using the command line (cmd.exe instead of Visual Studio) to see if the file compiles OK.
Source Files?: If it still does not work, please put the source file online so we can have a peek. Github.com for example. A quick look at the source (the real McCoy) goes a long way sometimes - and sometimes it doesn't help at all. Maybe give it a go. Redacted sources are just fine - encouraged even. Please pay close attention to sensitive data: How do I avoid distributing sensitive information in my MSI by accident? (and this also goes for published source files - obviously - not just the compiled MSI and its helper files - such as silent installation template batch files).
In summary: That became a lot of babble. Maybe first try to compile the migrated WiX source with the right WiX 4 binaries to
determine if that works or not. Then work backwards to figure out what
happens during the build process.
I am creating an install package using InstallShield Pro X. The upgrade works properly. However, the product manager wants the upgrade to replace all files on an upgrade even if the create date != modify date on the file.
I see that to do this I need to set REINSTALLMODE=vamus rather than vomus. However, I don't see how to tell InstallShield that I want it to use that setting. By default setup.exe always passes vomus to windows installer.
There is a property in the InstallShield project named ReinstallModeText that I changed from omus to amus but that seemed to have no effect.
So, how what do I set in the install project so that when setup.exe detects to run an upgrade it sends REINSTALLMODE=vamus? Thanks.
Update: Tried adding the following to the MSI Command Line value in the Release section:
REINSTALLMODE=vamus
This did not work. Setup.exe didn't set REINSTALL=ALL on the command line what I did this. I added that to the MSI Command line and the upgrade worked as expected. But, not the problem is if it is a NEW install those properties are still being set and the installer fails.
In investigating this further and testing more options I think the best answer is to modify the product code in addition to the product version and author it as a major upgrade which removes the previous version first and then installs the new files.
The main problem with this is that it takes alot longer for the installer to run. I also think that you can not issue this as a patch, but I could be wrong on that count.
Don't set the REINSTALLMODE to amus or vamus (force overwrite files). These settings apply to all components in the MSI, and could hence in theory downgrade system files or at least shared files - this typically involves files included via merge modules. It is normally safe to set REINSTALLMODE to emus (replace files with lower or equal version number). Even this can trigger a file replacement error if you try to overwrite a system protected file on newer versions of Windows featuring Windows Resource Protection (wikipedia) (Windows Server 2008 and Vista onwards). On older Windows versions the file would likely be overwritten and then restored in its right version from the dllcache via the Windows File Protection feature provided that feature had a good day. There was (and is) an associated tool for system file checking: System File Checker.
If you have issues with files that should be replaced even if they have been edited, you can use the RemoveFile table to schedule the file for removal during install (and then it will be reinstalled).
The real solution is to consider the installation folder in %ProgramFiles% as read only, and not have the application save ANY settings or change any files. All config files should go to the user profile or the alluser profile and the application EXE file should be responsible for the copy to the profile locations.
See my answer here.
I don't have IS X handy, but in later versions of InstallShield you would go to "Releases", highlight your release, go to the "Setup.exe" section and there's a field called "MSI Command Line Arguments". There you would indicate any command-line arguments that you want Setup.exe to pass to Windows Installer. E.g. REINSTALLMODE=vamus
You mentioned you used ReinstallModeText with "amus". Have you tried ReinstallModeText equal to "vamus". The "v" causes the installer to run off the source package, not the cached package, and that may be your problem.