I basicly wanna do this because it seems the clickonce installer cache sometimes gets corrupted or applications data files get corrupted.
So basicly what i want to do is have a extra start menu thats either calls a batch file or my app with a command line args.
Was hoping this could be done with clickonce, simply because i do alot of updates to the app. It has a very small install base ( less then 50 ppl ) and 2 click to publish is nice.
You can't add additional start menu short-cuts with ClickOnce beyond the standard application and help shortcuts. You can do whatever you want in the code of your application as long as the user has the security privilege to do it. So you could just write code to create a shortcut.
What are you going to have your shortcut do? What's wrong with just removing the application with Add/Remove Programs?
Related
I have a Win UI 3 app that checks it here is a new update available, it dowloads the installer, but is it possible to execute such installer without closing the app?
How execute the installer from the code?
How to handle tha installation from within the app without closing?
Is it to complex? or should I just have the user do it manually?
NO. The executable is in memory (and may have locked files or resources). In order to get an update it will have to be relaunched. If your code is modular, think plugins, these could be updated in place.
Most applications launch a helper app then close themselves, because Windows usually blocks changes to executable files that are in use.
The app might pass its own process ID to the helper app so that it can wait for the process ID to disappear before attempting to update the file.
If not, the helper app might scan the process list for the EXE name, and pop up a message asking you to close the main app. It repeats this until there are no instances of the EXE in the process list.
I have a small application which is a single executable. For context, this is deployed to Thin Client computers and runs automatically at boot. Users do not have the rights to close this application.
However, I need the application to be easy to update. I can't write my software to do any kind of auto-update routine, because these stations often have a write-blocker* which must be disabled beforehand.
The simplest solution as an administrator is to copy the new EXE over the old using the various tools provided with the Thin Client, or Group Policy / scripting where required. The update doesn't have to be instantly effective - the next reboot is fine.
The problem with this is that, of course, the executable is in use and can't be overwritten. What's the best way to allow this to happen? Load the software completely into memory and run from there? Do some kind of routine which copies the exe to a temporary folder and then executes it with a command line switch so it doesn't endlessly loop?
*This may have caused some confusion. These are Windows XP / Windows 7 Embedded machines. For the most part they work like normal computers, except file system writes are transparently redirected to a cache drive. On a reboot, all changes are completely reverted. A normal script to update the machine would go something like:
Disable Write Blocker
Reboot Machine
Copy Files
Reboot Machine
Enable Write Blocker
Reboot Machine
However, my application will autostart after every reboot as there's no mechanism to inform it. As such, when the scripts get run the executable is still in use.
You might be able to use Windows' MoveFileEx with the DelayUntilReboot option.
To do this from C#, see this answer which shows how to set up the call to the Windows API.
Note: I think the call needs administrator privileges.
You could make of use of something called Shadow copying assemblies. Search the net, you'll find lots of examples (also on SO and Codeproject).
Obviously the application can only update if your write protection is disabled. Are you using FBWF or EWF? You might even exclude the application folder from write protection.
I am making program to automate software installation in C#.
I hooked mouse & keyboard to listen events performed while setup installs..
First Admin needs to install program which need to be mass installed on connected clients.
So admin runs Server which hooks mouse & keyboard events while perticular installation of software & admin selects unique screen region for screenshot to later matched on client installation process to determine whether specific form has arrived, only then simulate key or click else wait until screenshot matches..(eg.next form came after clicking on Next Button only then simulate click or Keystrokes)
Correct me if i am wrong..plz..
1) Well i know same thing can be possible with Group policy object but it can only install msi packages not the exe setups... so they need to be converted to msi first.. i googed free programs for this conversion but none are free. ( All free programs are just simple exe to msi converters but that converted msi still ask clients something while installing if any error condition is there) & ofcource u need to purchase windows Server licence for domain controller pc's this will not possible for Indian Schools,Cybercafe's,Charitable Trusts..
2) There is no free program to do this task perfectly AutoIT,AutoHotkey tries it well but not every time it succeeds.
3) White Framework on Codeplex is nice but still hangouts sometimes while installing..
So this way is ok? or there is any other way to do this ( i want to automate exe,msi ondemand unattended installation)
Pertaining to #2, you are indeed incorrect. AutoIt is perfectly capable of handling this, in fact one of the basic AutoIt examples is an Installer (tutorial here: http://www.autoitscript.com/forum/topic/82288-installer-creator/)
With a bit of tweaking you could turn that into a great installer, with much less effort than it would take in C#
Maybe if you could tell us exactly what problems AutoIt has been causing you?
I have a solution with a Web Application, Console Application (and Windows Service, but that's probably for another question).
Publishing and keeping the Web Application up-to-date is easy. I simply right-click Publish to publish initially or update the live version.
Currently to "publish" or update a console application I copy the release exe and files over to the live machine. In this way I can use the task manager to run the exe in the copied location.
This smacks of bad practice to me. The problem with doing a right-click, Publish on the console app is there's no easy way for the task scheduler to launch the exe. Additionally i'm not sure what would happen when it came to updating the application. Would the "An update is available" screen just sit there waiting for a user to click ok??
What is the best way of easily publishing and keeping a console application up to date?
Ideally something I only have to do from Visual Studio (2008). I'll need to be able to set up task scheduler and then forget about it (no need to do anything with task scheduler or click through anything when updating).
Automatic deploy of applications partly sounds like Continuous Integration.
You may not be interested in the TDD parts, so you can just focus on the tools that allow you to grab code from your repository (SVN for example), build it and deploy it automatically.
Personally, and based on personal experience, I would do this for backstage environments only, for production I would stick to copying exes manually (and keeping backups, of course!)
Personally for these server side executables I just copy the exes. If you're updating them a lot and you want to ensure that you don't put them in the wrong folder or miss a file you could write a .bat script to do the copying for you so that you can just double click on it.
To be honest if you're deploying a new program so often that this is a major issue for you then I'd say you have a different problem. You shouldn't be making changes to a production app all that often. There might be something that's currently code driven that ought to be data driven such that you can make modifications that you need to your program by modifying your database, config files, etc. and not the code of the program.
I am looking for a way to monitor Windows dialog during a MSI deployment. Here is my situation: we have machines deploying daily MSIs and once in a while, one of them fail and shows a Windows dialog with an error message.
I am trying to find a way to write a script (maybe in Powershell) which will run every minutes and look for a Windows dialog with an OK button. Is there a simple way to do that?
Thanks!
You can depoly a MSI with options to not display a GUI at all.
Using MSIEXEC with the /quiet option.
Deploy via active directory to machines should not have this problem so I'd be interested in how you are deploying the MSI.
Rather than try to click the dialog, is there a way that you can determine the condition that will cause the error, and handle it?
Although you will find some methods for enumerating windows and posting click messages to them, there are some other things that you migth want to consider:
What if an unrelated dialog box appears that has an Ok button? It could cause problems for your users if an "Are you sure you want to delete the contents of c:\" gets auto-ok'ed.
Also, if your setup is running on Vista/Windows7/server2008 with UAC turned on, then your script will have to run with admin privileges, or any click messages will be rejected.
Can I assume that you are deploying updates to multiples machines (and effectively you wish to know if an update was successful?)
If that is the case, would it not be possible to code such that when the deployed software executes, it reports (via email?) the PC name and the Software Version Number?
You could then simply right a script to start the application periodically and then close it as well.
Darknight