By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,948 Members | 1,975 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,948 IT Pros & Developers. It's quick & easy.

ClickOnce

P: n/a
Repost from dotnet.general (no response), and OT but I hoped somebody
might have a clue...
I have a handful of ClickOnce installs that work fine almost
everywhere... however, on some machines it simply does nothing! These
are regular VS2005 ClickOnce "publish" deployments, signed with a
valid certificate.

The client correctly detects the MIME, prompts the user, downloads the
files, etc - and the system deployment log (temp internet files) is
clean - i.e. no errors or warnings - goes to completion.

If I grab a copy of the deployment folder, remove the .deploy
extensions and run the exe, then everything is fine - it just simply
doesn't run via the manifest. Even Main() {MessageBox...} simply does
nothing. The exe flashes briefly in the process explorer, but is then
gone, with no eventlog / crashdump etc, and no MessageBox.

Any suggestions as to where to look next?

Marc
May 17 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Just a huge guess: Security policy (caspol)?

"Marc Gravell" <ma**********@gmail.comha scritto nel messaggio
news:eK**************@TK2MSFTNGP06.phx.gbl...
Repost from dotnet.general (no response), and OT but I hoped somebody
might have a clue...
I have a handful of ClickOnce installs that work fine almost
everywhere... however, on some machines it simply does nothing! These
are regular VS2005 ClickOnce "publish" deployments, signed with a
valid certificate.

The client correctly detects the MIME, prompts the user, downloads the
files, etc - and the system deployment log (temp internet files) is
clean - i.e. no errors or warnings - goes to completion.

If I grab a copy of the deployment folder, remove the .deploy
extensions and run the exe, then everything is fine - it just simply
doesn't run via the manifest. Even Main() {MessageBox...} simply does
nothing. The exe flashes briefly in the process explorer, but is then
gone, with no eventlog / crashdump etc, and no MessageBox.

Any suggestions as to where to look next?

Marc
May 17 '07 #2

P: n/a
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
May 17 '07 #3

P: n/a
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_Deployment_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\Classes\Software\Microsof t\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\ClickOnceErrors.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**********@gmail.comha scritto nel messaggio
news:uQ**************@TK2MSFTNGP03.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
May 17 '07 #4

P: n/a
Yup; but those logs are clean as per OP

Oh well...

Marc

May 17 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.