So I have a Windows Forms app that uses an encrypted connection string for the database.
Every quarter we change the database password, but the vendor only upgrades this app maybe every 12 or 18 months. So because of this, the "appname.exe.config.deploy" file that is hosted on the clickonce webserver would have our new password--but the hundreds of desktops would still have the old .config file with the old password because the verision has not changed.
I know I can delete the %userprofile%\AppData\Local\Apps\2.0\ folder (deleting potential unrelated click-once apps in the process), but we are talking hundreds of desktops and that's not really feasible here.
I would like to know if/how I can tweak the .manifest or whatever in order to "fake" the clickonce to think it needs to re-install. I can't imagine I'm the first one with this issue but I've found nothing satisfactory in my searches so far.
Thank you.
Unfortunately install\reinstall process initiating when no application installed or version has changed.
I don't understanding, why so important having old one ClickOnce version, because your clients will make update process anyway.
If new copy installation is fine for your clients, then you can set new "Application instance name". Your customers launch will do new instance installation of your application. I'm really don't know how to change this name from Visual Studio or Mage.exe, but you can download my utility from second download link here. [Choose] your application folder -> [Update] action -> Add any prefix for [Application instance name] field value (for example "_1") -> [Build] + [OK].
Anyway, version increment is the best solution for you.
Related
I have a webpage that offers an installer which adds an registry into user's computer based on the clients that the user has access to.
The installer is quite simple. It reads from its app.config, gets the client key and downloads configuration file that is used to create the registry.
Here is the thing, I use ClickOnce to deploy the app. The main logic of the installer remains the same, the only different thing is the app.config key. If the user has 5 clients, I have to publish 5 times since I separate different installers by setting different publish/install urls like below. BTW, I will have to define different Assembly Name too:
It's definitely not a good solution.
Is there any better ways that I can configure the installer to accept this parameter from the webpage, or other better ways to automate this process and then reduce the publish times?
Looking forward to any suggestions!
Thanks!
What I finally done is to write a powershell script, modify related parameters in csproj and deploy them. But I failed to copy those deployed files to remote server(aws). If anyone has any experience on that, you're more than welcome to share your thoughts!
I know this question has been asked lots of times but mostly I couldnt find the answer I was looking for.
How do popular applications update themselfs ?
I found some libraries that update applications but mostly they just replace all the application files. This way my Updater would need to download around 200mb everytime.
Also ClickOnce is used a lot but this in my oppinion is an ugly way to update and install because the GUI is not really fancy and you can't even specify where to install the application.
I know some applications also replace the installer and just run the new one to deinstall the old version and install the new one but that cant be that right way...
So how do Programs like Mobirise, Discord or Teamspeak update themselfs ?
I have a have made a POS Solution(C#), working in 4 Shops.
This is what i've done to give client side updates.
Used Google Drive to upload installer file + a text file mentioning installer version, once uploaded each time the programe starts up it downloads the version text file from Google Drive, if it doesn't match the current version of the software which the clients Has, Messagebox Prompts a newer version is avaliable. Client then can click Upgrade and it will download the installer file, once downloaded software exits completely calling a python script which will Run the installer file.
This is not the best way but it works, becouse Google Drive has its own file version history which makes it easy for me to keep track of updates i send.
Hope I Helped <3
You can design the application to be patchable.
Patching is not a hot flavour in windows world.
I have an application that I want to share on my company's network share. It's a .exe with some .dll's.
We have ~40 users who will need this program. We want it to autostart with the computer.
The problem rises when we need to update the application. Because some of the users might have the application running we cannot delete the .exe and replace it with a new one...
Some say I should use .NET "ClickOnce", but it would'nt work with autostart, right?
What would be the best way to do this? Have a seperate .exe that copies the application to the users temp-folder and then run it from there?
I have the same setup. I have the exe as read only. This way I can replace the .exe and make it read only again. When the user restarts the application it has the updated version.
You can set it read only by right clicking -> properties -> check read only.
To auto start it, just add a shortcut to the start up folder.
This question already has answers here:
Why does rename a loaded .net assembly work?
(3 answers)
Closed 5 years ago.
We are trying to push updates to multiple servers at once and my manager has found that it is possible to rename running .exe file. Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
I guess I need to clarify, He doesn't expect the old copy to magically update, he just expects them to keep running the old copy until they open the exe again, in which case it will then open the new one that has the name of the old one.
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed. On my machine I have yet to be able to get it to work even in a loop.
My first and main question is this: Is it ever acceptable to do this. Should renaming a running executable ever be a valid scenario?
Secondly, if it is a valid scenario then how could one reliably do this? Our current thoughts are try a bunch of times using File.Move (C#) to do a rename and if it doesn't work then write out to an error log so it can be handled manually.
An airplane mechanic and a surgeon meet in a bar. The mechanic says "you know, we have basically the same job. We take broken stuff out and put new, better parts in." The surgeon says "yeah, but you don't have to keep the plane flying as you're making the repairs!"
Trying to update an application by moving files while the application is running seems about as dangerous as trying to fix an airplane in flight. Possible? Sure. Greatly increased risk of catestrophic crash? Yep.
If the application you are updating is a managed application, consider using ClickOnce Deployment. That way, the next time someone runs the application, if there is a new version available it will be copied down and installed automatically. That's much more safe and pleasant than trying to mess with an application while its still running.
No, this is not acceptable. Do not do this. This is not a valid deployment mechanism. This should have been yours or his first clue:
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed.
And it won't work, anyway. His theory is quite wrong:
Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
Specifically, the copy in memory will not be automatically replaced with the new executable just because it has the same name. The reason that you're allowed to rename the executable in the first place is because the operating system is not using the file name to find the application. The original executable will still be loaded, and it will remain loaded until you explicitly unload it and load the new, modified executable.
Notice how even modern web browsers like Chrome and Firefox with their super fancy automatic, in the background, no one ever notices that they exist, updaters still have to close and relaunch the application in order to apply the updates.
Don't worry about shooting the messenger here. It's more likely that your customers and your tech support department will shoot you first.
See number 1.
In our organization, we solved the problem of Updates by having two release folders say EXE_A and EXE_B. We also have a release folder called EXE which only has links ALL of which points to either to EXE_A or EXE_B from which the user runs the applications.
When we publish a new version of the program, we publish it to the folder that is not referenced in the links and then update the links (EXE). In this way, you do not get into exceptions that users are holding the application / assemblies. Also if a user wants to run the updated version, all he need to do is close / re-execute the link in EXE folder.
If you use Windows Vista/Server2k8 or newer you could use mklink to create a symbolic link to the folder containing your application and start the application out of the "symblic linked folder" and then at the update create a new folder, e.g. "AppV2" and change the SymLink to that folder, so the next time the user restarts the application he starts it out of the new folder without noticing.
Renaming open files is ALWAYS a bad choice!
But in general I would think of a better deployment strategy anyway, because if you need to use such "hacks" it is always a messy situation. I don't know your application, but maybee ClickOnce would be a point to start, because you can configure it to check for updates on every start...
I'd like to release some updates for a WinForm program, but to date I have simply released an all-new compile. People have to un-install the old version and install the new version.
EDIT: I'm using an auto-generated InstalWizard. It preserves my file strucutre and places the [PrimaryProgramOutput] in a particular directory. I forget what this is called.
I bet there's a way to get around this, but I don't know what it's called. As you may guess, searches for "updates" "new version" "install" and the other obvious things I've tried have generated an impressive number of irrelevant results. >_<
I suspect this process has a particular name, which should point me in the right direction, but if it doesn't please link to a tutorial or something.
I see from the tags you are using C#. Visual Studio can create Setup projects for these kind of tasks. The setup projects als contain a property RemovePreviousVersion, which will remove a previous version if the versioning of your setup is correct and the GUID of the application stays the same.
See this link for more information:
http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
ClickOnce deployment is a great solution most of the time...
You can deploy to the web and when ever your users start the application it will check for updates and automatically update the application if there is a new version available.
It can also be configured not to update automatically but only to notify the user that there is a new version available and allow the user to control the update process.