4 ms·

"ClickOnce" deployment, which you get for free when you're developing a windows desktop app, does the same thing as far as I can tell. And it doesn't install a

by mullr 15y ago

"ClickOnce" deployment, which you get for free when you're developing a windows desktop app, does the same thing as far as I can tell. And it doesn't install a service on your system; instead you can configure it to check for updates in the background when your app is running, installing them when it's launched the next time. So... what does this offer over the stock solution?

adamsmith 15y ago
I've never used ClickOnce, so maybe someone with more direct experience can chime in! My current project, and my last project (Xobni) both worked with COM components that could not use Reg-free COM for various reasons. Thus, if another app registers the same COM component, and then the user uninstalled that app, we needed to be able to re-register that COM component, which required SYSTEM level privileges in order to avoid a UAC elevation prompt. Services can also be useful if you want to be able to run code when a user is not logged in, or if you want installs to be system-wide. For example, in DesktopBootstrap, installs are for "all users," but if one user disables auto updates or starting up with Windows, it actually asks the service to disable those things for all users. You need a service running as SYSTEM to be able to pull that off, again unless you ask the user to elevate you. Finally, I'm curious about ClickOnce's browser-powered install. I'm not saying it doesn't work -- it might even increase conversion rates -- I'm just curious. I'd love to learn more about what happens with users who are using a non-ClickOnce-compatible browser, and/or who don't have the .NET framework installed yet.
- saurik 15y ago
  ("if another app registers the same COM component" <- why was this happening?)
  - adamsmith 15y ago
    Shared components -- at Xobni in the early days we used a library called Redemption that other addins often used. My latest project includes VirtualBox, which uses COM components that are going to have ID's in common with any other use of VirtualBox. (In the VirtualBox case we could change all of the ID's are recompile, but I'm still hoping to avoid doing that.)
    - saurik 15y ago
      Doing this is like including a /usr/lib/libvirtualbox.so.1.2 in multiple Debian packages, getting irritated that other people's packages uninstall your shared library, and then deciding to write a daemon whose goal is to watch for that file being deleted so you can replace it... in essence: a mistake. ;P AFAIK the way you are supposed to solve this on Windows (if you really aren't in the position to simply think of VirtualBox as a separate project that the user manages using its own Installer) is to use Merge Modules, which track this kind of installation corner case correctly and can be added to multiple MSI files. Having multiple people compiling, and then sharing, the same components eventually causes you horrible problems one day when you find out that one of the users compiled it with a slightly buggy compiler, and didn't notice because they weren't using that part of the library. The core benefit, then, of using Merge Modules, is that VirtualBox is able to distribute an official build of the library that people can submit bug reports to ("didn't work on Windows 7 Home SP2"), despite possibly not having its own Installer. Is VirtualBox simply being annoying in not providing official package manager components? :( Reference: "Each merge module contains unique version information that is used by the Windows Installer database to determine which applications use the component, preventing premature removal of a component. For this reason, a new merge module should be created for every incremental version of your component; a merge module should never be updated after it has been included in an installer." -- http://msdn.microsoft.com/en-us/library/6771e4ch(v=vs.80).aspx http://msdn.microsoft.com/en-us/library/6771e4ch(v=vs.80).as...
- TimGebhardt 15y ago
  ClickOnce doesn't require admin privileges to install software. Each program is installed on a per-user basis under the user's profile. So it doesn't need admin rights to write to C:\Program Files. I'm pretty sure this is how Chrome works as well. As for installing COM components, you can install COM components on a per-user basis as well. The registry keys are installed under HKCU rather than HKLM, so again you don't need admin access. I program .NET client applications for my day job and we use ClickOnce to deploy our software. The software doesn't require admin access to install or use, and we register a COM component for integration with Excel and it all works just fine.
  - adamsmith 15y ago
    Wow that's really cool! I wasn't sure you could register COM classes from ClickOnce. So yes it seems like ClickOnce is great as long as you don't need per machine installs or special powers to eg upgrade the user's .NET version, etc etc. How have you found the .application installer? (vs exe) Edit to add: I was surprised when MS introduced .msi installers! Someone at MSFT is cranking out the installer systems.)
    - TimGebhardt 15y ago
      I actually like the .application format. It's nice because it's just an XML file that the end-customer's computer knows what to do with it. At my company we've actually created an ASP.NET MVC application that dynamically constructs and serves the .application file on a per-user basis. This easily allows us to do canary releasing or beta previews. We're very happy with it, and so are our customers and stakeholders.

by mullr 15y ago

adamsmith 15y ago

I've never used ClickOnce, so maybe someone with more direct experience can chime in! My current project, and my last project (Xobni) both worked with COM components that could not use Reg-free COM for various reasons. Thus, if another app registers the same COM component, and then the user uninstalled that app, we needed to be able to re-register that COM component, which required SYSTEM level privileges in order to avoid a UAC elevation prompt. Services can also be useful if you want to be able to run code when a user is not logged in, or if you want installs to be system-wide. For example, in DesktopBootstrap, installs are for "all users," but if one user disables auto updates or starting up with Windows, it actually asks the service to disable those things for all users. You need a service running as SYSTEM to be able to pull that off, again unless you ask the user to elevate you. Finally, I'm curious about ClickOnce's browser-powered install. I'm not saying it doesn't work -- it might even increase conversion rates -- I'm just curious. I'd love to learn more about what happens with users who are using a non-ClickOnce-compatible browser, and/or who don't have the .NET framework installed yet.

saurik 15y ago
("if another app registers the same COM component" <- why was this happening?)
- adamsmith 15y ago
  Shared components -- at Xobni in the early days we used a library called Redemption that other addins often used. My latest project includes VirtualBox, which uses COM components that are going to have ID's in common with any other use of VirtualBox. (In the VirtualBox case we could change all of the ID's are recompile, but I'm still hoping to avoid doing that.)
  - saurik 15y ago
    Doing this is like including a /usr/lib/libvirtualbox.so.1.2 in multiple Debian packages, getting irritated that other people's packages uninstall your shared library, and then deciding to write a daemon whose goal is to watch for that file being deleted so you can replace it... in essence: a mistake. ;P AFAIK the way you are supposed to solve this on Windows (if you really aren't in the position to simply think of VirtualBox as a separate project that the user manages using its own Installer) is to use Merge Modules, which track this kind of installation corner case correctly and can be added to multiple MSI files. Having multiple people compiling, and then sharing, the same components eventually causes you horrible problems one day when you find out that one of the users compiled it with a slightly buggy compiler, and didn't notice because they weren't using that part of the library. The core benefit, then, of using Merge Modules, is that VirtualBox is able to distribute an official build of the library that people can submit bug reports to ("didn't work on Windows 7 Home SP2"), despite possibly not having its own Installer. Is VirtualBox simply being annoying in not providing official package manager components? :( Reference: "Each merge module contains unique version information that is used by the Windows Installer database to determine which applications use the component, preventing premature removal of a component. For this reason, a new merge module should be created for every incremental version of your component; a merge module should never be updated after it has been included in an installer." -- http://msdn.microsoft.com/en-us/library/6771e4ch(v=vs.80).aspx http://msdn.microsoft.com/en-us/library/6771e4ch(v=vs.80).as...
TimGebhardt 15y ago
ClickOnce doesn't require admin privileges to install software. Each program is installed on a per-user basis under the user's profile. So it doesn't need admin rights to write to C:\Program Files. I'm pretty sure this is how Chrome works as well. As for installing COM components, you can install COM components on a per-user basis as well. The registry keys are installed under HKCU rather than HKLM, so again you don't need admin access. I program .NET client applications for my day job and we use ClickOnce to deploy our software. The software doesn't require admin access to install or use, and we register a COM component for integration with Excel and it all works just fine.
- adamsmith 15y ago
  Wow that's really cool! I wasn't sure you could register COM classes from ClickOnce. So yes it seems like ClickOnce is great as long as you don't need per machine installs or special powers to eg upgrade the user's .NET version, etc etc. How have you found the .application installer? (vs exe) Edit to add: I was surprised when MS introduced .msi installers! Someone at MSFT is cranking out the installer systems.)
  - TimGebhardt 15y ago
    I actually like the .application format. It's nice because it's just an XML file that the end-customer's computer knows what to do with it. At my company we've actually created an ASP.NET MVC application that dynamically constructs and serves the .application file on a per-user basis. This easily allows us to do canary releasing or beta previews. We're very happy with it, and so are our customers and stakeholders.