Is there any way to place code (C#) that will be executed after ClickOnce installation, without running the application?
I saw Microsoft's 'custom installer', which is a nice way to say "why don't you create an installer application", which I prefer not to (I want my users to have a single - well, double - click and that's that).
Any ideas will be appreciated.
ClickOnce applications run when installed - so you could essentially just bootstrap your own application.
You could either put some code at the start of the main entry point. Or, my preferred approach, you could create a second wrapper application. You would make the wrapper be the app installed by clickonce and install the real exe along side it. In the wrapper write your custom code and then when you're done launch and real exe using the Process class.
Related
I wrote a DLL (with a COM interface) and wonder if I can use ClickOnce to deploy it on end-user machines (to be called using CreateObject("My.DllClass") from the user VBasic app. All the documentation that I've read for ClickOnce (and the abortive attempts that I've made) seem to indicate that a real app (exe, etc) is required for ClickOnce -- it can't deploy a single DLL (and some txt files) and get the DLL registered for COM use on the target machine.
Q1. Is my understanding correct?
Q2. Is my best alternative to learn the Wix Installer?
Thank you
Q1: Yes, your ClickOnce application must have at least one launchable executable file. It's minimal requirement. But you can add any .net executable file there.
Q2: Yes/no. I will try to describe some things for you here. It'll let you make a right decision in your choose. Here is my point of view your task if you gonna choose a ClickOnce technology.
Abbreviate: ClickOnce application = Your.dll + dotNet-Some.exe
At the first you need to know a ClickOnce application locating in Users\[CurrentUser]\AppData\Local\Apps\2.0 after get installed by user. You can't effect on location, so if your client PC have more then one users, then second one must install your application for your self again. As me know your COM assembly must be registered by regasm.exe, there for your Some.exe can on launch register your dll by regasm.exe or some WinAPI functionality, so executable file won't be useless in this way.
Major question is update process, you must track your clickonce build number at the first, and for update operation user must launch your Some.exe for check and now workarounds from here. If this update process if fine, then you need re-register your assembly again (because clickonce add new folder for updated assembly) and user will be ready for use your class.
In the case of MSI package you have full control of install process, but you need always deliver this packages to your clients. Wix is good, if you are .NET developer take a look on WixSharp - let you create installer much more faster and have a lot of examples
If you don't gonna publish your ClickOnce application from Visual Studio then you can use Mage.exe / MageUI.exe for ClickOnce application preparation or use my builder utility from here second download link.
I hope what i said was a bit useful.
I want to create a simple autoupdate that downloads the new version of my software (in a temp folder), runs the installer (I'm using Innosetup) which will take care of closing my application and then, after the setup is complete, I would like to remove the installer file.
What's the best approach to do that?
I saw there are a number of libraries that take care of everything but I have written almost all the code used to check for updates and I'd just need to be able to run the installer.
Thanks a lot.
You can use the NAppUpdate framework to achieve that quite easily.
Check this out: http://www.sjurvarhaug.com/nappupdate-to-automatically-download-and-execute-installer
I have asked this exact question on the Flexara forum, but got no response up to today, so I want to ask it here.
We currently have a InstallScript project which runs fine. The resulting setup can be made unattended/silent fine.
In this setup we have some features and invoke a number of third-party installations (that are a prerequisite for running our software).
However, we have customers that want an MSI file and therefore we resorted to the Basic MSI project type.
The setup is made without too much hassle (I'm fairly new to InstallShield) and I can generate a .exe and .msi from this project.
However the only issue I have left is invoking one of the third-party installers.
That third-party installer (made with NSIS) on its turn invokes another installer which is MSI based.
This results in having error 1500 - the fact that you cannot run a msi type installation while another is running.
I've tried scheduling the CA (that are used to invoke the third-party installers) as the first action and as last, but no success.
Before resorting on the more unorthodox scenarios (like creating a task on Windows Task manager that runs after our installer finishes, or at the next reboot and forcing a reboot - which our customers don't like) or a scenario that we don't bundle the 'faulting' installer (we really like to be able to hand over a single intaller and not multiple), I'd thought I ask your input.
I've tried searching for solutions everywhere on the internet, but either I'm failing due to wrong keywords or I just didn't stumble on the right post yet.
Are there any options left for us to create a single MSI installer that is able to invoke this third-party installer (which invokes a msi installer on its turn)?
Since an EXE bootstrapper is not acceptable, there is only one solution:
store the prerequisite installers in Binary table of your MSI
create some custom actions which extract them from this table and launch them
schedule them in InstallUISequence, for example right before Progress dialog
use searches to detect if the prerequisites are installed or not
condition your custom actions with the search results
Basically, you need to launch them during the installation UI. It won't work if you launch them during InstallExecuteSequence.
I don't think the basic MSI project supports this, but it may be supported by more advanced project types. Other setup authoring tools offer direct support for this.
You can try InstallShield's "Chained .msi Package" feature.
Dozens of Q&A entries (all but one in stackoverflow!) that I found got close to this question, but didn't teach me what I needed. I have what should be a nearly simple installation: a Windows service and an associated tray icon application. They install fine with the standard VS Setup project. After the files are installed, I need to present a dialog to the user to set some parameters in the service's exe.config file. In that dialog, the user should be able to abort the installation. I've tried two approaches to the Custom Action process and ran into a wall with each when it comes to making the installation roll back.
Approach 1: An exe for the Custom Action, run at Commit time.
This sort-of works. The application returns a non-zero exit code and the installation rollback occurs. What I don't like is that:
When the app exits (after the user selects to Cancel), the installation displays an error message saying that there was a problem with the installation and the user should contact the vendor. Since that's not the case, I'd prefer a more correct message ("Installation canceled by user") or no message at all.
Both of the project outputs (the service and the tray app) have to be listed under all four Custom Action sections or my dialog won't appear. Instead, an error appears about a missing InstallState file and the installation always fails. Intuitively, this seems wrong.
Approach 2: An Installer as the Custom Action, run at Install or Commit time.
This is cleaner to me (only the one item listed in the Custom Actions), but getting the process to roll back is worse than Approach 1. It seems that I have to throw an exception in the overridden method (Install/Commit), which then gives me several error dialogs before the rollback occurs, and then the rollback doesn't always uninstall the service.
What is the cleanest way to make this work without going to WiX or similar options?
The simple answer is don't use VS Installer Classes. They have a number of fundamental design flaws. I suggest you look at Windows Installer XML's ( WiX ) Deployment Tools Foundation ( DTF ) instead. DTF is a far superior hosting model / interop library for your managed code and outputs DLL's that are compatible ( from an MSI perspective ) with C/C++ custom actions. They can be consumed as Custom Actions by any MSI authoring tool, not just WiX installers.
Deployment Tools Foundation joins the WiX toolset.
Deployment Tools Foundation (DTF) Managed Custom Actions
I recommend this approach:
create a custom installation dialog which asks the user about your options
use the installer properties set by this dialog to modify your service configuration file (you can use a custom action or the XML support of another setup authoring tool)
This way the information is gathered before the install and the user can also abort the install without problems.
This approach is not supported by Visual Studio, but it can be done with free or commercial setup authoring tools.
If you want to stick with a custom action, you can try this:
make sure your custom action is deferred and doesn't run during commit (commit means that the installation was performed and there's no rollback)
use a Win32 DLL to show your custom dialog; this way you can return ERROR_INSTALL_USEREXIT (1602) so a friendlier user exit dialog is shown instead of the fatal error dialog
My company is developing an application that has a dependency on another of our applications. That second application already has an Inno Setup installer.
So I think I'd like to bundle the second application's installer within the Inno Setup installer for the first application. But I'm not sure how to go about that properly. Does anyone know the "right way" to do this?
I found this: Inno Setup Knowledge Base—HOWTO: Install .MSI files. I assume the technique could be used for a nested Inno Setup installer. But I have a couple of questions about the fine details:
How could I make it so if the first application is uninstalled, the second is also uninstalled?
Is that a sensible thing to do (automatically uninstall the second application), or should I leave it to the user to do that manually?
If the user tries to uninstall the second application while the first is uninstalled, should I somehow detect that and give a warning? How could I do that?
For the level of uninstaller functionality you are talking about, I suggest you get familiar with pascal scripting in Inno Setup (if you are not already). It offers incredible customisation, but has the caveat of making your projects a lot more complex.
To answer your third question first:
Yes, you should do this. In order to do it properly, you need to add this functionality to the uninstaller of the second application (i.e. the one your app is dependent on). See Uninstall event functions in the Inno Setup help. You need to check in that uninstaller if your app is installed (by checking if HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\SecondAppName exists, for example) and in that case show an additional warning.
As for your second question:
If it is remotely possible that your customer wants to continue using the second app, even if he decides that he wants to uninstall the first one, you should offer him the choice. I would do this with a seperate wizard page in the uninstaller for your app, after your app is uninstalled.
And finally, your first question:
You need to determine the name (full path) of the other app's uninstaller exe. You can retrieve it from the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\SecondAppName\UninstallString. For executing it from a script in the [CODE] section, see Exec in the Inno Setup help.