Assuming i have an executable called mainprogram.exe and another called Update.exe. What I want to acheive is: when Update.exe is started, it replaces mainprogram.exe with, for example, C:\Program Files\MyProgram\mainprogram.exe. The point is to include the executable that needs to be replaced in Update.exe so it would be an all-in-one solution.
Also note that I can't create Update.exe that will download the mainprogram.exe from internet, it has to be already included in Update.exe.
In building:
copy UPDATE.EXE to be embedded into the MAIN.EXE as a resource
At runtime (update time)
drop UPDATE.EXE from resource to the hard drive
start UPDATE.EXE with appropriate parameters (command line arguments, depending on the situation)
have UPDATE.EXE try to delete common file that MAIN.EXE will create and leave it opened
when MAIN.EXE exits, handle to the file will be released, allowing UPDATE.EXE to continue doing what it should - replace the MAIN.EXE with new version
start MAIN.EXE from UPDATE.EXE
(optional) delete UPDATE.EXE from MAIN.EXE, as you don't need it for now.
You can use .NET resources and access them via Properties.Resources. If you want to copy the content of a resource to the hard disk you can use System.IO.File.WriteAllBytes.
Adding and Editing Resources (Visual C#)
What you want is called a "Setup Project". This will allow you to bundle any files necessary for such an update to be deployed in such a manner.
Here is the MSDN link for doing this.
In a nutshell, you are creating an installer package, but you can limit the functionality of the installer to replace the designated files only.
You could just use an SFX archive - works pretty much like a setup program and "self extracts". Many archiving programs allow it, or you could just write a setup project in .NET which will do the same thing if you're having to include all the files in the updater anyway.
Related
I've recently coded a little program to determine numbers in a picture and it is reliant on two libraries I've used. (DLLs)
Since my target computer is not allowed to install programs due to security reasons, I need to create a portable .exe.
.NET is installed on the target computer but for some reason VS still does not include the libraries I've used in the exe but instead creates an application folder with a setup.exe, some .DEPLOY files and an application manifest.
I am new to VS and .NET in general so this question could be easy to answer, but I'm asking since I've found nothing useful on StackOverflow neither on google.
You can simply build the application and copy your bin/Debug folder along, but that would still mean you need multiple files.
In order to merge all references into the executable, use ILMerge. Here is some help calling ILMerge.
Basically, after building, you should do something like this:
ilmerge /target:winexe /out:SelfContainedProgram.exe
Program.exe ClassLibrary1.dll ClassLibrary2.dll
There is just one file you need to send along.
One way to do this is to build your application in Release mode (You can pick from Debug or Release in the drop-down). Then go to C:\Projects\[ProjectName]\[ProjectName]\bin\Release (The location of your project folder may vary). You'll see a bunch of files but all you really need are the DLLs, executable, and the config if you used one. You won't have to do any setup if you keep the necessary files in the application's folder, just copy them all to a folder on the target computer, create a shortcut if you want then you're good to go.
You can just copy all your assemblies into any folder you want. Simply chose "Build" from within Visual Studio and copy the files from bin/debug to your destination-folder.
However you have to ensure that all (relative) paths (if existing) still work as you cannot be sure where the user of your program copies the files to.
One simple way could be to use 7zip Packager, it doesn't need any installer. However, VisualStudio method might be more reliable.
I encountered the same issue recently. ILMerge suggestion above is no longer supported. I found Fody.Costura as a modern replacement.
Currently I have 2 exe files. app.exe and updater.exe. When app.exe finds out that there is new version available it runs updater.exe, which downloads and replaces it.
I'm wondering if it's possible to build updater.exe into app.exe. On app start it should check if there is updater.exe in the directory and if it's not than extract it. Any help appreciated.
You can integrate updater.exe as a resource into app.exe. The following SO post shows how to extract it at run-time:
Embedding an external executable inside a C# program
Note that, if your application is located in the default application directory (C:\Program Files, or, more generally, %ProgramFiles%), you will not have permissions to create a file in the same directory (which is a good thing). Thus, you might need to extract updater.exe into a temporary directory that the current user has write permissions to (such as Path.GetTempPath).
When I'm understanding you correctly you need to pack you updater.exe into you app.exe as ressource. Extract it, when App.exe starts.
But I can tell you, this idea with replace is bad. You should choose a MSI package to deploy your application.
For traversing and listing directory contents, see http://msdn.microsoft.com/en-us/library/system.io.directory.aspx
For accessing your embedded resources, see http://msdn.microsoft.com/en-us/library/xc4235zt.aspx
For writing binary data to disk, see http://msdn.microsoft.com/en-us/library/system.io.binarywriter.aspx
For running an exe from disk, see http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx
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 am using a custom action during install to write a text file to my install directory. When I uninstall, that file is not removed nor is the corresponding install directory. However everything else is uninstalled properly.
I understand the reason that WIX cannot uninstall this file using the uninstaller, I'm just wondering what's the best way to call into a "clean up" action on uninstall which in which I can manually delete the directory/file?
You could include a RemoveFile element in whatever component your text file is most closely associated. When that component is uninstalled, the text file will be deleted as well.
<RemoveFile Id="CleanUpLogFile" On="uninstall" Name="log.txt"/>
You could install an empty text file and then have the custom action write to the file instead of creating it.
In general, I would suggest to stay away from custom actions as much as possible (they can get quite messy when dealing with install, uninstall, patching, repair, etc.) You may want to consider having your application itself configure the file on first run or have an additional configuration app that is executed on first run.
you can always run a console app for example that removes the file through code. You would just add that project only to the uninstall custom actions.
Out of curiosity what is the nature of the text file? In similar situations where the text file is an install log I'd recommend logging to a temp directory or a location that is not under Program Files (such as the Program/AppData folders - C:\ProgramData\Manufacturer\ on windows 7 for instance).
This approach bypasses this issue completely eliminating the need to create custom clean up scripts or actions.
I have a quick question regarding debug and release in VS 2008.
I have an app i've been working on - its not yet complete but the bulk of the functionality is there. So basically i'm trying to give a copy of it now to the person helping with documentation - just so they can have a play and get the feel for what i've made.
Now the question is how to provide it to them. I was told to just copy the .exe out of the debug/bin folder and put that onto USB. But when testing, if I run this .exe anywhere else (outside of this folder) it crashes. I've now worked out why this is:
var path = ConfigurationManager.AppSettings["PathToUse"];
var files = Directory.GetFiles(path);
throws a null reference, so that App.config file is not being used. If I copy that file in with the .exe it works again.
So actually my question is regarding the best way to manage this situation. What is the best way to provide a working copy to people, and, is there a reference on preparing apps for release - so everything is packaged together and installed in a clean structured folder heirarchy?
If you want to be safe grab everything in the debug/bin folder. If you use the drop down in VS to change to release and then compile the project, there will be fewer files in the release/bin folder because many debug related files are not included.
If there are third party DLLs you are referencing, like if you downloaded log4net or something like that, then you can simply put them in the same folder as the exe. This is called side-by-side deployment, and in my opinion is the simplest and easiest to test.
You can search for XCOPY deployment to learn more about what you are trying to do.
You can take another step of compressing the bin folder into an archive like a zip file to make it easy for the user to extract them, or you could use a tool like WIX or NSIS to create an installer to extract and copy the files.