Still learning create MSI installer with VS 2008 for our C# application. We have some batch files to create database and tables, after installation we want to delete it because there are sensitive information on them (username, password, ...). My questions are like those:
where should I put those temporary folders/files? (doesn't matter?)
how to delete them after installation? or how to call batch file from installer? I was able to add a custome action to modify app.config file but call batch file should be a different way. (simpler than having a installer class?)
how to guarantee those files will be deleted even something wrong during the installation?
thanks,
Instead of a batch file, which anyone can open and read, consider compiling the sensitive information and commands into an .exe. If you store information in a file on someone's PC, you cannot guarantee they will not copy and retain it.
Ideally, temporary folders and files get installed in the windows temp directory, but you can also install them in your application directory.
You can't guarantee the install will complete or files will get deleted, but you can do the delete (or whatever) as early as possible so they can't install without that deletion, or you can have your app or some other process complete the deletion after the install.
Related
I'm trying to make an uninstaller.
I basically need to be able to remove a directory in the program files that contains the uninstaller.
I was thinking to have the uninstaller create a copy of itself to the temp folder,
then have the uninstaller running from the program folder open the uninstaller in temp and close itself where it continues the uninstall.
Problem is, how do I delete the uninstaller in the temp folder...
Check out: https://www.catch22.net/tuts/win32/self-deleting-executables
He has multiple solutions - but mostly aimed at C++ code.
I am currently trying to implement the "DELETE_ON_CLOSE" method in C#.
A comment to all the nay-sayers: MSI does not solve this problem in all cases. In my case, my application needs to install to a network folder, where any network user can run the app. It also needs to support upgrades and uninstalls from any network workstation - not necessarily the same workstation that installed the app. This means I cannot register an Uninstaller into the Add/Remove Programs list on the local machine. I must create an Uninstall.exe that is dropped into the install folder. MSI does not support that, so I have to write my own.
Even though I agree with everyone saying you shouldn't do that, what you can do is:
Have your program create an executable (and config file) in the temporary folder of the OS it's working on.
Have your program start it as an independent process, then exit.
That executable then calls back the actual setup stuff.
Once the setup is done, the temporary executable can delete the setup files.
Since the only trace of your program is now in the temp folder, it will eventually get cleared automatically.
Everything in Visual Studio seems to lead one to putting data files with the application.The app.config goes there, when I create an .XML data file, there is a Copy to Output property that will automatically copy that file to the exe folder. Howerver, it seems that under Vista and Win7 UAC doesn't want the application to be able to write data to any file in the application directory. So I'm changing my evil ways so that I use the LocalApplicationData folder for files I want to read and write. (I just read the app.config so I'm leaving it alone)
I'm using a VS2010 Visual Studio Installer project to create the installer for this app and I can't seem to find a way to target the folder for my .xml file to the LocalApplicationData folder. I can click on the file and see a Folder property but the dialog only has options for Application Folder, User's Desktop and User's Program Menu. Is there some way to do this in the installer or do I have to write code that checks for the file and copies it over from the .exe folder when it doesn't exist? I figure I'm late to this particular party and there must be a canonical way of handling this.
Also, I'm wondering about debugging, is there something similar to the copy if newer functionality in the build process that will now copy this .xml file automatically over to the LocalApplicationData folder whenever I update it?
The Setup project doesn't expose LocalApplicationData in the Special Folders list. You can use it anyway by doing this:
Add a Custom Folder and set the DefaultLocation property to [LocalAppDataFolder]
I want to make an installer tracker.
If a execute file is a installer program, I will start a process to record the setup process. So I get a setup log after installing.
But How can I recognize an installer file. All installer files have ".exe" extenison. Is there a special metadata in the execute file to tell me it's a installer file.
I know word files have "author", "title" metadata. Maybe a installer file has a "install program" metadata. Anyone help me?
No; an installer is just an executable file (or a script, in case of MSI).
However, you can recognize it by what it does - take a snapshot of the system as it was before, perhaps hook the file and registry operations of the executable, and when it finishes, look at what it has changed.
For example, has it created a folder in Program Files? Has it created an uninstaller entry in the registry? Has it created any services? Etc.
When and MSI is installer/removed/repaired an "msiexec.exe" process will be started by the OS. So this could be another resource that you would want to watch.
As for the file/registry system you could use the OS monitoring API that listen to changes and gives you the desired information.
http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx
In my project I have to create some files and directories into my app folder which is into program files. But in vista it is giving me error that I dont have access to create file.
What should I do now for giving access ? Also it not let me access the registry !!
The program folder is not the place to store application data. There is an %APPDATA% folder for that - you are supposed to store your data there.
Use System.Environment.SpecialFolder and System.Environment.GetFolderPath to obtain the path leading to the correct directory.
Also, you need to differentiate between just creating a folder and putting some files in there (for example during installation) or writing to the program folder at runtime, while typically running under a limited account.
The reason for this difference is simply that installation routines and setups run with elevated privileges under Vista / Windows 7, thus those are allowed to create folders and files there. Still, those files are not supposed to be written to at runtime of your application.
So, what is it you want to do? Write data at runtime, or put some files (i.e. dependencies) in your application folder at a single time? If it's the first, comply with the rules and use the %APPDATA% folder. If it's the second, create an installer / setup routine.
Vista and Win 7 have the Program Files folder locked down so you can't write to it with a basic user account. If you need to create folders there, then you should do it in the installer. Otherwise you can use the user's Application Data folder in their profile.
The only other way is to modify the permissions on the installation folder at install time.
Can you turn the UAC off? Or Login as administrator? The chances are that you are creating the folder in the wrong place.
"Idea to update the new version of application on client machine"
I have read binary data from DB server using WCF, create a zip file with contents, extract the files and update our application bin folder.
I want to validate the process like if everything is fine then update bin or rollback old file.
Can anybody give me idea to validate this process?
Do we have any check sum idea..
Well if you use SharpZipLib to inflate the zip file, there is a TestArchive method on the ZipFile object that will do an integrity check of the archive, and tell you if it's valid.
Otherwise, you can use MD5 to make a checksum on the remote file, and compare it to the downloaded file to see if the content is the same.
Store on the server/web the most recent version of the project that is online. eg: in a version.txt the value "2.1.0", or query the database if you have access too.
Your application running on clients, will periodically read the contents of the version.txt file, then compared against the inbuilt(self) version number.
If a patch or minor release is detected eg 2.1.123, spins out a second app(updater.exe) that will quietly
do the upgrade,
it shall download the updated(preferred zipped) project from server/web.
Stop any running instances.
Unzipping the content.
Backup existing files(rename)
copy/install the new version of the project,
Start the application (when the app is restarted successfully it will delete its own backup file).
if a major release is detected eg: 3.0.0
notifies the user there is a major upgrade
if user accepts, download the installer
runs a full installer update
Does this help?