I used WiX to build an installer (MSI) for an application, which works fine, except for this unreasonable amount of "applications that are using files that need to be updated by this setup":
This happens for some users some times, and I don't quite understand why this happens, and how to fix it.
I don't see a reason that the installation process of my application would conflict with all of these applications, and I'm not sure how to investigate it further.
My application is a standalone desktop application - not any add-on or something that interacts or depends on any of the applications listed.
The steps my installation process does:
Check that .Net framework 4.0 CP is available (exit if not).
Install the application under Program Files[Company][Product] (including my exe, my DLL, 2 third party DLL's that I bundle)
Install MS Visual C++ Runtime Redist 14.0 if needed
Add Start menu items for the application (launch & uninstall shortcuts)
Custom action for creating a scheduled task that starts my application on user logon as admin (the application runs in the tray as admin).
Custom action for starting the application after setup finishes (if checkbox is checked in last dialog).
Any advice on how to fix this, or at least investigate what causes this, will be appreciated :-)
Does it happen only when you run the installer and your desktop application is already running?
To investigate this further, best place to look at is your log file. The log file will have the details about the file which is being held by the other process, something like:
Info 1603. The file C:\...\abc.exe is being held in use by the following process: Name: xyz, Id: 19010, Window Title: 'xyz'. Close that application and retry.
Info 1603. The file C:\...\abc.dll is being held in use by the following process: Name: xyz123, Id: 9243, Window Title: 'xyz123'. Close that application and retry.
Once you determine the actual file being used by those other process, then it will help you figure out what the root cause is. Basically the INSTALLVALIDATE windows installer action determines if one or more files to be overwritten or removed are currently in use by an active process. An entry is added to an internal FilesInUse table if any file is overwritten or removed while it is open for execution or modification by any process during File costing. The FilesInUse table contains columns for the name and full path of the file. When the InstallValidate action executes, the installer queries the FilesInUse table for entries and determines the name of the process using the file. The InstallValidate action adds one record to the ListBox user interface table for each unique process identified by this query.
Related
We have an application which shows up as an Excel ribbon.
We have installed the application in our test environment through administrator login. We are trying to make a per machine installation.(Please note that in production environment, the installation will be through system account).
When we login as user to the same PC, we don't see the excel addin in the Excel ribbons. We don't see the addins anywhere in the list of addins as well.
We have tried using Active setup,Userstat,setting the values of properties as ALLUSERS=1, RegisterForAllUsers= True, InstallScope= perMachine, InstallAllUsers = Everyone, RunActionsAsInvoker = True . Also the privileges has been changed from user to admin in all the cutom actions and in manifest file as well. All these changes where made as we understood that the application used to package is Addin express and so the msi creation with privileges as admin is possible.
Unfortunately none of these changes seems to help us.
What we would need is an msi which we can install on per machine basis.
From the situation mentioned in the question, we had tried a lot of options and finally following approach works for us:-
Create a package which would place a powershell shortcut in the startup folder.
The shortcut would in turn call or execute a powershell script.
The powershell script would
1. check if the registry key for that particular add-in is available in HKCU.
We had our registry key as "HKCU\Software\Manufacturer Name\Product Name" which in turn had a string value "Installed".
If the registry key is not available for the user, then install the package with tranform.
3.If the registry is already available, then script doesn't make any change.
The package is installed as an Admin and once the user logs in, then automatically the cmd file is executed and the add-in is installed.
Since this was the first version of the product, we didn't have to handle version compatibility.
I'm using freepascal. So after I run my code compiler creates an exe file that should create few text files. However after it creates an exe file it says "Program c:\fpc\2.6.4\bin\i386-win32\maxmin.exe exited with exitcode = 2". No text files are created. If I later run maxmin.exe manually - it works fine.
UAC - disabled and EnableLUA = 0. But I still pretty sure - it is windows 8.1 rights issue problem.
Some possibilities, in descending order of likeliness:
Note that exitcode 2 usually indicates a file not found error.
Working directory. While manually executing you set the working directory by CDing with the shell, and when indirectly executing the program's assumptions about a working directory are not satisfied.
Sometimes locks linger on Windows for a short while. Usually not noticeable in the manual execution time frames, but when programmatically executing programs in quick succession it might happen.
If you have the feeling that the EXE doesn't run at all, it might be an security software issue. After the binary is generated, the antivirus kicks in and wants to scan, locking the binary for a few seconds.
I'm using WiX 3.5. Recently, the following WiX error started occurring frequently on the build server:
light.exe (,): error LGHT0301: Failed to open the database. During validation, this most commonly happens when attempting to open a database using an unsupported code page or a file that is not a valid Windows Installer database. Please use a different code page in Module/#Codepage, Package/#SummaryCodepage, Product/#Codepage, or WixLocalization/#Codepage; or make sure you provide the path to a valid Windows Installer database.
Which "database" does the error refer to? (None of the WiX source files have changed in a long time, so I doubt it's a code page problem.)
Other people have reported that this error may be caused by Trend Micro Office Scan, which is indeed installed on the build server. I asked the system administrator to exclude the build directories from the scan, but this error still occurs. How can I determine whether the virus scanner is the culprit? (The error doesn't always occur, so if I disable the virus scanner and the next build succeeds, I still don't know whether the error has gone away permanently.)
The "Disable the ICE validation" worked for me - just a setting through Visual Studio 2012 in the .Setup.
After studying the WiX source code and running Process Monitor, I found that excluding the build directories from the virus scan is insufficient.
Explanation: When light.exe runs, it creates the target MSI file in a temporary directory. (This file is the database that the LGHT0301 error message refers to.) After light.exe closes the MSI file, ntrtscan.exe opens the MSI file for read access and read-only sharing. Later, in the database validation step, light.exe tries to reopen the MSI file for read/write access, and a sharing violation occurs.
Solution: Exclude the temporary directory from the real-time virus scan. On Windows Server 2008, for example, this directory is C:\Users\«username»\AppData\Local\Temp.
This is a common problem with build processes and antivirus. The scanner will detect the new MSI package and try to scan it. Meanwhile the build process also tries to validate it by running the Internal Consistency Evaluators (ICE) suite and you get a failure because the database has a mutex on it.
You should just remove the virus scan from your build output folders. Alternatively decouple the validation from the Light command so that the antivirus scan relinquishes the MSI handle before you run the ICE validation.
I had the same problem which was actually really related to codepages and language settings of my system.
Adding English input language in Windows' regional settings solved the problem on my German Windows installation.
The real cause was Trend Micro real time scanning!
(The following is only for historical reference)
I followed #Michael Liu answer and solved the problem
I had the same problem.
I am not referring to Codepage (or SummaryCodepage) in any of those tags, or in fact anywhere in the WXS. Putting Codepage="1252" didn't change anything.
Finally, I tried adding
encoding="utf-8"
to the XML tag which previously only had a version='1.0' attribute. This fixed the problem, as described in "Failed to open the database" error. - SOLVED
It was also the antivirus program for me.
An easy way to check if the problem is related to the anti-virus program is to disable the ICE validation in the WiX project setting (using version 3.7). This worked for me, and is a permanent setting now, since in our company you can't change the setting of the antivirus software.
This is the most common error I found while using WiX. The easiest solution for this is go to Properties of your project → Tool Settings → (Check) Suppress ICE Validation.
I'm using c#, .net 4, WIX 3.5, Windows Vista.
I have made my application compatible with RestartManager by p/invoking the RegisterApplicationRestart method and by handling the WM_QUERYENDSESSION and WM_ENDSESSION window messages (I return new IntPtr(1);).
If I try to update my application manually, then everything works as it should:
Launch application;
Launch msi file containing new app version;
During the installation/update, I'm prompted to close the running application;
Upon continuing the running app is closed, install completes, and the app is restarted;
If I try to update my application from the application itself, then I run into problems:
1) Launch application;
2) Download the new msi file;
3) Launch msi file with:
using (System.Diagnostics.Process p = new System.Diagnostics.Process())
{
p.StartInfo.UseShellExecute = false;
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i \"" + downloadPath + "\" /passive";
p.StartInfo.UserName = "Administrator";
p.StartInfo.Password = securePassword;
p.Start();
}
4) Because I'm using passive mode, the application is closed automatically;
5) After the installation, my application is not restarted and under Event Viewer I have an
Event 10007 - Application or service 'MyApp' could not be restarted.
I have tried:
Not to use passive mode for msiexec;
Launch msiexec via cmd.exe (cmd.exe /C "msiexec /i ....") - in the hopes that launching msiexec from another process would solve the problem;
Wait for 60+ seconds before launching the msi update (shouldn't be relevant in my scenario, but MSDN documentation has something about it...)
But none of the above has worked (always the same result).
Having to launch the setup with elevated permissions might have something to do with the issue, because during the manual update I get a warning in the Event Viewer - Application MyApp (pid 3220) cannot be restarted - Application SID does not match Conductor SID.
Despite this, restarting the app still works. Googleing the warning yields no good/specific results, only that this warning is probably caused by running the msi in an elevated prompt.
How do I fix (or workaround) this issue, so that I can update my application from the application itself and restart my application afterwards?
Edit - extra testing:
There doesn't seem to be a need to respond to WM_QUERYENDSESSION and WM_ENDSESSION messages, because application restart during a manual upgrade works without them, so we can rule them out;
If I don't provide administrator credentials to the application initiated upgrade and instead I type them in during the upgrade, then app restarting works;
If I run an elevated command prompt and initiate an application upgrade from there (manually), then app restarting still works;
In order for application upgrade to work at all under Standard user accounts (so far I tested under an Administrator account with UAC), then I also have to set p.StartInfo.LoadUserProfile = true;. Otherwise nothing happens. (application restart still doesn't work though);
I tried all other process StartInfo parameters that I could set - WorkingDirectory, Redirect, Verb
(= "runas") - no change in results;
I installed Vista SP2 onto the virtual machine that I have been testing on (so far ran SP1), but no change;
I performed an "automatic" application upgrade with verbose logging. In the end there was an error message - RESTART MANAGER: Failed while restarting applications. Error: 352. That error code is very generic (http://msdn.microsoft.com/cs-cz/library/aa373665), inorder to get more detailed info I would have to write my own installer that would call RmGetList after the error, then I might get more details (this though is something I'm not willing to do);
Edit 2 - msi log file:
http://mommi.planet.ee/muu/log.txt
Assuming that the manual process indeed works without any problem it seems that your need for Administrator privileges in combination with the "updating itself" leads to these problems. I see the following options:
create a batch file to execute the update
When you want to update call this batch file (with elevated privileges), make the app close itself... the batch file should wait some seconds, then check whether the app is still running (and close it in case) and then run the commandline you need to run msiexec - don't restart the app from within msiexec but after a successfull run of msiexec from the batch file.
create a batch file which is always used to start the app
When the time comes to update you just end the app. Either the batch file check for an available update and applies it, starting the app after successfull update OR the app set some environment variable which is then accordingly processed by the rest of the batch file.
I have a ClickOnce application that about 120 customers are using. This week, I found out two customers declined an update in January and were stuck on an old version. I discovered this by deleting an ASP script the old versions used on our server. The customers that aren't updating get a 404 and call to ask why.
One customer clicked our install button again and got the latest version no problem. The other clicked our install button and gets an "Application validation did not succeed" error. The details of the error are SomeImage.gif "has a different computed hash than specified in manifest."
I don't want to deploy a new version because that usually results in phone calls asking, "did you add what I asked for yet?"
I figure I should be able to uninstall the application completely and resintall with the one problem user. Nope. The error persists. How can I remove whatever the Windows uninstall process leaves behind that would cause this error to persist?
Update:
I found the folder C:\Users\User\AppData\Local\Apps\2.0 on the customer's Windows Vista computer, and deleted it. We ran the installer again, and the error persisted after redownloading the application. I'm not 100% confident that this folder contained the whole program, though, but it is the only location on disk I could find that contained some resemblance of our application.
Track down mage.exe in the Visual Studio tools folder (C:\Program Files\Microsoft SDKS\Windows\v7.0A\bin). Copy it to the user's computer. Try this:
mage.exe -cc
This clears the ClickOnce applications. I would also delete the \apps\2.0 folder AFTER you do this -- this is the cache created and used by ClickOnce applications.
Then reboot the computer.
This may or may not help. My error messages weren't exactly as you describe, but I was eventually able to remove the final traces on my machine by going to:
HKEY_CLASSES_ROOT\Software\Microsoft\Windows\CurrentVersion\Deployment\SideBySide\2.0
I deleted all grandchild keys that bore names similar to my application. After that I was able to install and run the latest version.
This is on Windows 7 64 bit.
Try doing a "Clean Solution" and then doing another Build. If you publish without incrementing the version number I don't think existing installs will get an update message.
If you've already run the uninstall and it hasn't sorted it, try deleting the files in
C:\Documents and Settings\<userName>\Application Data\
You'll have to do some looking around to find your application, but it shouldn't be too hard.
In the past I've used the below code to avoid the users having to click the update button, this will install it without them even knowing.
Private Shared Function UpdatedApp(ByVal AppLog As Logger) As Boolean
Try
' Check to see that this program has been delpoyed
If Deployment.Application.ApplicationDeployment.IsNetworkDeployed Then
Dim CurrApp As System.Deployment.Application.ApplicationDeployment = System.Deployment.Application.ApplicationDeployment.CurrentDeployment
AppLog.WriteLine("Application Version : {0}", CurrApp.CurrentVersion)
AppLog.WriteLine("Checking for updates")
' If theres a update then Install it
If CurrApp.CheckForUpdate() Then
AppLog.WriteLine("An updated version is available. This update will now be applied.")
' Update the app to the current version
CurrApp.Update()
' Upgrade the settings (that is, the connection string).
My.Settings.Upgrade()
AppLog.WriteLine("Version {0} is now installed, the application will now restart", CurrApp.UpdatedVersion)
Return True
End If
Else
AppLog.WriteLine("Application version: *Dev Version*")
End If
Catch ex As Exception
AppLog.WriteLine("The application is unable to check for updates. The program will execute on a possibly outdated version. Error {0}", ex.ToString)
End Try
' Always return false unless the update has been applied (even if the update throws an error)
Return False
End Function
Have you attempted to rollback a version with the ClickOnce Application? You can do this when you got to the Programs and Features and then uninstall on your app.
This should then leave your App in a state where it would then request the latest update again.