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?
Related
I'm trying to create exe/msi for my solution
it contains the following Projects
ActiveDirectoryEngine: library used to implement AD operations
ADService: windows service - performs the work in the background
CryptographyEngine: library used to encrypt/decrypt data
TerranovaActiveDirectoryHost: Dashboars/win form to manage/check the service's status
SyncToolSetup: the setup project "it only targets TerranovaActiveDirectoryHost"
Here is the contents of the Setup project:
I tried the same steps for different Solution, with ONLY one windows forms application, and it worked fine, but it looks that it doesn't work when I have more than one referenced projects.
The install and Uninstall options are not enabled
Update:
all the previous projects are referenced in the Win forms project, so am I targeting the right one when creating the exe/msi?
The only project with the Install option is the setup project. Other projects in the solution do not have install option just because there is a setup project as part of the solution.
References in a non-setup project (such as a C# build) are not automatically included in a setup project. References used to build code are not necessarily things that need installing on the target system. The setup will try to help with dependencies, but it's unreliable, and only a guide. For example, your Application Folder view contains some files that are part of the .NET Framework, and you definitely don't install them because they are installed as part of the standard .NET framework install.
The setup project must be told what needs to be installed on the target system. There are generally two ways of doing this:
Selecting project output as input to the setup project. This can be rather indeterminate because it's not always obvious what files are included, or what to do if the files need installing to different locations.
Add the files that you know you need one at a time by adding them in the File System view of the directory they need installing into. Typically, executables go into the Application Folder (defaults to Program Files..), data files to User's Application Data, shared files to Common Files folder, some assemblies to the GAC and so on.
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 developed an app in WPF using VS 2015. I created a release build for this app. But when I copy this build to any other folder outside it starts properly but does not launch API methods i.e. API hitting methods are not being called or my app is not responding. As it runs properly in debug mode I can't find the reason. Can anybody help?
You should to copy ALL dll's from the Release folder. Your exe file is dependent on configuration (yourprogram.exe.config) as well as other assemblies (dll's from your folder). Without these dependencies the application cannot run (because that is how .NET works). All classes and methods are wrapped in dll and if you run your program without some dll, then it means that there are no necessary classes or its methods which worked with other dll's in your Visual Studio.
You can use ILMerge to merge all dependencies into single .exe file to simplify distribution of your application.
More detaiils on ILMerge can be found here: ILMerge on CodeProject
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.
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.