I installed the Visual Studio 2017 Installer and added an installer project to my solution.
When I'm building my main project, I'm using post build events to create a Production directory (in which all files are nicely sorted into directories) - for the sake of the example, let's say that this is the new path: C:\workspace\NewProject\bin\release\Production
I saw that the installer takes the build files (located under the debug/release folder under C:\workspace\NewProject\bin\) and those are the files which will be installed when running the msi.
However, what I wish is that the installer will ignore all files under C:\workspace\NewProject\bin\release and use the files under C:\workspace\NewProject\bin\release\Production
Is that possible? Or should I somehow configure the output folder's files from the installer's properties?
Although the "project output" option is popular as input to setup projects it's often better to just use the Add File of option in the File System view in the setup project, adding it into the target folder. It's better because you see exactly what you're adding, and the destination locations that may be scattered anywhere on the target system (Program Files, Common Files, GAC and so on).
There's no advantage to organizing files into nicely sorted folders on the build system because the setup project doesn't care. If you want the files nicely sorted on the target system you need to create those folders in the File System view on Target machine and add each file to its destination.
Related
I am trying to create installer file by Visual Studio 2015 Installer.
When I add Primary output from <project name> into Application Folder, it point to files in obj folder instead of bin folder.
After installed, I can NOT start my application. I think the reason come from "obj/Release".
Please refer to attached image for more information:
Why? How can I change it to bin folder?
The easiest thing to do is to forget about primary output and just add the files you want by browsing to them from the IDE's File System view, especially if it's just one or two files, and it typically help to see the files you're installing and know exactly what you're doing. Also, note that other files (such as data files) should most likely be installed to user's application data (not Application Folder), and shared Dlls might need to be in common files folder, and assemblies into the GAC. Using primary output tends to gloss over this kind of detail.
I am hoping to get some help to figure out how to create an installer in visual studio 2013.
My class library project generates a DLL called DataTest. The solution also has an xml file called config.xml. Currently when I build the solution the DataTest DLL ends up in the bin folder (and the config.xml is just a static file somewhere). What I want the installer to do is copy/install the DataTest DLL to C:\MyData\Test and the xml file should end up in C:\MyData\Config.
I have found this http://geekswithblogs.net/TarunArora/archive/2014/04/24/visual-studio-2013-installer-projects-ndash-hello-world-installer.aspx which seems like a good place to start but I don't have much experience with the different configurations in VS so I don't really know how to do what I want to do.
Thanks
I'm assuming you want an MSI file to do the install because you posted that link, so you're using the Visual Studio Installer projects extension.
This might also help, old but still applies:
https://www.simple-talk.com/dotnet/visual-studio/getting-started-with-setup-projects/
Configurations in Visual Studio don't really have much to do with this. The Bin, Release, Debug folders in your build are nothing to do with where you want to deploy the file on the target system. For example, if you have a Dll that you want to install in the Common Files Folder then you select that folder in the File System view of the setup project and just drag and drop the file in there. The same principle applies to the Program Files folder, which is the usual place for applications.
I've built against the release profile and this creates an executable build within the release directory in my project.
How do I best distribute to clients from this executable? There are a lot of files within this folder which don't appear when installed through the installer, such as the mainifest and one called application.exe.xml (which is confusing when Windows hides the extension in Windows Explorer).
Are these all necessary? Can I just send the executable? Or will I need to send with all the files? Is there a way to build without all these files?
You must send the EXE file and any DLL file that you reference locally. If you use COM references and the like, you need to register them during the installation. The same thing for the GAC I think, but I haven't used that for stand-alone applications myself.
The application.exe.config file contains the application settings (a copy of app.config). If you don't use settings or the user doesn't typically care about them, you can omit the file, and it will use the default values you built the application with.
The vshost files are not needed (if you have them). They are used by Visual Studio's debugger. The .pdb files contain debug data used to facilitate DLL file to source matching. Unless you plan on attaching a debugger to the application, there is no point sending those.
Usually, in an XCopy deployment you have to deploy (literally copy all files deployment with no setup/installer program) the content of the output folder (like debug or release) without:
*.pdb - debug symbols
*.xml - xml documentation
?vshost? - Visual Studio hosting files
In fact, it anyway also depends on your specific application. As a developer, you need to know what you are producing; in case you are using an xml file which is not the result of the .NET documentation compiler, but a static file copied in the output folder, then do not forget to deploy it.
A last note: developers usually disable the option to hide file extensions in Windows Explorer ;-)
You need to understand what an installer does or why an installer is important.
An installer takes care of the basic environment. The installer can carry dependent assemblies/modules along with the application. It can also check if you need something before you run, like .NET on the target machine. It can also create the shortcuts on the desktop or start menu. Plus it also provides adequate options on the target machine to uninstall it.
If you wish to ship the executable alone, you might miss out some assemblies that the executable depends on. The target machine may or may not have the correct .NET version installed.
Use the program: HM NIS EDIT from HM Soft.
Build your project
Run NIS EDIT
Make a new script from the wizard (Ctrl + W)
Run all the steps
Select all the .dll and .exe files
Build a setup file
I have a WPF project and a post build event which copy files from a folder outside of the solution into the output directory.
I want to publish my application with Clickonce publish. The only problem is that the copied files are not included in the publish or the manifest.
I tried using MageUI.exe , msbuild /target:publish from the visual studio cmd and even tried to change the project file by hand including a beforepublishevent but none of that worked.
I am open to suggestions, but what I want is to take the output folder and make the installer install the output files. (e.g. install the .net 4 framework and visual c++ runtime libs)
If you don't want them in the solution, but you do want them in ClickOnce then the only possibility is to use an external tool to create the ClickOnce manifests as you can't add non-project files to the ClickOnce output in Visual Studio.
There are two options I know of:
Use MageUI to manage your ClickOnce manifests. You can add additional files to your application in Mage.
You could use some software that I created and sell called ClickOnceMore (www.clickoncemore.net). ClickOnceMore will allow you to add all the files in one directory to your ClickOnce manifests by adding a single folder include. You can also then control which sub folder on the client they get deployed to. It was designed to make scenarios like this simple. You can download a free trial on the web site.
I hope it helps. Apologies for the marketing plug, but I do think ClickOnceMore can solve your problem perfectly.
Instead of copying the files through a post-build event, why don't you include them inside the project, and mark Copy to Output Directory = Copy if Newer?
If they are DLLs, you can add them as reference instead.
There are other options to create installers such as WiX+SharpSetup. It's much more flexible, but also more complicated, and takes more time to create simple installers.
I need to generate a list of all the files which are enough to run my application on any machine. I need this for a setup program. When i go to bin/release folder i'm able to see some pdb files and some configuration files, which i think will not be needed. I tried to disable generation of pdb files too but it still generates pdb for the other projects present in the solution.
So i need a way in visual studio 2008, which can get me all the files (the .exe and .dll and other files) required by my application to run.
Thanks.
Have you tried publishing the application (Build > Publish [app])?
This should just copy all the essential files to the specified folder.
The pdb files are used for debugging. Building in "Release" mode should exclude these files.
You can also create a setup project within the solution. Using that project it is possible to see a list of included files.
If you make a release build or publish the application then you should have a complete set of assemblies your application needs.
However, it can still rely on assemblies which reside in the GAC (Global Assembly Cache) of your machine. Check the references of your project if you think there are assemblies missing in the bin folder.
To solve this exact problem with our software, we wrote a simple console app that finds all the .vbproj & .csproj files in our projects directory, then changes all of the to Release mode (which does not create pdb files, documentation files etc).
This is then run by the build machine (CruiseControl.Net) before it starts compiling the projects.