Some people are having trouble installing my AIR app. Most are installing it fine.
Some of the people having trouble are installing it for the first time, others as an update.
I've tried two versions of the installer - one with a migrated cert, the other without migration.
Also, I've gone through these steps with them:
check that your computer's system clock is correct. Correct the date and time if it not current.
make sure you have the latest updates for your machine eg latest Windows updates for Windows machines
install the latest version of the Adobe AIR runtime (download from http://get.adobe.com/air)
uninstall my app if it is already installed
make sure the application folder does not exist (in, for example, c:\Program Files or c:\Program Files (x86)). If it does exist, delete it.
empty the Trash (Mac OS) or Recycle Bin (Windows)
try installing my app again
I'm wondering if there are any other steps that you are aware of to test?
Cheers
Related
My company uses Wix Toolset to create an installation package for one of our applications. As part of an upgrade, we changed the names of some executables and dlls.
When I attempt to install the new version on a machine with the old version (something that had worked flawlessly beforehand), everything works fine until the very end of the installation, when all of the files in the installation directory are unceremoniously deleted.
What setting is causing this? If this has happened to you, what dumb thing did you do to cause it and what restored balance to the world?
Thanks.
I currently use WIX (latest version) to package and bootstrap my Windows Form application.
I'm having an issue where my clients (using SOE workstations in a secure, enterprise environment) don't seem to have access to the MSI package cache directory when using the installer to perform a major upgrade. The installer completes successfully, but when they double click the desktop shortcut to launch the software, it displays the following two wix-generated dialogs:
I then get a 'Fatal error during installation.' message and the software won't open until it is completely uninstalled and reinstalled.
There are no issues at all with a fresh install. The current workaround is to manually uninstall old versions before installing the latest version.
I'm having trouble replicating this problem in my dev/test environments, and requesting my client to change their SOE configuration is out of the question.
Any advice would be most appreciated. I'm hoping there is a way to redirect the cache location to a UserData folder, or an entirely different approach to handling upgrades.
Thanks in advance for any guidance.
I'm using Visual Studio 2010 to build a MSI consisting of several DLL files set to register using vsdrpCOMSelfReg. There are also several Windows services that are installed using custom actions. My target machine is running Windows 32bit embedded standard.
My previous development box ran Windows 7 64 bit and I could build and install this MSI with no problem. I recently changed over to Windows 8 Pro, and when I build the MSI using the exact same code base I get "failed to register" errors on my DLLs, which then causes the services to fail installing.
I have a "Privileged" launch condition in the MSI that passes for both versions, so it looks like the required permissions are there.
If I set the DLL files to "vsdrpCOM" I can successfully register after the fact using regsvr32, but my services can't install because they rely on those DLLs being registered to complete their own installation.
What am I missing? What changed with DLL registry beween Windows 7 and Windows 8?
The usual cause for this is missing dependencies. ComSelfReg requires your Dlls to load and run during the install. If you have included the VC++ runtime support as merge modules and they install in WinSxS then they are not available until after your selfreg code needs to run. The symptoms are exactly those you'd get when the VC++ runtime is being installed from merge modules and do not already exist on the system - failure during the install and success with regsvr32 after the install.
In general you should look at using a tool that doesn't require code to install services. All the major install tools populate the ServiceInstall and ServiceControl tables in the MSI file because MSI will install services just fine, but VS setups don't use them for some reason.
The problem was in the dependencies automatically pulled in when I added the DLL Project Outputs. One of the detected dependencies was IPHLPAPI.DLL, pulled from C:\Windows\System32. This DLL was then copied into the application directory. In my install of Windows 8 Pro, IPHLPAPI.DLL is version 6.2.9200.16420. In Windows 7, this file is version 6.1.7600.16385.
I'm guessing my assemblies were referencing the Windows 8 version since that was in the local directory, and this caused registration and/or runtime errors. I excluded IPHLPAPI.DLL from the installer and everything is now running correctly, referencing the file in System32.
This is Edited from the OP. This is a VB .NET 4.0 WinForms application. There is a mysql datasource involved with this project. The target CPU is set to any. Problem: When running this application on any computer that has VS 2010 installed along with the mysql connector it runs flawlessly. When installing on a virgin system(ie. No developer environment installed) but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately. So to fix the issue I install the mysql connector MSI. This immediately fixes the issue on the client system and it runs. The problems is that as you can see below from my Installer setup that the 2 needed DLL files for MYSQL are actually included in the installation package so should not need to be installed separately. So Why is it that using that installer from the images do I need to install the mysql connector? Any Ideas? Below is a screen shot of the References the program uses and from what I believe I do not need to deploy any of those DLL files with my application other than the 2 MYSQL DLL files. So why is this failing?? Below are images showing the project references as well as the Installer Files that are being installed in the applicaiton folder. As shown in the image the 2 mysql dll files are to be put in the application folder. There is also a screen shot showing each dll's properties for in application folder.
You answered your own question.
but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately.
You don't need to install the connector msi package, but you do need to include the two DLL files in the application's directory. Anytime you have some dependency, you need to deploy it with your application.
Edit solution quoted from my comment:
From your update it sounds like you have a version mismatch on the
assemblies, and the references are set to Specific Version = True.
Check the version number of the assemblies on your developer machine
in the output directory, and check the version you are installing on
the client system. (You can just hover over the DLL to read the
version on the ToolTip). You can try to set Specific Version to false
by right clicking your reference and selecting properties, or simply
ensure you deploy the same version of assemblies. Your program is
looking for the versions its compiled against
I have created an shareware application using vb.net visual studio 2008 for windows desktop, and packaged it using innosetup 5.3.8. The problem is when i have installed the application in C:\Program Files\Application and it runs successfully(use trial period of the application), Im also able to install the application once again freshly with the same setup by installing in different directory.eg C:\Program Files\Application new . The application in C:\Program Files\Application new does not have any settings of the already installed one.
Where do i went wrong . Do i need to take care of this in my application(vb.net) or innosetup. How to take care of the already installed path in innosetup or carry the settings of already installed application to newly installed path by upgrading the older one.
I dont want to write any thing in registry because the application does not want any administrative permission requirements.If i install the application in same path it gets updated with the older settings being taken over to this new one and it works fine.
Windows applications normally save their settings in the registry under HKEY_CURRENT_USER\Software\YourCompany\YourApp or as files under %APPDATA%\YourCompany\YourApp. Both locations can be written to without admin privileges, and both locations are user-specific. That is, if two users use the same computer, both can use your application with their own settings without affecting the other user.
You should never save any settings under c:\Program Files. Writing to the Program Files folder requires admin privileges. If your application does not have a manifest then writing to Program Files may appear to work. What is really happening is that the files you're writing to the Program Files folder are rerouted to the VirtualStore. Unless the system administrator has disabled the VirtualStore. Then your application will fail.
If you want your application to be robust, it should only save settings to HKEY_CURRENT_USER\Software\YourCompany\YourApp and/or %APPDATA%\YourCompany\YourApp. Your application should use its default setting if no previously saved settings can be found in these locations.