C# Clickonce Application Prerequisites: Any SURE way to determine the list?

Question

Not that I haven't done any searching, but the result always leads one back to the MSDN recommendations that "all will be taken care of" if you use their Publish Wizard and "publish" your click-once application. And of course nothing is ever taken care of.

Invariably I do this: I make a CD based application, have it as "Create the setup to install prerequisite components" that's the default. Do my publish. And BAM, pretty much 90% of the people who were told "here's my first test version" write back immediately and say "it didn't install" and then we view the details and it's near impossible to ascertain what in the world is the problem. Once the result was that one guy had placed the setup files so deep in a directory structure that was why it failed, this was literally found by accidental web search/lucky peek at a suggestion comment.

Seriously, there's no iron clad way for a developer to say "I can determine exactly the full list of prerequisites; as well as the minimum system for this application", so that they can construct their published click-once application ONCE and once only?

My inclination here is to "check all prerequisites" and then un-check the ones it gripes at me about; like it will say "you can't both pick A and B, or B includes A so that's irrelevant.

It's great that I can customize the list of prerequisites, but since I don't "know" that list; what I'm asking is how I determine that list?

Answer 1

It should be fairly easy to determine your prerequisites. Depending on which version of .net you are programming in will tell you which version they should have as a prerequisite(most likely 3.5/4 at this point). Any external libraries will need to have the DLLs packed in, as those will not be detected by the prerequisites wizard.

You list of prerequisites should be fairly obvious if your the one who wrote the program. Which libraries did you use? Include those that do not have installers, and if shipping on a CD, you might as well include the .net installer for the version you are using in code.

I've seen click-once fail quite a few different ways. One is nesting to deeply, which is typically a rare occurrence. Second is checking the network for updates. I've had issues where click-once won't install if it is set to check for updates on startup, but it can't contact the update server. You'll need to sort that one out depending on your environment. I also saw one situation where a co-worker wrote an app that simply would not install via click-once, it would crash every time. I resolved the issue by correcting some very very bad code, but the app would deploy fine in a ZIP file.

Lastly, does your application NEED an installer? Is it a large package with many dependencies and complex directory structure, or is it just a few files and folders that will happily run from any directory? If it is the latter, you may be better off distributing a ZIP file installer and being done with it. Also, do you plan on making use of the auto-update features of click-once? That is really the only reason I ever use it, and if you don't plan on taking advantage(or can't) it loses much of its appeal.

Answer 2

I found this particular solution. And thank you for answers, they were helpful.

For this case Visual Basic PowerPacks 10.0 was a prerequisite. I don't know why it was a prerequisite because I wrote no VB code. It may be because I chose a custom ICON image. I did try to take it out and the app then installed, but crashed.

The setup was configured to download the installations for anything it needed.

That process was happening, but failing.

We downloaded the VBPP setup.exe from Microsoft, included that with the release folder, and told those who would be installing to run that setup first and then run the setup for our app. That made it work.

Before it was clear that the VBPP install was starting, it asked for acceptance of the EULA. The "install" also looked different than from when we downloaded and ran the VBPP setup.exe separately.