If you want to make sure that ClickOnce breaks, just figure out a way to throw an unhandled Exception in the constructor of your application.

Once it shows up on the client, and begins to run, it will barf. Not a normal ClickOnce barf where you get a killer log file to sort through, but a "Windows would like to send an Error Report - does that Float your Boat?" type of crash.

I figured that out because I had a couple of files that I wanted to 'embed' with my application - media files, and an XML manifest that were just added to my project in their own folder, and had the following attributes set from within the properties pane:
Build Action: Content
Copy to Output Directory: Copy Always

Problem was, the .xml file simply wasn't being copied out to the ClickOnce deployment. Big honkin' 600KB .wmv files were going down fine, but not a pidly little 100KB XML file.  And since my application was using that file to deserialize some objects in memory upon startup, my app barfed.

No idea WHY that file woudn't deploy when the others would.

But I went into the Properties | Publish | Application Files dialogue, and sure enough, the .xml file - for SOME reason - was set to Data File (Auto), while everything else was set to Include(Auto). So I set my .xml file to Include and everything was up and running again.

Apparently the 'Auto' action for .xml files is to treat them as Data Files - which... for some reason means that they won't get deployed unless you mess with them.

Moral of the story: you may want to add Try... Catch functionality to your ClickOnce constructors to do something like MessageBox.Show(ex.Message) in order to stop them from crashing so hard that Windows has to step in and take over.