I'm trying to use Install Shield LE to package an distribute a winforms app. This is working well and I even have .net 4.5 redistributable packaged in the setup.exe. The issue I am having is I am now creating a version 1.4 of my app, and I want it to successfully uninstall the old versions (1.0 thru 1.3) and install the new. So far I haven't been successful; every time I run the new setup.exe I get a warning saying that the current version has to be uninstalled first using programs and features in control panel.
Does anyone have a decent tutorial or some guidance that could help me improve my customer experience by having my new version replace the old?
Many thanks,
Jason.
In the visual studios project explorer, under your installshield project are a number of page entries. One is called 'General Information' (Under 'Organize Your Setup'), and includes a few sections. The first section is called, 'General' and the first few fields are "Product Name", 'Product Version", "Product Code", and "Upgrade Code".
To create a new installer (setup.exe) that will UPGRADE a current installation, if it exists, there are a few things to do. The key in the way it knows to upgrade a current installation is the "Upgrade Code". If this code is the same as the Upgrade Code defined in the original installation (from the original setup.exe), it will update your installation.
To create an update setup.exe file:
Open the "General Information" page.
In the General section (Top section):
Change the product version to your new version number.
Change the "Product Code" (NOT THE UPGRADE CODE!).
You can do this by clicking the
{...} icon at the end of the Product Code field.
Finally, create a new upgrade path.
Open the "Upgrade Path" page under the 'Organize Your Setup' section.
Right click on "Upgrade Paths" in the tree view on the far left, and select "New Upgrade Path...". This will create a new entry in the tree view. Name it whatever you like.
Click on the entry you just created, to bring up the properties in the window on the right. The first field is "Upgrade Code". This code needs be the same as the code used in the prior installation. If it is different, your installation will install another instance of your program (if the product code is also the same, you would get the "Uninstall other program first" message).
Fortunately, the "Upgrade Code" of your original setup.exe is easy to get. In the Upgrade Code field, there is an ... icon. Clicking this will open up a file browser. Set it to show "All files" as its default is msi files only.
Navigate to the setup.exe file used in the original installation and select it. It will populate some fields for you, including the original Upgrade Code. You will notice it also sets max and min version numbers to the version number of the original setup.exe. Set the max version number to the version number of your new setup.exe that you defined in the General section of the General Information page.
You're set! Build the solution, and the new setup.exe will upgrade a previous installation (with the same Upgrade Code).
Check out this page. It covers the same material, bit with pictures!
http://syncor.blogspot.com/2013/03/doing-upgrades-with-installshield-le.html
Related
I'm looking for a way to add new pages to installer with its own interface. Ultimately, I would like my installer to do many things in turn, enabling the user to go to the next pages and check or set subsequent configurations.
But at the moment I'm looking for how to add an additional page that would run before installation and check if the computer has the required programs to install the application. I would like to attach my ready code to c # to check if these programs are installed on the given computer.
By using this tutorial:
https://www.youtube.com/watch?v=6Yf-eDsRrnM&t=7195s
I created the basic version of the installer. In the tutorial we create installer by using WixUI_Minimal.
I have looked through the documentation and it is written that you can create your own pages, but I can't find anywhere. For example there
https://wixtoolset.org/documentation/manual/v3/wixui/
is Customizing Built-in WixUI Dialog Sets but they dont show how do that.
Update 21th April 2020
I have created a public GitHub Gist, which explains the steps and even include a customized Dialog PrerequisitesDlg.wxs with up to 5 Prerequisites, which can be configured as WiX Properties (text and condition). The whole sequence is wrapped in WixUI_KargWareFeatureTree.wxs.
Text before 20th April 2020
The element you need is UIRef Element, Wix Toolset v3 Documentation.
Wix Toolset is an open source project, so you can review it on GitHub, Wix Toolset v3.
The dialoges which are embed in Wix Toolset are listed here, Source Code of the Default UI-Dialoges of Wix ToolSet. I would use the WixUI_Advanced one, but you can pick all others or start even from scratch.
Download the WixUI_Advanced.wxs from GitHub
Copy the wxs file to the root of your msi-project (where the *.wixproj os placed) and name it to e.g. MyWixToolsetPages.wxs
Edit the name of the UI xml element inside MyWixToolsetPages.wxs (near to line 50)
Add the MyWixToolsetPages.wxs to your wixproject
Replace or add the UIRef reference element in the product.wxs to <UIRef Id="WixUI_MyWixToolsetPages"/>
Add your new dialog as <DialogRef Id="myNewPage" />
Customize the order of the pages with Control Next / Back and Event NewDialog
Be aware to test your sequence in both directions (next, next, next, end) and (end, back, back, back)
Change <UI Id="WixUI_Advanced"> to <UI Id="WixUI_MyWixToolsetPages"> inside your MyWixToolsetPages.wxs (copied from the original WixUI_Advanced.wxs)
...
<UI Id="WixUI_MyWixToolsetPages">
...
Replace the UIRef inside the product.wxs
...
<UIRef Id="WixUI_MyWixToolsetPages"/>
...
I maintain an open source wix authoring tool that enables you to do this by uncommenting one line of XML. The trick is to insert additional rows into the ControlEvent table causing existing paths to be overridden.
https://github.com/iswix-llc/iswix/blob/master/Application/IsWiXNewAddIn/MSISolutionTemplate/SetupProjectTemplate/UI.wxs
https://github.com/iswix-llc/iswix/blob/master/Application/IsWiXNewAddIn/MSISolutionTemplate/SetupProjectTemplate/UI-CustomDialog.wxs
Overall Advice: It is generally an anti-pattern - as of this IT-epoch - to do too much with your setup GUI. In particular it is
better to do per-user configuration as part of the application launch.
Rule of Thumb: You should limit setup-GUI to genuinely shared settings that need to be written with admin or elevated rights to
per-machine locations (inaccessible for normal users). Set everything else from application launch. This can also help QA personnel with their testing.
Burn: Burn is the WiX toolkit's setup.exe creator. It is a bootstrapper, chainer, downloader, installer, etc... construct. Hello-Burn sampler here. And about replacing Burn's default GUI.
WiX MSI GUI: I have a minimalistic sample here for how to change your MSI installer GUI: https://github.com/glytzhkof/WiXCustomDialog. This is the GUI embedded inside your actual MSI. There are other possibilities with GUI.
GUI: You can replace the GUI inside each MSI with a GUI from a Burn setup.exe. There are some details here. This GUI you can implement as a normal executable with all the bells and whistles that allows. The MSI GUI is rudimentary and old. There is another answer here on how to change installer GUI.
VS2019 with the most recent update... Version: 16.2.5
Main error: TF402484 The personnel team project has been deleted
Also : TF10175 The personel team project does not exist.
As far as I understand so far, TFS new name seams to be "Azure DevOps". Some error say TFS while others "Azure DevOps" but it sounds like it is the same.
It got many errors in many projects (into at least 4 different solutions):
There is 3 to 4 kind of different dialog box errors, depending on where and what action I do related to TFS. All errors are about TF402484 error. The error is about a deleted project which nobody has deleted. Most of the time or always, the project has never been part of the solution.
I did not do anything else than updating my VS2019 to the most recent version.
I red: Visual studio 2013 team project has been deleted
About suggestion from previous link: "Undo any pending changes", yes it could seems to temporarily fix the bug BUT there is something that happen that put me in this situation, that seems to happen very often, intermitently and that's very anoying.
In fact, why do I have many items from other projects (not in my current solution) that appear in the Pending Changes window of my current solution?
Starting Source Control Explorer give me many TF402484 DlgBox error (at least 4) and it show "Working..." and stay like that forever. IT just freeze.
Also, I'm using many instances of VS2019 open at the same time. Could it cause the error?
What's going wrong??? What do I have to turn on/off or set, in order to prevent this behavior which is going to kill me in a near future?
Also, perhaps there is no connection, but the only other thing that also changed on my machine: I'm using Cobian Backup to do my backup and perhaps it touches (changes file time) to all or somes solution files.
The error the Undo any pending changes to that project or branches from that project in your local workspace. indicate clearly. You could give a try with below two ways:
Delete the workspace and created a new one, then check it again.
Team Explorer Home --> Under Solution --> Click the arrow down
behind workspace --> Manage Workspaces... --> Select the specific
workspace then Remove
Note: This will remove all your local mappings. Therefore you should check in all changes before deleting it. or back up
Look at Excluded Changes section under Pending Changes and check
if there are any files which belong to a deleted folder/deleted project. If yes,
right click at the file name and choose Undo.
Besides, you could try to clear TFS cache, which may do the trick.
Also reference this similar thread :
Visual Studio TFS: TF10175 During Add Solution To Source Control in
Visual Studio How To Fix
TF10175: The team project does not exists
I'm building a UWP application and I'm getting a build error when the number of resources is 200+ with Visual Studio Community 2017 Version 15.9.4. If I reduce the number of resources below 200 then it builds just fine. Is this a limitation for the Community version? I intend to submit the app to the Microsoft Store and unless I limit the markets the app will fail because it doesn't support all of the required language codes which are included as resource files.
I've tried building a project from scratch...steps to reproduce detailed below. I've reduced the resource list but now I'm faced with denying my app to some markets because I believe the Microsoft Store won't accept my app for that market unless it supports the language for that market.
Start Microsoft Visual Studio Community 2017 Version 15.9.4 with Microsoft.NETCore.UniversalWindowsPlatform v6.2.3 NuGet package (and no other NuGet packages) if that makes any difference.
Click and Select File=>New=>Project from main menu.
Select Windows Universal=>Blank App (Universal Windows) then click OK.
Select Target version 17763 and Min version 16299 then Click OK (but the same error occurs with other version settings).
Select Project=>Store=>Create App Packages.
Select "I want to create packages for sideloading" (but the same error occurs with a Store App) then click Next.
Click Create to accept the defaults.
Click OK to close the popup indicating that the package was created.
Click Build Solution or press F6.
Right click on the app project and select New Folder then rename it Localization.
Right-click on the Localization folder and select New Folder.
Name the folder using one of the Supported Language Codes listed on https://learn.microsoft.com/en-us/windows/uwp/publish/supported-languages.
Right click on the new folder and select Add=>New Item.
Select XAML=>Resources File (.resw) then click Add.
Enter any value, for example String1, for the String1 Name and save it.
Create additional sub folders for all supported language codes and copy the same resource file into those folders.
Add those resource files to the project.
Try to build the project.
Result:
Error Validation error. error C00CE014: App manifest validation error: The app manifest must be valid as per schema: Line 223, Column 6, Reason: Element '{http://schemas.microsoft.com/appx/manifest/foundation/windows10}Resource' is unexpected according to content model of parent element '{http://schemas.microsoft.com/appx/manifest/foundation/windows10}Resources'. App1 C:\Users\Steve\Documents\Visual Studio 2017\Projects\UWP\App1\App1\bin\x86\Debug\AppxManifest.xml
Note: Line 223 is the line where the 200th resource line: <Resource Language="LT" /> is located. However, the error goes away if Resources.resw files are removed from the project until there are 202 or less localization resources in the project. This error is preventing my UWP applications from being available to all supported markets.
One thing that drives me crazy with TFS is the fact that if you have a file checked out, but you made no changes to it, it still shows as a change, distracting you from real changes that you made. This is especially annoying when you use tools such as T4 to generate code, because most of the time the tool will generate the same code, but will leave the file checked out.
For some reason that I can't understand, Visual Studio insists in showing those as changes, and will even claim that there are conflicts if another person happened to check-in the same "changes".
Fortunately, the TFS Power Tools include a command that compares checked-out files with the server version and undoes the unchanged files. I will explain how to integrate it into Visual Studio using a custom tool.
This is unfortunately not available if you are using Visual Studio 2017!
It used to be very simple to accomplish this with earlier versions of Visual Studio:
tfpt uu /noget /r *
How do we remove files from pending changes if they do not have any changes?
This is different based upon your choice of version control system in TFS, so the above problem only exists for TFS' traditional version control system TFVC and not git which has been supported for a few years now.
For TFVS a partial workaround is to mark all files, right-click and Undo... and click Undo Changes button in the following dialog. This will prompt you for the files that are different (letting you choose No or No to All) but not for the ones that have no changes. Important: I write 'partial' because this approach does not work for file renames as the file is considered unchanged so the rename will be undone.
Yes,there are no Power Tools for Team Foundation Server 2017. You could use below workaround:
Right-click on your project ,select undo checkout, then just click okay, or whatever confirmation is left...
Then, while undoing checkout, for every file that has REAL changes in it, a prompt will ask you to confirm the check out for that file... simply click "No to All". Visual Studio will know if the checked out file has changes or none.
WARNING: This method also removes new files, i.e. files that are not yet checked in to TFS. If you want to keep these files then simply exclude them from the set of files you "undo".
You could also take a look at this question: his question Files listed as pending changes when doing merges that didn't change?
The TFSSourceControlExplorerExtension extension is available for VS 2017 and it has an undo unchanged action that works rather nicely.
Stage the change you actually want. The file that isn't actually changed then disappears.
I've searched and searched on here. I've tried the following methods with no luck:
Set the project installer properites to - InstallforAllUsers (can't remember the exact name) but that does add the shortcut to all the user's menus, but only the user that installed the application is able to run it. The other users get a SysWOW64 error about not being able to install it or something.
Set the [DesktopFolder] or [AllUserStartMenu] again, I may not have these property names right, but I followed them from a few users that have posted on here. Giving these properties the value of ALLUSERS. The installer fails during install and says "Unable to locate network location 1" or something like that.
Used ORCA to edit the MSI file and add a property to install for all users, and failed inside ORCA with the error of unable to add property.
It's maddening. I'm using Visual Studio 2010. I think I'm just pushing the limits of the instller.. imagine that. My install is a desktop application (winforms) that has a custom installer action and class that writes some values to a setting file on choices the user makes during the install (custom UI installer screen).
Any ideas?
MSDN Site that explains how to do this
MSI Install All Users
The InstallAllUsers property for a deployment project determines
whether an application is installed for all users of a computer or only
for the user performing the installation. The InstallAllUsers property
can be set in the Properties window when a deployment project is
selected in the Solution Explorer.
Settings
False - The application will only be installed for the current user
and will not be visible to other users of the computer (the default).
True - The application will be installed for all users.
InstallAllUsersVisible Property
The InstallAllUsersVisible property for the Installation Folder user
interface dialog box determines whether the Install MyApplication for
yourself, or for anyone who uses this computer label and corresponding
Everyone and Just me option buttons appear during installation. The
InstallAllUsersVisible can be set in the Properties window when the
Installation Folder node is selected in the User Interface editor.
Settings
True - The Install MyApplication for yourself, or for anyone who uses
this computer label and corresponding Everyone and Just me option
buttons will be shown during installation, and the user's choice
determines the installation method.
False - The Install MyApplication for yourself, or for anyone who
uses this computer label and corresponding Everyone and Just me option
buttons will not be visible during installation."
===========================================================
So here's Step-by-step what you do to install for Everyone as default
without the radio button choices appearing for your users who are
installing your product.:
1. Click on your setup project in your Solution Explorer.
2. Look in the Properties window and set the property InstallAllUsers
to be True
3. Click on the icon in the Solution Explorer toolbar that has the
pop-up tooltip "User Interface Editor"
4. Click on the "Installation Folder" item in the panel that appears.
5. Look in the Properties window and set the InstallAllUsersVisible to
be False.
6. Rebuild your solution.
Some other additional notes to try from a quick search I have just done for you..
I was searching the web for an answer to this question, and I found the answer hidden away on Microsoft's site.
You are going to need Orca.exe from Microsoft. It is an MSI database editor. (http://msdn.microsoft.com/library/de...p/orca_exe.asp) The only way I see to get this file is by installing the Windows Installer SDK (http://www.microsoft.com/msdownload/...msdk/sdkupdate).
Once you are done building your .MSI file, you will need to open it with Orca.exe. Once open, go to the "Property" table. From the menu, Click "Tables" and then "Add Row". For the "Property" string, enter "ALLUSERS", for the value, enter "1" or "2". Entering a "1" will cause the installer to try to add the shortcut to "All Users" and fail if the current user does not have authority, a "2" will cause the installer to try "All Users" first, then fail over to their personal folder. For details - http://msdn.microsoft.com/library/de...stallation.asp
I tested this on "User's Desktop" and "User's Start Menu" and it worked for both. A word of warning: If you re-build your MSI file, it will delete the "ALLUSERS" property entry, so you must use Orca.exe and re-add the setting on each re-build.
I know this is an ancient question, but I've done this before and when I recently had to do it again I had forgotten how. Since my gut instinct was to look on SO before digging into old installer projects, I figured I'd better get the answer posted.
Here is how I accomplish this:
Add a registry search to your launch conditions:
(Name): Search for All Users Programs menu
Property: ALLUSERSMENU
RegKey: SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Root: vsdrrHKLM
Value: Common Programs
Create a new target folder in the file system editor and leverage your new property:
(Name): All Users Programs Menu
AlwaysCreate: True
DefaultLocation: [ALLUSERSMENU]\YourMenuHere
Property: MENULOCATION
Transitive: False
Place your shortcuts in that new folder.
That's it.
For reference here are the folder paths you can access in the registry for Windows XP:
and for Windows 7:
See ALLUSERS property on MSDN. The link in the first comment is broken.
http://msdn.microsoft.com/en-us/library/aa367559%28v=vs.85%29.aspx