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.
Related
How can we include a separate .NET application inside a VSIX package? Preferably in a subdirectory so that it doesn't interfere with DLLs of the Visual Studio extension itself (different versions). The application is available in the same solution, but for the same reason I van also not add a reference to it in the main project.
The intention is to run that application as a separate process, started by the extension. The extension will then connect to that application through WCF.
I'm pretty certain you just need to include the .EXE in your .VSIX. A .VSIX is just a .zip file, and you can include additional files into it by simply adding them to your project and setting the Include in VSIX property to true.
To confirm, try downloading something like the Azure Data Lake and Stream Analytics Tools VSIX to disk. (I mention this one because I noticed it installed a number of .EXE's under my C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions directory).
Once you have the .VSIX on disk, rename it as a .zip file and unzip, or view its contents with the windows explorer. Note that the extensions.vsixmanifest file contained in that .zip has no references or entries for any of the .exe files installed by that .VSIX. Which means, all you really need to do is include it in the .zip file.
Add a subfolder to your .VSIX project, copy the .exe there, add it to your project, set the Include In VISX property to true, and I suspect you'll be all set.
Sincerely,
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.
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 am developing a Visual Studio 2010 extension (VSIX project) to add some extra properties to the entities in the Entity Framework designer. In addition to registering the appropriate classes for MEF discovery, I would like a T4 include file to be copied to the %ProgramFiles%\
Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Entity
Framework Tools\Templates\Includes folder when the extension is installed, but I don't know how to do it and the VSIX properties page does not seem to show any option for this.
So my question is: is there any way to have a given file being copied to a given location when a VSIX project is installed?
Using VSIX only, no, there is not.
Whole contents of VSIX package are during installation simply unzipped into your local extensions directory - and that's END regarding file installations.
Whatever you want to copy anywhere, you must deal with it outside of the VSIX installer. For example - use different installer. Or, for another example, upon first-run of your plugin, somewhere in package.Initialize(), check whether the files in question exist in right places, and if not - copy them there.
Of course, if you want to write to the ProgramFiles directory, you have another barrier in front of you: the UAC protection. To write there, you will need an another executable that your plugin will run in elevation (and asking the user for permission during that, etc) and it only it will be able to copy the files there. Well, of course, unless you happily assume that everyone always run their VisualStudios "as administrator" and simply ignore the UAC and your users' tears.
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.