This is my first dabble into Setup Projects.
I have Solution in VS2013.
Within the solution is a C# Winform project, and a Setup Project.
On first build, I can use the setup.exe to install my application on my laptop; no issues.
However, when I make changes to my Winforms, these are not reflected by any subsequent re-install.
Quite simply, the build does not pass winform changes to the setup package.
To explain:
I make changes to a form, for example I add a label or button.
In my setup project I increase the version number.
VS automatically generates a new Product Code.
Build all.
Copy the setup.exe + msi from the setup project's debug folder.
Paste to desktop.
Execute setup.exe
Install completes successfully.
Control Panel > Programs, confirms the new version number.
Yet running the app, none of my form changes are there !?
Hope someone might be able to explain what's going on, what I am missing !?
Many Thanks
A Visual Studio Installer project will automatically pick up the right version of the application if you add the Primary Output of your application. So that's that.
It could be that Visual Studio does package the new version of the executable, but it does not get installed, because you forgot to increase the executable's version number, too (not just the installer's version number!). AFAIK, Windows Installer replaces files only if the version number differs.
What happens when you uninstall the old version before installing the new version? Do you then see your changes? If that's the case, try increasing the version number before the next update.
Change all version numbers of your hosted application in AssemblyInfo.cs together with Version number and Product code in your installer (Setup project).
Related
This is my first time trying to make a deployable program. After creating a nice little WPF XAML app that runs (i.e. I can run the executable in the bin folder), I am trying to wrap it in a setup program.
After following multiple directions online for both WiX and "Microsoft Visual Studio Installer Projects". Both make installer packages, but they are only targeting the dll file from the WPF XAML output when I as for the "Primary Output". It seems this is stemming from the build of the WPF project.
How do I adjust the primary output of the build process so it is included in the setup program?
Screenshot of build output specifying the dll as the output file:
To add more details:
This could be one wpf(.net core) application instead of one wpf(.net framework). See the Output window in Elton's screenshot we can find the output is xx.dll instead of xx.exe.
If we create a Installer project in this solution, right-click the Installer project=>Add=>Project Output=>Primary output to contain the WPF's output in installer project, only the xx.dll is considered as wpf's output, but not xx.exe.
So after building the Installer project in VS, double-click the setup.exe(installer project's output), the wpf.exe is not well installed.
On top of Lance answer. You can add the publish items to your outputs near your main Primary Output.
1- Right-click on project and select Add => Project Output.
2- Choose your target project and select Publish Items from the list with your configuration.
3- Now you have another Output in your Application Folder.
Done. with every Batch Build you have your publish directory copied to application folder.
My Visual Studio 2019 WPF app is setting a dll as the output when it
should be an exe.
I'm sure you're using a WPF(.net core) project cause yesterday I happened to reproduce same situation in my machine. As for the cause of the issue, if you're interested in it, you may get some help from this issue. For .net core 2.2 and earlier, if we build a console(.net core) project, we'll get a xx.dll as output by default(Use dotnet xx.dll to run that).
But for .net core 3.0, I found this situation changes. Now if we build a Console(.net core) or WPF(.net core), apart from the xx.dll, we'll also get an xx.exe now. And I checked the Updated date of Installer Project and the Release date of WPF(.net core), the latest update of the Installer project is much earlier than the release of WPF(.net core), I guess maybe this is the cause? I'm not certainly sure how Installer Project recognize the output of one WPF project, but I suggest you can post this issue in DC forum , if it gets enough votes, the team will consider a fix.
Here're my workarounds which may help:
1.Use Add=>File instead of Add=>Primary Output:
Build the WPF project in release mode, navigate to the output path and copy that path. Then right-click Installer project=>Add=>Files to enter that path. Choose all files in output folder and click open:
Right-click the assembly file and choose Find in Editor:
Right-click the xx.exe=>Create a shortcut. Then move the shortcut to User's Desktop folder and set the AlwaysCreate property to be true.
After that, build the installer project and install that xx.msi or setup.exe in my machine, I'll get a shortcut in desktop, double-click it will run the wpf(core) application.
2.See this blog, we can use command like dotnet publish -r xxx -p:PublishSingleFile=true to get a single-file executable which is self-extracting and contains all dependencies (including native) that are required to run your app. In this situation, you don't need a Installer project to deploy your project. The single executable is enough. Hint from Lex Li in this issue.
Hope it helps :-)
I am trying to update an application using the Install Shield project in visual studio 2012.
I have read tons of articles/stackoverflow questions about it, and every single one gives the same steps for updating an existing application:
Increment product version
Change Product Code
Build Setup
So I do exactly that. First I build my application, then I build the setup. I find the setup, and I run it. It installs the application as expected.
Then I make a minor change to my application (changing the background color for example), then I:
I build the application
Increment Product version from 1.00.0000 to 1.00.0001
Change the Product Code - I Click the {...} to automatically generate a new one
Make sure the Update Code is the same
Build the setup
Go to the same directory I found the setup in before, and run the setup. It indicates that it installs, but then when I run the program, it is the original program - and in my Control Panel > Programs, there is now 2 instances of the application. And in the install directory of the application, it is still the original files.
I have clicked the resequence RemoveExistingProducts, and still the same thing.
edit: I am just using the basic version of InstallShield that came with VS2012
Anyone have any ideas what I am doing wrong? I have absolutely no idea what I am doing wrong...
As stated within the Upgrade Paths section of InstallShield within VS2012:
If you have released earlier versions of your product and you want to ensure that end users are able to upgrade to the current version without manually installing the earlier version and then also installing the current version, use the Upgrade Paths view to indicate upgrade information.
So in order to upgrade any previous installations, you need to add your application's Upgrade Code to the 'Upgrade Paths'. You can do this from the Solution Explorer:
[InstallShield Setup Project] -> Organize Your Setup -> Upgrade Paths
From that tab, you will right-click on the 'Upgrade Paths' option on the left side of the center pane, and select 'New Upgrade Path...'. You will then be presented with an option to select an installer (.exe or .msi) for your project which will populate the Upgrade Code field. Make sure you set the Min and Max Version fields to specify which versions of your application that you'd like your new installer to upgrade. If you'd like the new installer to upgrade any installed version of your application, then simply set the 'Include Max Version' and 'Include Min Version' fields to no.
You should now be set to build your solution, and when running the new installer, you'll find that you will no longer run into the problems you've specified.
I have created a setup project in visual studio. It works fine, now when i make some changes, create new setup file and then try to execute it. It gives me this error.
I don't want user to bother with this step. I want it to update the application or uninstall it first and then install new version.
How could i do this.
Kindly guide.
Windows Installer automatically uninstalls the old version if you increase your package ProductVersion and change the ProductCode. This can be done in the project Properties pane.
If you don't do this, you need to uninstall your old package manually using the Control Panel applet.
I have created a msi install package for my project from the VS2008 deployment project. but I am having problems when it comes to upgrading installs, The previously installed version does not get overwritten. How do I ensure that previously installed versions get overwritten?
In Visual Studio select your Setup project within the Solution Explorer
Open the Properties Window
don't right click and select properties.
select View - Properties Window
set RemovePreviousVersions to true
increment the version to a higher number
select yes in the upcoming message box
If you built and deploy this new setup, a setup with an older version number will be deleted.
Important: the setup version number is completely independent from your application or assembly version number!
(Oliver's answer is correct, but I wanted to add pictures and some more details)
Select the setup project in your solution, then open the Properties pane (the tab next to Toolbox):
Make sure DetectNewerInstalledVersion is true (it is be default)
Set InstallAllUsers to true
Set RemovePreviousVersions to true
Update the Version number and hit Enter
After you hit enter, Visual Studio will ask if you want to generate a new GUID for ProductCode, click yes
Additionally, you need to update the version numbers for each project in your solution, because the installer will only replace DLLs if their version number has been incremented:
Open each project's AssemblyInfo.cs and update the AssemblyVersion and AssemblyFileVersion numbers
Or a better way:
Remove AssemblyVersion and AssemblyFileVersion lines from each project's AssemblyInfo.cs
Link to a VersionInfo.cs file in your solution with those 2 lines
Step-by-step for the above: The Right Way To Version Your Assemblies
Right-click on the setup project and select Properties (a different Properties dialog):
Set Windows Installer 4.5 as a Prerequisite instead of the Visual Studio default of Windows Installer 3.1
I'm not sure if all of these steps are necessary, and there may be other ways to set this up, but the above steps work for me.
Windows Installer has built in checks on your files to make sure that the version is higher than the previous version of that file. If it is not, Windows Installer will not overwrite it. For more extensive info on how Windows Installer handles versioning check out this MSDN article:
http://msdn.microsoft.com/en-us/library/aa368599%28VS.85%29.aspx
We need to set REINSTALLMODE property of our msi file to amus.
Following is the link to know more about the meaning of 'amus'
http://msdn.microsoft.com/en-us/library/aa371182%28VS.85%29.aspx
There are two ways to do that.
By using msiexec.exe which comes with .NET SDK (if you have VS 2005 or VS 2008 it will come with it, just browse to command prompt of visual studio and you will find it there)
once you find msiexec.exe just type following command to set REINSTALLMODE property to amus for your installer.
msiexec.exe /i foo.msi REINSTALLMODE=amus
I distribute my application using a VS2008 install package, which normally works great. When I create new versions of the app, I go in and increment the Version property on the install package and verify the RemovePreviousVersions property is set to True.
This works just fine most of the time - I just run the install package for the newer version and the older version is uninstalled and the newer version replaces it.
However, occasionally the install package will run successfully, but when I start the program the old version starts up. Apparently the old version of the .exe is still present.
I end up having to completely uninstall the software and install the new version, which always works, but is a pain.
The file isn't in use as far as I can tell and the install package doesn't tell me to reboot.
Any ideas about what's going on here?
Not a direct answer, but the key difference between an upgrade and an uninstall+ a reinstall is that any custom uninstall steps are not called in 2k8 but are in 2k5.
This is referenced in Visual Studio 2005 -> 2008/10 Service Installer Project Upgrade issue
The other difference related to this is that in 2k8, the files get upgraded based on the version info resource - if your modules dont have newer versions, they dont get replaced.
In some cases whether you strong name also has effects, but I'm pretty confident the last paragraph covers the issue you're seeing.
second is By using orca
Orca is utility to modify msi files.
You can download 'Orca' from following links. http://www.softpedia.com/get/Authoring-tools/Setup-creators/Orca.shtml
Steps:
a. Install orca into your computer.
b. Open orca
c. Drag and drop your msi into orca UI
d. Into left panel it will list the name of tables
e. select property table
f. go to right panel and right click
g. click on 'Add Row'
h. into 'Property' type REINSTALLMODE
i. into 'Value' type amus
j. save msi file
k. and that's it
Now when you install it will overwrite all files.
We need to set REINSTALLMODE property of our msi file to amus.
Following is the link to know more about the meaning of 'amus' http://msdn.microsoft.com/en-us/library/aa371182%28VS.85%29.aspx
There are two ways to do that.
By using msiexec.exe which comes with .NET SDK (if you have VS 2005 or VS 2008 it will come with it, just browse to command prompt of visual studio and you will find it there)
once you find msiexec.exe just type following command to set REINSTALLMODE property to amus for your installer.
msiexec.exe /i foo.msi REINSTALLMODE=amus