I've wrapped up version 1 of my desktop application and it's ready for deployment.
Just to test things out, I grabbed the contents of the /debug folder and copies that into a folder of the target machine and the application works.
I'm sure this is not the correct way to do this.
I've created a Visual Studio Installer project and created that as well. My question is, do I have to set something similar to ASP.Net's debug=false, when deploying an application?
Thanks for the suggestions.
There are several deployment options of .NET applications. Your approach is often called "xcopy deployment" and is a simple copy of all included files.
Typically you don't copy the content from the debug folder. Instead you change the "Solutions Configuration" combo in Visual Studio from debug to release, compile the application and copy the files from the "Release" folder instead.
When creating a release build of your application the compiler applies more optimizations to the code to create a more efficient executable.
There are other methods of deployment. Here are some that creates different kinds of installers
ClickOnce (Right click on your project in solution explorer and choose "Publish")
Installer project (creates an MSI installer)
WiX (creates MSI installers too, is more cumbersome than an installer project, but more flexible
etc.
The benefit of creating an installer is that it is usually simpler for an end user to run an installer than it is to copy a loose bunch of files. An installer can automatically create an icon on the start menu, make sure the correct version of .NET framework is installed etc.
If you only want to run your application on one or at most a few computers it is probably not worth the extra work of creating an installer.
I would do the following when creating a "release candidate" of your app:
Create a branch or tag in your source control repository identifying a particular build as the source of the release candidate. A branch is nice because it allows you to make changes necessary to release the source that you don't want in your dev environment.
Set up the Release build configuration of your app. Among other things, yes, this does ensure the DEBUG compile constant is not set, so anything that is conditionally compiled based on that constant will not be. Default behavior is also to optimize the code (faster runtime, not debuggable) and to not generate PDBs.
Build the installer. Ideally, the output of the installer should go somewhere else than the main output of the primary project.
Run the installer (doing so from its build location is fine). It should execute with no errors, and produce what you expect.
"Smoke test" the application as installed. Basically, run through some basic operations that do not modify the data layer it works against, that will verify there are no major problems with the app possibly caused by a missing DLL or incorrect connection strings/app settings.
Copy the installer to a thumb drive of sufficient size, and try the same installation and smoke test on a "virgin" computer that does not have VS installed. Ideally, it should mimic the environment of the target machines as closely as possible.
For one, you shouldn't be deploying the Debug assmeblies. You should build in Release mode. http://msdn.microsoft.com/en-us/library/wx0123s5.aspx
I've never used the Installer projects, but I tend to stay more towards web and console stuff. Hopefully someone else will have a more detailed post :)
Use a Setup and Deployment project. This way your application will make sure user's have required libraries. It will also download the required .net version if it is not installed.
And always release the "release" version and not the debug version. Copy/Paste from debug folder will not work in call the cases and its not the right way to release an application.
Also, if you don't want someone reverse engineering your code, you might want to use Dotfuscate.
Related
I am struggling with a issue of making one installer dependent upon other.Suppose i have a setup project Through which, i use to make MSI(or setup) of my c# application for deployment on windows machine. Now suppose i have another project whose MSI(or setup) is generated by another setup project.
Now what i want to make is that when my first setup is run than it will first check for whether second MSI(or setup) is installed or not. If its not installed on target machine then it first set up will run and install second setup, once second set up is properly installed then installer of first continues and completes the its installation.
I can't figure it out how can i check whether second setup has installed or not. i.e how to make second installer dependent upon first installer. I am using visual studio 2013 and the project which i am deploying is c# application
First time i am dealing with making setups for application deployment so may be my way of asking may not be good. Thankyou!
In general that is not possible by means of MSI only since you can't run two MSI installers at the same time. You'll need to use some external solution: a self-made script, InstallShield wrapper etc. The only thing you can do within the MSI is to check that a prerequisite application is installed and if it's not - abort the installation.
Yes, you need to use a packaging tool that either offer out of the box support or you will have to write your own code for this.
You have quite few options here:
-InstallShield
-AdvancedInstaller
-Wix
What you are trying to achieve is known as prerequisite or runtimes required by your application.
As J.Tribbiani mentioned in his answer the solution you need is to use a professional tool like Advanced Installer or the others, to configure your setup as a prerequisite. This is the standard procedure for your requirement.
Here is an example tutorial of how to do it with Advanced Installer:
prerequisite configuration
Or a video of configuring an optional prerequisite, i.e. which the users could choose to skip (let's say if they have an equivalent alternative or want to manually install the prerequisite)
Disclaimer: I work on the team building Advanced Installer
Now I have a completed program, that needs to be deployed with some files. I would like to ask, if it is possible to deploy the program without the use of ClickOnce or other external tools, with the minimum amount of required files?
The program will run on a server, and will be updated locally, but since the program is installed per user, does that mean if I log in to the server with my user, a person that uses the direct path to the program will not find it? It also makes maintaining the program slightly more annoying, because when changes come, the current maintainer will have to always navigate to the xyz folder to edit one config file. How do I publish the program without ClickOnce or other tools?
Your options include:
Click once (which you don't want)
Visual Studio installer Projects
WiX Toolset
Other installers ...
Write an installer on your own (wouldn't recommend)
Just put the exe (and other needed files) in some directory and launch the program
Put the exe on a shared location and launch from there
You can redistribute as a set of files. However I would not recommend this approach. You force the person who deploys your program :
Choose location for the files
Remember this location when time to uninstall comes.
Handle updates and version management
Restore program functionality if any of the required files will get damaged.
You can use VS Setup project template, here's tutorial
Alternatively you can use free Wix installer, it has a bit of a learning curve but provides much more power to the developer.
You can do perMachine install both with VS setup project and with wix.
I have two separate projects/solutions. One is an ASP.NET web app and the other is a console app that runs as a WebJob on Azure. These two separate projects/solutions share some common projects' DLLs.
We work on these shared projects through the web project's solution in Visual Studio and when done, I copy and paste the DLL's into the bin folder of the console app.
When I compile the console app, I notice that the shared DLL's revert back to a previous version. I know this because I see the Date Modified dates of those shared DLL's. The moment I compile the console app, they go back to previous versions.
Why is this happening and how do I prevent it?
You definitely should not drop assemblies into output folder by hand as they will be overwritten from whatever location build takes them from. If you have to do it manually - copy files over original location. To debug - enable verbose logging for build and carefully check where assemblies are copied from.
Automated solution integrated with the build is better approach.
Standard solution for sharing assemblies between project is NuGet. As most basic solution you can just use file share to drop packages. Check out guidance for continuous integration build system you are using as there is probably recommended nuget source (i.e. package feed in VSTS).
I have a WPF application that is going to be installed on several client PCs. I'm using InstallShield Express Edition as the deployment tool for that.
I've created a different project(DLL) to keep track of the software installations. Basically is a stand-alone C# project that reads, writes and does some validation checking in the Windows Registries, and can be integrated in other WPF applications (this project/DLL is going to be useful for other Apps).
What I want to do is to create an .EXE file to register the installation. This .EXE is not used in the main WPF application, but uses the .DLL that I've just talked about above.
I've managed to do that by creating a different solution with a single Console Application project, and referencing the necessary DLL's.
But what I really want is to create it as project within my Main App Solution, and when I do that no .EXE file is generated other than the Main App executable.
Is there anything I can do to get the 2 .EXE files (Main App and InstallationRegistration) or is the way I'm currently using the only way?
This is more a nuisance than a problem, but still... it will be a better way to keep track of this small module in all the different Applications I've developed.
Thanks
Are you saying the Console EXE is not created as part of the build/run of the solution?
Or the Console EXE is not created as part of the InstallShield deployment project?
If you are referring to building Console EXE as part of the build/run of the solution:
Generally, when you hit F5, Visual Studio builds only those projects you designate as Startup and their dependencies.
You will have to explicitly build that Console App or the Entire Solution.
You can designate it as one of your Startup projects if you want it to be built everytime you hit F5; or specify it as a dependency of the MainApp project (that's a bit of a cheat but it gets the job done).
After trying for a few different ways I got to that DUH!!! moment.
What happened is that VS was creating both .EXE files for the Main App and the Console Application, only with each one is in their respective Debug/Release Folder
For Example:
Main App -> C:\Projects\MyApp\MyAppUI\bin\Debug\MyAppUI.exe
Intallation Control.EXE -> C:\Projects\MyApp\InstControl\bin\Debug\InstControl.exe
NOTE: C:\Projects\MyApp is the solution folder.
It kinda makes sense they are on their own folder, but on the other hand, there should be an option in VS to choose where we want to send all the solution's .EXE
Hope it helps someone in the future.
By default, all intermediate compilation artifacts are placed in the obj folder under a given project in the solution (so far I am not aware this can be changed).
For project outputs they are, by default, put under bin\Debug or bin\Release depending on your Build Configuration.
This can however be changed from the Project's Properties; specifically the Build tab has an "Output path" option for you to specify the build output location.
This has to be done on a per project basis but I generally create a SolutionDir\bin folder under the Solution root and direct all project output paths to SolutionDir\bin\Debug or SolutionDir\bin\Release as the case may be. This has the added advantage or reducing the total size of SolutionDir by avoiding multiple copies of output assemblies in large solutions with complex interdependencies between projects.
Does this help?
How can I deploy a C# Visual Studio 2005 project so that I can run the application in another system? My project has a few dependencies and files that have to be integrated while deploying the project.
What is the best way to handle this?
You need to know what dependencies you have.
you need to have .Net framework installed
you have to explicitly install all dependencies that you used from the GAC on your target machine (some 3rd party components)
and then you just need to copy files from your \bin\Release folder
install all services, etc. if you have any
In the simplest cases only copying files should be enough.
Have you looked into ClickOnce deployment?
It's far from perfect, but for projects without a huge amount of overhead, it's generally good enough.
What kind of project?
Assuming it's a regular winforms application, just copy everything from either the obj\debug or obj\release directory to the new computer. Then run your executable
You can right click on the project file in visual studio and publish to a different location. This will build the site and copy it to the specified directory.
Also, if you need to do anything extra during the build, you can specify custom build actions on the build tab of the project's properties.
EDIT: now that I see you added that it's a windows application my answer doesn't matter. I'd try adding a setup and deployment project in visual studio to handle installing/deploying your windows application.
You more or less have three options (maybe 4?) as I see it.
Windows Installer
ClickOnce
Just distribute
the exe itself
In your particular case I would suggest ClickOnce as long as the project is not massive with too many dependencies.
For other alternatives.
The right answer depends on many criteria.
The simplest way to deploy is by copying files. Just put your .exe, the dependent .dll's, and the .config file in a directory and copy it onto the target machine. It's simple, but there are many restrictions to this approach:
It assumes that the target machine has the right version of the .NET framework installed
It assumes a certain technical competence on the part of the person installing the software.
The installation won't do basic things like create start menu items.
Publishing the program for ClickOnce deployment addresses a lot of these issues, but it's got its own set of limitations. I haven't used it much, so there are probably more than these, though these alone are pretty significant:
Programs are installed into the ClickOnce cache, not the Program Files directory.
If your program does anything outside of the ClickOnce sandbox, you have to deal with security elevation and code signing.
You can create a VS Setup and Deployment project and build an .msi file to install the program. The most obvious drawback to this is that it's complicated: .msi files can do many, many things, and the Setup and Deployment object model is complex, with documentation that is, let us say, fanciful. But there are things you can do with .msi installation that you can't readily do with other approaches, including (and certainly not limited to):
Cleanly uninstall the program through Add/Remove Programs.
Provide an actual UI for installation that lets the user decide where to put the program.
Support scripted installation via MSIEXEC.
Install components besides the program, e.g. databases, COM objects, etc.
Put components in the target machine's GAC.