I'm using Windows 7 64, VS 2013.
I'm trying to create an MSI installer that contains 2 C# applications distributed in 2 different folders, both folders are containing 1 DLL file that is the same. I am adding all necessary dependencies, everything seems fine, but after installing, one of the applications throws an error regarding loading of that DLL.
My assumption is that the VS installer project keeps the files in a common folder and when it sees the same file it automagically refers both application to use the same exact DLL.
My work-around for this problem is to rename the DLL when adding it into installer project and make a small .bat script that renames the DLL after installation. This works, but I'm guessing there's a more elegant way to do it besides having scripts run at install/uninstall time that will rename some DLLs.
Strictly speaking, Windows Installer has something called the component rules. One aspect of this is that a given file in a given folder can only belong to one component. The same files in two different folders would be two different components because a component can only define files for one folder.
WiX creates MSI and has a feature called smart cabbing where the file would be normalized when compressed into a cab and embedded into the MSI.
Visual Studio installer projects are of very low quality and will killed by Microsoft before being brought back to live as an add on. It has horrible dependency scanning and you are finding that the "automagical" behavior doesn't work very well.
Related
Currently, our customer uses a Windows .bat file in order to batch-install a series of installers (currently .exe files produced using Inno Setup, although there are plans in the future to replace them with .msi installers) found in a directory.
However, they have requested that this be replaced with an .msi file -- it sounds crazy to me (as it doesn't actually INSTALL anything, merely search for external files already on the target machine and then run them) -- but presumably it is in order to take advantage of Windows Installers' logging functionality, as well as to prevent unauthorized tampering with the installation process.
Most of the stuff I've found on Windows Installer custom actions seems to refer to running programs installed by the MSI, not programs that were already on the target machine before the installer was run. What do I need to do to run already-existing files (in the same directory as the MSI itself) as part of an MSI's processing?
I'll accept solutions using either Visual Studio or WiX.
We have a folder of text files that needs to be copied to the server whenever our application is deployed. Currently, we handle this by manually copying/pasting the folder's contents.
How can I include this as an automated step in the MSI?
I want the folder (and it's contents) to be included in the MSI. Then, on install, I want to the files in the MSI to overwrite the existing files (in a given local directory).
The files are in source control (TFS), but they are not part of any .NET project.
I've used the Nullsoft Installer before (among others), and that's basically all it does (you tell it what files to pull in and where to put that at install time). Visual Studio automates a lot of this... but I just can't see where to do the basic task.
I have .net 3.5 application
I have made basic MSI installer with installshield added .net 3.5 in Redistributables tab rebuild and checked .msi and .exe but size is same .net only added in ISSetupPrerequisites folder
Installshield does not put Redistributables in .msi?
I must send full folder (DiskImages) to my clients?
their would be no points in putting the redistribuable in the MSI since you cannot launch another msi while an msi is runing.
a good practice would be to compressed all your files in the setup.exe. it's easier to carry around and prevent anyone from replacing them with nasty stuff and launch them with admin's right.
right click on the prerequisit and open the properties
Now specificly for the .net 3.5, since it's a windows feature on most of the modern OS (anything but xp...) the installation of the module will failed. I would suggest making a launch condition validation the presence of the registry key HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5|Version. like that
it will make your installer smaller and probably more usefull since you can customize the error message to explain how to activate it.
You can compress everything into the .exe file (select compressed, and "extract from setup.exe" as appropriate), but since Windows Installer does not handle prerequisites, it cannot be just the .msi file.
If you stick to the uncompressed build you described, then yes, you must send the full contents of at least the Disk1 folder (also any other Disk folders if there are any; they're typically only used for multiple-disk media scenarios).
I am creating a installer for my application using VS Setup Project. Everything works great, but the issue is, whatever files or extra DLLs I used are present in the Application folder, which I want to remove so that my folder contains only files are required by it and not by the installer. I have been searching for a way to achieve this, but I am unable to find one.
So is there any way to remove extra DLLs, text files, that were used by installer, after the installation of application. ???
Or
is there any special folder in which we should keep Dlls used by installer so that they are automatically removed once installation is completed or machine is restarted ???
I am really confused in this, as it looks to me a very common requirement of removing temporary files that are only used by installer, after installation is completed.
The setup project installs whatever you added in Application Folder from File System Editor.
If you are using a project output, remove it and add your application files manually. If you added the files manually, remove the ones you don't want installed.
I'm working on some automated build changes and have some questions as to the best approach for building/packaging EXE applications.
Conceptually, there are two scripts. The first builds everything at puts the resulting binaries on a share so they are available for deployment. The second set of scripts are each responsible for copying and configuring some application from that build result.
The first script, which builds the entire solution, copies the build result to known pickup location by overriding the msbuild output path. This causes binaries for all to be dropped in the same folder (except web applications, where each project is in its own website under _PublishedWebsites). This is problematic as when I build an installer for a single EXE project, I only want to include the EXE and dependencies of that EXE. However since all project outputs are in the same folder then it is not clear which are needed by the individual application.
Given that the build has put the binaries for all the executables in one folder, how can I build an MSI that only includes the binaries needed for a particular EXE?
I am using psake/powershell for the build scripts, using msbuild to compile the solution files. I am using WixSharp the build the installer from a command-line app (not CSC).
SUMMARY
Since Wix# actually builds the MSI when you "run" the .exe it creates, and uses the WiX toolkit, you would need to output the executable Wix# + WiX Toolkit creates to your drop folder. Then make sure the WiX toolkit executable files are either on your PATH or in your output folder, and create Powershell script(s) that invoke your Wix# executable(s) in the drop folder. One straightforward approach would be to have one Wix# project for each separate "product installer", and have each these Wix# executables be output to your drop folder, for further processing/generation of the MSI files by your downstream Powershell (or other) scripts.
I am using Wix# integrated into the VS2013 IDE, so my answer should be interpreted in that context. My Wix# installer is simply one project of several in my overall solution.
EXAMPLE FOR A SINGLE Wix# PROJECT IN A VISUAL STUDIO SOLUTION
So, for example, if your Wix# project code file is set up in VS as a project named named MyWebsiteSetup, and the Wix# code file is MyWebsiteSetup.cs, your Wix# executable will be located at \MyWebsiteSetup\bin\debug\MyWebsiteSetup.exe.
Have the build place this MyWebSiteSetup.exe file in the drop folder, along with the other files Wix# places in bin\debug folder. Then have your second set of scripts run the MyWebsiteSetup.exe program, which will generate the MSI. I believe you may need to have the installation component files the Wix# code requires be deployed to the drop folder as well, and in the expected folder structure. Wix# seems to place all the other support files it needs in the bin\debug folder, so just having all the files copied from the Wix# project's bin\debug to the drop folder should get you what you need.
ADAPTING THE EXAMPLE TO MULTIPLE PRODUCTS (MULTIPLE Wix# PROJECTS)
Now, your question was how to do this for multiple websites where all the files are placed in the same drop folder. There are several ways to approach this, but the one I suggest is to have a separate Wix# project in Visual Studio for each separate product, and have the Wix# output files for each of those projects deployed to the drop folder along with the product files. If your separate products were named MyWebSiteSetupA, MyWebSiteSetupB, and MyWebSiteSetupC, they will generate executables MyWebSiteSetupA.exe, MyWebSiteSetupB.exe, and MyWebSiteSetupC.exe. You would simply have your second set of scripts invoke each of those in turn. Each of the Wix# code files (.cs files) for those projects of course will have been coded to know what files it needs to pick up when it runs, and when the resulting exe is run, it will get the files it needs, provided you've made them available where expected, and build the individual MSI's for each product's installer.
There are of course, numerous other approaches for this, with flexible tools like PowerShell, each approach with pros and cons, but I hope this helps get you started with an approach you can then tailor to your needs.