Can not use ClickOnce publish on .NET 4.0 application from Visual Studio 2012

Question

I installed Visual Studio 2012 and went to go publish one of our applications, that is targeted at the .NET 4.0 framework. Due to the setup on these machines, we c

Answer 1

Visual Studio 2012 breaks the ClickOnce installer, that's if you even got Visual Studio 2012 to update your application without telling you that it is no longer supported.

If you managed to upgrade your solution like you have, you'll find that ClickOnce actually publishes fine. It's only that the prerequisites fail to install therefore making the installation fail. If you still have a Visual Studio 2010 copy of your code that has never been touched by Visual Studio 2012 you can still build via that copy even if you update the code with Visual Studio 2012-written code via your source control. As long as that build stays untouched, it will continue to work, but if Visual Studio 2012 gets its hands on any of the ClickOnce files on that copy specifically, it will simply fail to find dependencies.

I for one decided to leverage off the fact that it still publishes and built a custom tool which can install and run any ClickOnce application as long as it can build. It can install to any location, elevate if needed, install any listed prerequisites (developer controlled), and create the desktop and start menu entries, which then run an updater that does a smart update as ClickOnce would do (only update necessary files to avoid excessive bandwidth usage). I have also built in an update source picker while in a debug environment.

This requires only that two EXE files be placed into the publish folder and you install from the third-party installer, not the ClickOnce ones. This give me a lot more functionality (I can make it do what I want, multi-threaded installer/updater, downgrade capabilities for developers to roll back) and freedom to change the updater (theming) or how the install gets done.

For those that see that my execution order is "Fake exe shortcut" ---> Updater ---> exe, you'll notice that would actually break pinning, because you'd pin the updater, not the EXE file, so I made the application run only with an argument of "/updated", if it wasn't present, the application itself must run the updater EXE file present in the same folder (which only shows if there are files to update), which then updates and starts the original EXE file again with the correct command argument. Pinning now works as you only open the EXE file. (This also gives the capability to skip an update by putting the command argument into the TargetPath, and best of all the end user knows nothing as it's a background progress and the installer is professional and branded).