Tried to see if the fusion log shows something.
The following is from
http://msdn2.microsoft.com/en-us/library/aa480721.aspx.
The title is Administering ClickOnce Deployments. At least sounds good.
"
Dealing with Launch Errors
ClickOnce is highly reliable; however, in rare instances the application may
fail to install or launch correctly. When these situations arise, it is
helpful to have a log to diagnose the problem.
Whenever a launch failure occurs, the end user will get an error dialog like
the one shown in Figure 10. If they press the Details. button in that
dialog, they will get a deployment log for the failed deployment. The log
includes information such as the URLs used to launch the application, and
specifically what caused the failure.
Figure 11 shows the error log summary for an installation that failed due to
an authentication issue.
Whenever a user reports that they are having trouble getting a ClickOnce
application to launch, the first troubleshooting step is to get them to copy
the information from the error log and have them send it to you for
analysis. The vast majority of launch failures can be diagnosed from the
information in the deployment logs.
ClickOnce log files for each installation are written to the WinInet cache
(the Temporary Internet Files folder), for both failed and successful
deployments and launches. These files are just written as text files to the
Internet temporary files cache, and you can harvest information from there
directly if you are troubleshooting a persistent problem on a client
machine. These files are unfortunately named with obfuscated file names that
make it fairly difficult to identify which log file belongs to which
application. You will also have to sort them out from the hundreds or
thousands of other files that end up in most users' Internet caches. The
naming convention for these files is the prefix System_Deployme nt_Log_XXX,
where XXX is the obfuscation. The best way to deal with these is to clear
the cache, reproduce the problem, and then copy the log files out of the
cache for analysis.
Another option is to set a custom log file location. When you choose to do
this, all errors are written to a single file in the location that you
specify, and each activation appends its log entries into the end of the
file. So this approach can give you a more easily analyzed running
commentary of multiple launch attempts.
To set this up, under the registry key:
HK_Current_User \Software\Class es\Software\Mic rosoft\Windows\ CurrentVersion\ Deployment
Add a string value named LogFilePath, and set its value to a fully qualified
path to where you want the log entries written (i.e.
C:\temp\ClickOn ceErrors.txt). Once you do that, all errors will be written
there. I would use this more as a diagnostic and troubleshooting aide rather
than as a normal configuration. Note that when you set a log file like this,
there is no longer any separation of entries, and the entries cannot be
purged using the normal cleanup process of the internet temporary files
cache.
"
"Marc Gravell" <ma**********@g mail.comha scritto nel messaggio
news:uQ******** ******@TK2MSFTN GP03.phx.gbl...
Possibly, but how to find out since there is no spew? It *should* get its
security from the publication, so I'm not sure ;-(
Marc
