I made a laucher application in c++ that use direct 2d and 3d. Now i making a installer for this. I followed microsoft docs and i made it but there is a issue.
I use 'Microsoft Visual Studio Installer Projects' extension to make that.
The issue is if i already installed my launcher with a previous installer msi file, if i rebuilt a new installer msi and try to run it it show me this error
This is the microft docs i followed to make this: https://learn.microsoft.com/en-us/cpp/ide/walkthrough-deploying-your-program-cpp?view=msvc-160
In the future maybe i need make a update for my laucher. It isn't good idea everytime need go to control panel, search and delete the previous application and install the new one manually.
Anyone know how can i make it automatic remove old version and install new one? Maybe there is a better way to create a installer?
Major Upgrade: In order to upgrade properly, you need to use a major upgrade so that your new version uninstalls the old one and then installs itself (this can happen in reverse order too: new version installed and old remnants deleted afterwards, but this is another story). There are further upgrade types, but stick to major upgrades for simplicity.
The message you are receiving is basically because you have a different package code for the new MSI, but not a new product code or version number (or just one of those problems). You need to get the settings straight.
Recommended step-by-step:
Set "RemovePreviousVersions" to True in the project properties.
In the same place: bump up your version number (one of the first 3 digits)
Answer yes when asked to change product code, or do so yourself manually.
Keep the UpgradeCode the same - it needs to be stable across releases.
Rebuild your setups. Clean out your box of old remnants before testing or test on a virtual.
Testing: Remember to simulate your full upgrade process from first version installed to the new one with different version numbers for a few core files and also try to add a few files and such things. Very important to verify.
Heads-Up: Before ending, it is standard procedure to warn about the potential limitations of VSInstaller Projects (shorter list form).
MSI Tools: Here is a short "review" of other MSI tools.
MSI Upgrade Types: Shamelessly stolen from the InstallShield help file (towards bottom):
Related
We create our installation packages with WiX Toolset. I'm trying to enable 4-digit product versioning (like 4.0.0.195, 4.0.0.196 etc). The problem is that when product is upgraded the previous version is not uninstalled.
I am aware of ProductVersion limitation. And my current approach to the problem is writing a C++ custom action. This action successfully detects the installed product, I have its upgrade code. The custom action is also capable of setting MSI properties through MsiSetProperty. But what do I need to do to force removal of the installed product?
Per this link I see that in MSI there is Upgrade table that I might have to modify. But how do I do it for running installation? MsiGetActiveDatabase gives a read-only handle. MsiOpenDatabase opens MSI files by path.
Am I going the wrong way?
Yes. You are going the wrong way. Use the first three parts of the ProductVersion so upgrades can work correctly.
I am using Visual Studio Community Edition 2017 and trying to create a UWP application.
I get the following error
Your project is not referencing the "UAP,Version=v10.0.10240" framework. Add a reference to "UAP,Version=v10.0.10240" in the "frameworks" section of your project.json, and then re-run NuGet restore.
I had the same issue on my build machine. What's weird is everything runs fine on my local machine.
I managed to fix this by going into the project properties for my UWP app, and changing the Target version to match the Min version.
The reason I believe this issue is happening is because when targeting a higher framework, on a Windows Server machine (the build agent) it doesn't restore all of the packages between your min and target version. It seems to build fine against the version you target.
By the way Ken, following the instructions given by the error don't fix the issue. Try not to be so rude. I came to this page looking for the same issue, and you are no help at all.
I have the same issue, after I remove my bin and obj folder, I can build mine and see the errors gone.
I recently ran across this same issue when updating the target framework. The issue turned out to be the Nuget Restore task in my VSTS Build definition needed to be updated to the latest version (2.*). Once I did that, the builds worked as expected.
I agree with Jeff. Ken Not sure if you should be giving any answers with this kind of attitude.
The error message is misleading there is not project.json at least you cannot see it in the Visual Studio explorer.
I had the same issue and have min and target version set to the same number but it would not build.
The fix was to make sure in Nuget package manager setting to tick checkbox 'Allow Nuget to download missing packages' and the one below it as well and rebuild the project.
This is a pretty weird mistake, but what worked for me :
1st Solution:
1 - Change your project target to "10.0.10586" (or up)
2 - Make a clean / nuget restore / rebuild
3 - Return the project target to the "10.0.10240"
4 - Make a clean / nuget restore / rebuild
Do not ask me why, but it worked :)
2nd Solution:
If you use a repository with Tortoise, try making a CLEANUP
I had an old Backup folder in my project that contained a project.json. Looks like it might have been from an earlier upgrade. I deleted Backup and got a good build.
This happens in exactly this manner, if projects were generated in the year 2017 in the phase where MS changed to project.json and then decided against it. I tried several solutions (and yeah, Ken White is so wrong!) and the cleanest way was to really build up a new clean project in the lastest and up to date version of Visual Studio (VS2015 did not work sustainable) and just copy over the old project content which is just a few minutes work. This will save you a lot of headaches especially working in a larger team!
I tried the above solutions but nothing worked. I had to backup and remove the UWP project and recreate it from scratch.
I tried a couple of solutions.
Solution 1
Open the solution from Windows explorer and search for project.json files. Open all of them (If you have multiple) and make sure the required framework versions are there. I frequently switch between build 10240 and 17763 and I get this error frequently. (I switch between git branches that target different frameworks of UWP) So instead of adding the exact version I just added only the 10.0 part like this.
"frameworks": {
"uap10.0": {}
},
Now if your project.json files are ok, search for project.lock.json files. If you have one or more of those, delete them.
Now clean your solution
Close VS
Delete all the bin and obj folders.
Reopen the VS and try to run the app.
Solution 2:
Go to project properties
Change the minimum and target version to something else and do a clean build. Then put the actual versions and build again.
I had errors installing VS2017 with
Package 'Microsoft.PortableLibrary.TargetingPack.Msi,version=15.0.26004.1' failed to install
The actual IDE will open but I don't have any XAML functionality - it appeared to fail the installation before this component was installed. XAML files won't load and there is no XAML listed under 'Text Editor'.
How to fix this error?
After several hours finally managed to get it to work:
Still not sure exactly what a targeting pack is - and why VS couldn't install it but I manually installed this package and managed to get it to work:
Manually installed:
Microsoft .NET Framework 4.6.2 Developer Pack and Language Packs
https://www.microsoft.com/en-us/download/details.aspx?id=53321
Other things I did that may have contributed to the solution:
I rebooted
I removed all files in C:\ProgramData\Microsoft\VisualStudio\Packages - actually I moved them to an OLD folder and later deleted them. You will see packages downloaded here after you restart the install.
I had previously created a symbolic link from %ProgramData%\Package Cache to another drive to save space (https://superuser.com/questions/455853/can-i-delete-the-folder-c-programdata-package-cache). This symbolic link didn't seem to work anymore leaving me with some files in %ProgramData%\Package Cache and the rest in the other drive. I moved them over and recreated the link. If this is something you did to save disk space and forgot then that could contribute towards a failed solution.
Something above fixed the issue and I now have XAML back again.
Note: The VS2017 RC1 does not support offline installation so that was another avenue I explored and gave up on. The command line switches currently do NOTHING.
I believe the package I needed is the following one but not absolutely sure.
C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.PortableLibrary.TargetingPack.Msi,version=15.0.25719.0
Today after updating our projects it seems Xunit.KRunner is no longer available on NuGet. We checked the Microsoft projects and it looks like they are using the xunit.runner.kre package. When trying to install this the xunit.assert assemly is failing to download from Nuget. Any suggestions to get this working? I am guessing that the versions are messed up.
Here are my nuget package locations:
I'm also using the beta2 version of the kre.
There is/was an issue with the new xunit.runner.kre and VS CTP 5. See below discussion:
https://github.com/aspnet/Testing/issues/65
xunit.runner.xre is available only on myget/vnext feed. Include that in the Nuget.config that you should be able to restore the package
By running on the beta2 kre you're then having mismatched dependencies. If you look at the versions of your xunit bits they're all beta3. I'd recommend upping your kre to beta3 to fix your issue (will affect which packages your app pulls in).
Also as a side note I'd recommend ensuring your nuget.org/api/v2/ feed is enabled (in the SS you posted it wasn't). There's currently an issue where it'll occasionally disable itself; has definitely made my life frustrating several times when things don't build :).
This ought to be simple, but seems to be anything but.
I wish to create an installer that can be used by those using group policies to install products. I do not know then if this must be an MSI, or an EXE. Can an EXE install be installed via a group policy? I chatted with another Wix novice who seemed to think it was a bad idea to have an install that was a plain MSI file.
My product uses the Visual C++ 2010 redistributables. I do not wish to use merge modules. Both this and this link give some of the disadvantages of using them. I object to 1) installing things that the user has not consented to, and 2) not having a control panel uninstall item with a version number that users can inspect and see if they have the latest version of. Thus, I am not interested in responses consisting of people lecturing me on why I ought to use merge modules. If what I am asking for is truly IMPOSSIBLE without merge modules, then please explain why.
I do not know if it is necessary to use a bootstrapper to kick off an EXE install. I gather that it is, but it seems bizarre for me, for an MSI with such involved tables and descriptions, not to be able to kick of a mere EXE, ON THE CONDITION that the redistributable is not installed already.
If it is necessary to use a bootstrapper, I would like to know if anyone can find a complete example, with both bootstrapper and Wix code, for an example of a product install; ideally, together with the command lines necessary to compile them, for such a common case as installing a VC++ 2010 (or possibly 2012) program, together with its redistributable - with the latter being installed as the EXE.
I have found this to be straight-forward and easy to do in Inno Setup Pascal - except for the Group Policy part. I have found anything but COMPLETE examples and/or straightforward explanations to accomplish this using a Microsoft installer. No matter what Microsoft says, I would consider such an installer to be best practices. My code is not managed, and I would like to support XP. Thus, a bootstrapper that requires some .net to already be installed would only add another unsolved layer of complexity to the problem. One that statically links to a .net library might not be too bad, if it did not create very much overhead. My MSI install seems to work pretty well. I did not realize that installing a vcredist_x86.exe would be a problem with such an elusive solution. I do not have Visual Studio. I am using the Qt framework, and have Visual Studio installed only to compile my application. If you have a bootstrapper solution, please specify which bootstrapper you are using. Ideally, the same idea could be extended to more than one prerequisite, and the same coding pattern could be used. If there were a way to use a merge module or additional MSI so that the redistributable would have its own control panel entry, that could be acceptable.
Brownie points for suggesting a mailing list, forum or well-populated chat channel to talk about Wix that does not require one to receive a lot of unnecessary mailing list traffic.
Group Policies by default don't allow EXEs to be installed. I did read about some admins that repackage EXEs into MSIs to deploy them via GPO but that is rather hacky. There is also the possibility to script the deployment - GPOs support script execution, machine or user level.
You can't embed an MSI within another MSI either because only one installation can execute at any time (Windows Installer design).
I don't know how you will be providing your product to your customers but vcredist_x86.exe (I am trying this with the v100 version) uncompresses into the root folder and generates an msi and a cab (vc_red.msi and vc_red.cab) among other files. If you provide these to your customers they can add them to the same GPO used to deploy your product.