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.
Related
I'm using visual studio community 2013 on Windows 10 home for development of a c# AI application. The application works fine if it runs from the development folder, however, because I want to be able to keep the application running while modifying and compiling existing code, I copied the exe and DLLs (1 exe, 2 DLLs, debug build) to a different folder to be run from there.
When run from the copied folder, the exe (only the exe) is deleted when I close the application. Moreover, I cannot copy the exe back from the development folder because I get "Destination folder access denied". This happens only when I try to copy the exe (other files, including exes with different names, can be copied OK) and I have to reboot to be able to copy the exe back.
I'm not sure even where to start to debug this. Things I tried:
- Check the recycle bin to see if the deleted file is there: no
- Run process monitor to see if the exe name is running anywhere: no
- Exclude the copied folder from antivirus (AVG) scan/check: didn't help
- Make sure I'm running as administrator: yes
Have you checked the folder permissions on the destination directory? This sounds pretty much closer to a folder permission issue.
Since you haven't mentioned the Windows version in question, I am going to be generic on the approach. Try this:
Go to folder properties -> Security -> Advanced -> Owner -> Edit
Add ownership to your user account
Apply changes and retry copying files as see if it still prevails
** Also, in folder permissions, try giving full control to your user account
I am trying to develop a feature in my app, which will enable users to check for the updates and, if new version exists (on the FTP server), it will download all the new files and run the new instance of the application.
I have successfully managed to check for an update (by comparing XML files) and downloading the zip file from the FTP server into a temporary folder. However once I started copying the files into the main folder, application suddenly crashed becuase all the dll's I have tried to copy were already in use.
I came with two approaches that are possible:
1) rename all the files under the main folder to: originalname.dll.bak (append .bak to the end of their name). Then copy original files and restart application. Upon opening new instance (updated exe file), the very first thing we do is that we erase old files ending with .bak. One problem with this approach is, that I can easily rename currently running process to include .bak, yet I am not sure if I can do the same with the dll files (have not implemented this solution yet)
2) Create an external app (e.g. console app), which will be executed from the main application whcih will handle the update process. Upon opening this external updater, my main app will immediately close so that we can assure that copying of the new files will be without a problem.
I have not done any of this before therefore any comments & suggestions will be more than welcome. Also shall shall there be any better way how to handle the update process, I would be more than happy to implement it.
I am using C# with .net 3.5
I am saving my program data in a file under: C:\Program Data\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data")
and then I reinstall the application, and ran it.
The strange thig is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\Program Data\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin priviliges instead of getting: "C:\Program Data\MyProgramName\fileName.xml" I get "C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml"
and indeed there was a file that existed from the previous installation (that I obviously didn't delete ,because I didn't know it existed).
So apparentlly there is some virtual path to the file under program data.
EDIT :
I found out that after deleting the old file in the virtual store, my application is suddenly able to find the correct file. (I didn't make any changes in the file under Program Data.
My question is:
why is it happen.
How can I prevent it from happening
Thanks in advance
Do you actually have to write to the per-system Program Data folder instead of the per-user Application Data folder(s)?
You might want to take a look at Environment.GetFolderPath and the following Environment.SpecialFolders:
Environment.SpecialFolder.ApplicationData - data folder for application data, synchronized onto domain controller if the user profile is roaming
Environment.SpecialFolder.LocalApplicationData - data folder for application data, local and not synchronized (useful for, for instance, caches)
EDIT:
Tested on Windows 7 x64, non-administrator user.
var appData = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
var myFolder = Path.Combine(appData, "MyApp");
if(!Directory.Exists(myFolder)) Directory.CreateDirectory(myFolder);
File.WriteAllText(Path.Combine(myFolder, "Test.txt"), "Test.");
This does what is expected, ie. writes into C:\ProgramData\MyApp\Test.txt. As far as I can tell (Administrator mode Command Prompt), there's no UAC virtualization going on either.
Double edit:
I guess what's happened is that at some point an Administrator user has written the files into your ProgramData folder, and as such, UAC file system virtualization kicks in and redirects the non-administrator writes into the VirtualStore.
Does your uninstaller run as Administrator? If it does, you might have to check both the VirtualStore path for the user who initiates the uninstall, and the actual file system path for program data to remove. I'm not sure if there's an official way to do this, though...
I found the reason for the bug.
the application is trying to take ownership on the file and then the other file is created.
I removed that line and now everything works just fine.
I've never burnt a visual studio program to a CD before. I've made a setup project with all my program files, and it works fine. Do I simply need to burn the following installer files onto the CD and give it to someone?
The installer is a folder containing:
-DotNetFX35 (Folder): Contains .net requirements for my program.
-WIndowsInstaller3_1 (Folder): WindowsInstaller-KB893803-v2-x86.exe
-setup.exe
-My Installer.msi
Sorry for the seemingly easy question. I'm double checking as I have one CD and an impatient employer.
Thanks!
You will need to add an autorun.inf if you want autorun to work. Put the contents of the install folder at the root of the disk, create a simple text file called "autorun.inf" at the root of the disk and add the following contents:
[autorun]
open=setup.exe
This will instruct the operating system to run setup.exe when the disk has inserted (and consented to it).
There are other tricks you can do with autorun.inf too. As many have mentioned in the comments, the best way to test this is by creating an ISO and testing it, or buying a stack of blank disks. They are pretty cheap these days.
If you don't care about auto run, then you can put anything on the disk itself, it's just content, the user would just need to go into the contents himself and click setup.
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.