After compiling a Visual Studio setup project: there are two files produced: application.msi and setup.exe
If I run application.msi, the new version is not rewritten to the old version. It is likely to run setup.exe for all of the cases. That made confusion if I give two files to the clients. How can I made just one file?
The Setup.exe file is a BootStrap file used to check for the prerequisites that you setup in your Setup Project's Prerequisites Dialog. The MSI package itself is what determines the applications installation parameters. You should have Remove Previous Versions as true and make sure that your application's Assembly version has been incremented by at least the Build Number, otherwise if you are updating only the Revision number it will not be over written. The Assembly Version information Format is as follows. Major.Minor.Build.Revision. Make sure that you also change your setup projects Version number also.
You can package the MSI with setup.exe into a single self-extracted archive and launch setup.exe after it's unzipped.
Related
I am using Installshield 2015 with Visual Studio 2013. I created a setup.exe for my application. In order to start my application, user needs to run SpeechPlatformRuntime_x86.msi or SpeechPlatformRuntime_x64.msi.
How can I add these msi file into my project so after installation finishes, it automatically run msi file?
These sound like they provide dependencies. Since you deliver a .exe file, I would suggest creating a prerequisite and including it in your project. This will result in them being installed first, and your main .msi (or InstallScript) project contents will follow.
(If you delivered only a .msi file, you would probably have to document your dependency. You could look into the Chained .MSI Packages support, but it's not really that well suited for handling dependencies.)
I am trying to build a large Visual Studio 2010 solution that contains some setup projects from the command line using the following:
devenv.com mySolution.sln /rebuild "Debug|Mixed Platforms" /out E:\myUser\Desktop\build.txt
The MSI files are generated fine. They actually work and install the application as they should be doing it. But here comes the problem: When a change is made on the code and then the solution is rebuilt following the process described before, the application installed by the new MSI does not contain any of the changes made in the code.
Do you have any comment that could help me understand what is happening?
Thanks in advance.
You can't just rebuild an MSI file and install it when that MSI setup has already been installed. You need a RemovePreviousVersions upgrade (increment the version of the setup project in its properties window and say yes to the answers).
This might be useful:
https://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
it still applies except that you must also increment the file versions of the binaries in your setup for them to be updated during the upgrade.
I have an update to third party .DLL that must be installed onto my clients' computers. We currently employ automated installs via MSI that are created in Visual Studio 2010
Unfortunately, the third party .DLL was versioned incorrectly and file version of it was not increased by the provider (they only increased assembly version). The third party provider is Microsoft, so waiting on them to fix the issue is not realistic. We need to get the new .DLL to people now and within one MSI update. Right now, MSI update is not overriding the .DLL
Is there a way within VS2010 Setup project to force override a .DLL even if the file versions match?
If you are willing to do msi postbuild tweaking you can hit the File table and do "version lying". Another thought is to not put that DLL in your install. Find an installer from Microsoft ( if it exists ) that you can put into a bootstrapper or create your own installer and use AMUS instead of OMUS for the version rules.
Can't you just add the file to your installer as a 'file' and install it with the other files? Don't set it as project output, or any of the canned install actions. Go to the file portion and right click the "Application Files" folder, and say > add file. Navigate to the file that you want and choose it.
I have a Windows Forms application with an installer (.msi) already created with Visual Studio. I am now creating a new installer for version 2.0 with the property RemovePreviousVersions set to true.
Now, when I install 2.0 over 1.0 it removes 1.0 and installs 2.0 completely.
Is there a way that I can tell the installer if you find some files already installed (like .xml files used for data) then don't override them?
I am trying to have my 2.0 installer serve the 2 purposes:
Install from scratch for new users
Existing users will upgrade but not lose their customizations
The deployment project in VS does not overwrite files. What happens is that since you have RemovePreviousVersions set to true, when you change your program file version and the ProductCode GUID of the setup project, it will first uninstall the previous version and then will do a clean install of the new version.
To make sure some files don't get overwritten, I usually exclude them from the Content or Primary output files (wherever they are located) and then add them separately to the setup project. Doing this, you can individually set properties for those files. The property you are looking for is called Permanent" that if set to true will never uninstall the file in question, and therefore will never overwrite it with a new version. The only drawback with this is that when you uninstall the product, the Permanent files will not get removed from their target locations, but in my case (usually local DB files), that's a good thing ;)
Cheers!
[edit] The above is true for VS 2008 SP1. Haven't tried it on other versions, so hopefully you are using the same VS version or it works for the version you use.
[edit2] Oh, also you could also use the "Condition" property to achieve something similar. If you do that, make sure that "Transitive" is set to True so the Condition is always evaluated. Haven't tried it with Conditions, but that's another option you could look at. Other than these 2, I think that's pretty much it for VS deployment projects.
When I was in a similar situation what I did was:
The files that were customized by each user and should NOT be touched by the installer were NOT included in the MSI (NOT in the Visual Studio Setup Project). When the app was run for the first time I generated the XML files through the code.
The files that were static (e.g. data that was used to populate Dropdownlists) I included in the MSI and I can update those by building a new MSI with Visual Studio.
Basically don't include customizable files in your MSI project. Create them in code for new users.
I never looked into telling the MSI not to update certain files that are included in the MSI file. The solution I came up with was perfect for me. I don't know if it can be done.
I hope this helps.
I have prebuild events on the installer to rebuild the projects with the appropriate configuration etc.
If I right-click build/rebuild on the WiX (3.0) project in visual studio it all builds fine, but if I try to run MSBuild on the wixproj file the pre-build events will throw errors.
I can instead call Candle and Light on the wixproj but it won't run the pre-build events.
The prebuild events rely on the macros provided by VS and I'm not sure how to get around that other than creating another project and basically just use the prebuild event of the project which just screams hack.
Another problem is that I need to feed in a self-updating version number into WiX from the command line.
I was planning on using just a csproj to handle the version number and updating it and just shelling to the MSBuild and Candle and Light, but the problem is that I don't know how to access the solution directory from code other than hard-coding it in
We found it easiest to use a utility to edit the project itself and to dump all the pre-build and post build events before we build it with our autobuilder (in our case VisualBuild).
This leaves us with a nice and juicy build process that doesn't rely on any nasty hacks in the IDE and give us full control over where source comes from and where built components go to.
I'm using a different way that works well for me, which I described here.
I maintain the version number in a batch file, which just writes it into an environment variable
I create my release builds by running a batch file that first calls the "version number" batch file (so I have the version number in an environment variable called %VersionNumber%) and then executes an MSBuild project file
The MSBuild project file builds the solution, and I get the version number for the .exe in the .csproj file by reading it from the environment variable if it exists (and then I use MSBuild Community Tasks to create an AssemblyInfo file with the version number in a pre build event)
This means that the .exe has version 0.0 when built from Visual Studio, but Im fine with that because I create all my releases from the batch file.
To create a relase build with WiX setup, I execute another batch file, which just calls the "build" batch file mentioned above, and then calls the WiX utilities candle and light to build the actual setup.
candle uses this .wxs file to create the setup, where I again get the version number from the environment variable: $(env.VersionNumber)
the final .msi file created by light includes the version number in its file name because I pass the file name (including the environment variable with the version number) as an argument: -out release\msi\bitbucket-backup-%VersionNumber%.msi
It took me a while to figure all this out in the beginning, but now I release all my projects in a similar way.