I've created an MSI with Visual Studio 2010 using the Deployment Project template. It used to work, but now it has started acting up when installing over an earlier version - i.e. upgrading. I have set RemovePreviousVersions to true, but what is actually happening is that it removes "previous" version after installing the new version, effectively removing the new version also. In the MSI log file I see evidence of this. (Feel free to examine it)
Shouldn't normal installation procedure be to 1. uninstall previous version, 2. install new version? Anyone have any explanation of this?
I wasn't sure whether it was a match but you indicated it was. There's a bug in the VS2010 version of the Setup project feature that strikes when you moved the project from VS2008 to VS2010. Quoting from the KB article:
This problem occurs because a different hashing algorithm is used to create the GUIDs in Visual Studio 2010. When you install the MSI file that is created from the Visual Studio 2010 Setup project, the MSI file determines that the GUID has changed and removes the files and registry keys for the installation path based on the sequence of the project.
In this scenario, the files and registry keys for the installation path disappear unexpectedly.
There's a hotfix for it, follow the KB article link for the download and the usage instructions.
Related
WiX version 3.11 was installed but was uninstalled. WiX version 3.9 was then installed. During the time that 3.11 was present an empty WiX project was created. After 3.9 was installed the project was completed. At build time, an error is issued indicating that WiX version 3.11 must be installed.
We use WiX to generate installation packages. There are multiple versions of Visual Studio in use, 2013, 2017 and 2019, to accommodate various products. When WiX 3.11 was installed it was observed that VS 2013 stopped recognizing WiX projects. 3.11 was uninstalled and 3.9 re-installed. Previously existing WiX projects were again recognized and could be built by VS 2013 but the one WiX project that had been created in VS 2017 while 3.11 was in effect is still insisting on having 3.11 installed at build time. I've looked at the WiX project file and don't see why it is insisting on having 3.11 present. Does anyone know how to convince it to use the installed 3.9?
The WiX project loads in both VS 2013 and VS 2017. VS 2019 insists that the WiX project is an incompatible project type. I can live with that for now but when either VS 2013 or VS 2017 attempts to build the setup project the following error is issued:
The WiX Toolset v3.11 (or newer) build tools must be installed to build this project. To download the WiX Toolset, see http://wixtoolset.org/releases/
Other respondents suggested restarting VS and rebooting. This did not fix the question. I copied the the project to a safe location and then deleted the original from the solution, TFS and disk. A new WiX was created and the previous Product.wxs file's contents were copied into the newer project's. It built and thus the problem was addressed using the time honored tradition of burning it down to the waterline and starting all over. I would much have preferred to have discovered the offending data within the original project file that was telling the system to utilize 3.11 but that, obviously, didn't happen. Maybe next time.
I believe it has something to do with the fact that it was created under 3.11. This means the code for 3.11 is not compatible with 3.9. If this is the case, you might just want to delete the project (not the solution), and start over with the 3.9 framework.
It might also have something to do with the Extension that is added to Visual Studio.
.wixproj: I would open the Visual Studio project file: Name.wixproj and check the content. I see sections indicating checks for version in there, but I am not up to speed 100% with what each section mean and how to fix this specific issue. It is probably well known and solved on discussion forums somewhere.
File Diff: One ad-hoc solution would be to create a new project with WiX 3.9 and then use a file compare tool such as Beyond Compare to migrate whatever settings you actually need from the old project (WiX 3.11 format). You should be able to do this with the project open in Visual Studio. It will prompt to reload, do so and test build? Then iterate until you have a heartbeat with all settings migrated?
I've written a Visual Studio extension which installs using an MSI. The install puts a extension.vsixmanifest file in the right place, and the extension appears in the Extension Manager as expected:
The problem is, when I publish a new version on the Visual Studio Gallery, the Extension Manager does not report it. I add the new version by creating a new installer and editing the existing page. Each new installer has a new ProductCode, PackageCode and ProductVersion (I update the MSI setup project and the version number in the included extension.vsixmanifest), but the same UpgradeCode; an example 'upgrade' commit can be found on GitHub here.
The issue appears to be that when Visual Studio Extension Manager queries the extensions service for the latest version of my extension, it returns a blank string - the same result as if you query with an invalid extension identifier:
The two extensions successfully queried in the example are the NuGet client tools for VS2015 and the SQL Server Compact/SQLite Toolbox.
What am I missing?
OhhhhhhKAY. I've solved this, and it turned out to be a problem with the Visual Studio Gallery page editor.
When you add an extension, you're shown a VSIX ID box:
When you edit an extension (I'm using Chrome), that box has disappeared!
It's still in the DOM, but it's hidden from view. Because of this, I never entered my extension's VSIX ID into the form, it didn't have a value associated with it, and the extensions service therefore didn't return a version number for that ID. The Extension Manager uses the extensions service to find out the latest versions of installed extensions, so it wasn't reporting new versions of mine.
The VSIX ID box reappears if you deselect then reselect one of the extension's supported Visual Studio versions, so I've been able to assign the ID that way. The service now returns a version number, and the Extension Manager therefore shows available updates:
Probably you may need to raise ProductVersion as well and mind correct version conditions in Upgrade Table in installer project. If this will not help try investigating this issue installing with full verbose log (msiexec /i installer.msi /l*v logfile.log) this may give some clues. The worst case you may want to add an entry to RemoveFiles table to delete this file (during install before deploying your file) but that sounds nasty and i would prefer to avoid it.
I don't think this is a problem with your installer configuration, assuming your installer does, in fact, upgrade your product. If I understand your question correctly, this is an issue with Extension Manager.
Have you tried removing the trailing .0 from your new version string? There might be an poor/unexpected comparison result when comparing a 3-dot version to a 4-dot version.
You could also try doing a more extreme version number change (upping the major version) to see if Extension Manager picks that up.
I had an install issue with the NuGet package manager extension. I am now trying to remove it, but each time I do the remove, I come back to VS2013 PRO and it is still there (win7 sp1 box).
Is there a different way to remove it (I am getting errors whenever I try to open a project).
I ended up calling Microsoft support, and we spent about 45 minutes searching the registry for the particular version of NuGet (there was an old version installed that was not properly removed, keeping the new one from being installed).
We had to search by version id.
VS2013 does not only put things in:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions (with a random character folder name)
But also in %appdata%\Microsoft Visual Studio 12.0\Common7\IDE\Extensions as well as other places. So we had a lot of searching to do, but once we found it and removed the folder and all the old Nuget references from the registry, it was possible to continue and install the new NUGET Package Manager.
Today I found things were corrupt, (probably registry) but a REPAIR (From the install) was able to fix the problems
I have an legacy installation from a DotNet 1.1 application (with Visual Studio 2003) that will not deploy the msflxgrd.ocx file on the FIRST installation on Windows 7. If I uninstall the MSI and then run the same MSI again, (and future installations on the same laptop), the msflxgrd.ocx file deploys. At first I suspected that it was a regsvr32 issue, but since there is no file to register, it seems to be more of a deployment issue. I have administrative rights on the machines.
I have links to the MSI logs here:
Is anyone able to help?
Thanks!
My previous answer was to explain what was going wrong. This answer will be how to fix it.
InstallShield distributes a Merge Module for this control that contains version 6.0.84.18. However, it seems that this merge module is old and doesn't include a security update that was released by Microsoft a few years back. See the thread:
Updated Merge Modules for MS08-070 Security Bulletin
In the thread Mike Marino tried to get updated merge modules from Microsoft but was told:
Microsoft will not be providing Merge Modules for these. They
recommended that users either build their own MSMs or include these
files in their own MSIs.
So here is what I would do. Make sure the msflxgrd.dll is the latest version from MS08-070 (6.1.98.14) or newer. Author it into your installer in the SystemFolder directory. Mark it as Permanenet = true. Set the Register attribute to vsdraCOM and set the SharedLegacyFile = true.
Rebuild your installer and test your upgrade scenario again. You should be good to go.
From what I see in Log 1, the machine is not as clean as you think. FindRelatedProducts is finding a previous installation of your product and telling RemoveExistingProducts to uninstall it before installing your new version.
I've seen situations when the component rules are violated that MSI thinks a file doesn't need to be installed but the file then gets uninstalled by the removal of the product being upgraded and the file ends up not being installed. By uninstalling and reinstalling you break that up into two steps so that when the second install evaluates the need for the file it comes back as yes and gets installed.
The fact that this is an OCX COM server is just a coincidence and not really relevant to the real problem.
I'd need the MSI already installed and the MSI upgrading to give you specific remedys.
Action start 14:55:44: FindRelatedProducts.
MSI (s) (A0:18) [14:55:44:119]: PROPERTY CHANGE: Adding PREVIOUSVERSIONSINSTALLED property. Its value is '{08D8BF6E-E399-4B8A-8B8D-7DFF68F81131}'.
MSI (s) (A0:18) [14:55:44:119]: Skipping action: ERRCA_CANCELNEWERVERSION (condition is false)
MSI (s) (A0:18) [14:55:44:119]: Doing action: VSDCA_VsdLaunchConditions
Action ended 14:55:44: FindRelatedProducts. Return value 1.
I have a web setup project built using VS2008. I've converted my solution to VS2010 and now when I build my new installer and run the install from the MSI it installs fine, then at the last step, removes all the files it's just installed.
I have RemovePreviousVersions set to true. If I turn this off the files remain in place (but I get multiple instances in the Programs and Features in the control panel).
If I run the install again, the files reappear. From then on, the files always remain, even when installing another version. So, the problem seems to be with running an installer built using VS2008 and then running the same installer built by VS2010. The upgrade GUIDs on each installer are the same.
What is the cause and how can I fix this?
I haven't tried porting a setup from VS2008 to 2010, but having the same upgrade code for different build versions will cause problems; simple explanation is the msiexec installer fails when it tries to remove the old components because the older components have the same upgrade version as the newer components being installed. There is a VS project setting where you can automatically generate a new upgrade code each time you rebuild your .msi; I generally select this and saves a lot of these versioning headaches.
Uninstall all copies of your app using
add/remove programs
Delete the contents of your %TEMP% folder ( to
get rid of any "old" (VS2008) copies
of your .msi)
Update the GUID for the VS2010 version (I think you do this by right clicking on the
GUID in the properties window and clicking "genereate new GUID")
rebuild the project and try again!
I just encountered this error. Had the exact problem when upgrading. I tried the solution at:
https://connect.microsoft.com/VisualStudio/feedback/details/559575
I edited my MSI-file in Orca resequenced RemoveExistingProducts right after InstallInitialize (sequence number 1501). This was found in the InstallExecuteSequence table. This was originally sequence number 6550.
That solved my problem.
What I've discovered is that changing the UpgradeCode will prevent the files from being removed, however it's then treated as a separate installed program - i.e. in the control panel (Programs and Features) my program appears twice. Logically, I think, this is because it's not the same program.
My only option seems to be to programmatically uninstall the old version in the installer of the new version by writing a custom action.
I've submitted a bug to Microsoft Connect and they've confirmed it's reproducible.