[RESOLVED] Click Once Fishing For Suggestions

I've used Click Once to deploy a pair of applications for well over a decade without issue. Sometime last summer, date not particularly certain, something changed. One of the applications will not install on a new computer, and I haven't dared try the other one.

At first, I thought this might have been a signing issue, and was able to set it aside for a while as that was getting sorted out...or more specifically, my request to sort it out was being ignored, which worked well for a couple months until it didn't work well anymore. I don't really care about the signing on this, so I've been using the temporary certificate for signing the file for all this time. Occasionally, those have gone stale and needed to be replaced, so I thought I'd get a real certificate. Turns out, those are too expensive for something as trivial as this, so I tried a new temporary certificate and this failed as well.

The cause for the failure is a bit mysterious, and somewhat suggestive. I have not done any real study of this since last fall, and I didn't find much then, but the details of the failure mention an invalid username and password. There is no such set of credentials for this program, so that was a bit odd. However, I think I DO know what it's asking for.

I can install the program just fine so long as I am logged into the web server on the computer that I am installing the program onto. The program fails to install with a pretty useless error message on any computer that is NOT signed into the web server. The details talk about those missing credentials, and don't say anything else that looks useful to me, so I believe the credentials it is asking for is the credentials to sign in to the web server, something that should never be required for installing something.

I'll be studying this more over the next couple days, but I thought I'd toss that out there in case anybody knew why my ClickOnce deployment, which had been working fine for years, suddenly wants people to log into the web server to install?

I realize that this is a deficient question, but there's not all that much to go on. That message about the bad credentials is the only error being reported, and the fact that it works fine on computers logged into the web server, are basically the only pieces of data I have to go on, at this point. If anybody has any suggestions, I'd be interested in hearing them.

Can you clarify what "logged on to the web server" means in this case? Authenticated to the web server with a web browser? Connected via RDP?

I'm not an expert at ClickOnce, but assuming you have access to the website's log files, and assuming logging is enabled, I would check to see if there are any 401 unauthorized errors (or other errors for that matter) being logged when an installation is attempted. I'm thinking perhaps some of the installation content has had a permissions change, and a user authenticated to the website has access, but an anonymous user doesn't.

Is it configured to check that server for updates? Not sure whether ClickOnce will check for updates before installing.

It certainly checks that server for updates upon launching, so it probably checks it for installation, but it never gets very far.

Actually, that's not quite true. The first step of the installation is to download the installation package. That appears to work fine. It then does 'something', which is where it fails. I was thinking that might be running the installation package, but it might be checking for updates. It's the failure when checking for updates that alerted us that there was something going wrong.

Quote:

---

Originally Posted by OptionBase1

Can you clarify what "logged on to the web server" means in this case? Authenticated to the web server with a web browser? Connected via RDP?

I'm not an expert at ClickOnce, but assuming you have access to the website's log files, and assuming logging is enabled, I would check to see if there are any 401 unauthorized errors (or other errors for that matter) being logged when an installation is attempted. I'm thinking perhaps some of the installation content has had a permissions change, and a user authenticated to the website has access, but an anonymous user doesn't.

---

What I mean by that is perhaps a bit complicated, and trivial, at the same time. The way we have things set up, we have a bunch of servers on a domain, but our IIS server is not on the domain. Therefore, when I am logged into our network, as I generally am when at work, I'm still not logged into the web server. I almost never need to be, as there is little reason to log onto the web server machine, since it would be pretty unusual for me to even interact with that server in my normal work. On those times when I want to look at something, alter something, or some such, I have to explicitly log into that server. As long as I have done that at some point prior to installing the application, then the installation works. Naturally, I found this out by accident.

Otherwise, that's a good suggestion. I have not pursued that avenue of exploration.

Arrggh. I'm probably wrong about all of this, but I just can't quite say.

As I mentioned, I have used this deployment on a pair of applications. It has only notably failed on one. I had been avoiding testing the other one, because the other one is far more important. If the one that failed could no longer use Click Once, I didn't really care, as there was an acceptable alternative, but the other one would have been a bigger deal. It would only have been an issue for new installations and updates, and those weren't happening, at the moment. I just assumed that if it failed on the one it would fail on the other, so I wanted to solve it one the one that was easier to tinker with. Call these applications A and B, where A is the larger one that I haven't looked at, and B is the smaller one that is manifesting this issue.

This morning, working from home, I uninstalled A from my home computer (I don't use it there, it was only on there for a test from many years back) and reinstalled it. It worked fine. That was interesting. I then tried installing B, which has never been installed on my home computer. That failed, but it failed with a new error message from any I had seen before. The error was that the path was not found. The path it was looking at was the path on the IIS server where the application is located. That's why it was complaining about the credentials. It's not installing from a web URL, it's installing from a file path. If the path is accessible, all is well. If the path is not accessible, it could be that you aren't logged in (the case for most people at my office), or that you aren't even on the right network (the case for me at home).

So, this is looking like a simple setting change, and I have a way to study that superficially, which might even be enough.

More data. I'm not entirely sure whether this is still a deployment issue, but it seems likely that it is.

I determined that the deployment was not trying to deploy from a web site, but from a folder. The folder was on the IIS server, and that's why it was trying to get to the server, which it couldn't do because it lacked the credentials. I fixed that, which exposed a different problem.

There are very few settings for Click Once deployment. It's pretty simple. One of the things you can tell it is the URL for deployment and updates. Call this URL A. If the application components were not at A, I'd get a 404 error, and I'm not, so it is seeing the right thing. However, installation is still failing. What's both intriguing and maddening is that I get different information when I try to install it from within our network and from home (outside the network). I was going to take this question in one direction, but wanted to get the exact wording, only to find that the wording from home is different from the wording at work. Unfortunately, it's a goodly drive to get to work, so I end up with different problems.

What I was seeing at work was that it failed because installation was trying to get some of the components from URL B. There WAS a URL B. It was virtually the same name as URL A. I must have created it at some time, and it differed by only one character (A is essentially foo4bar, while B was foobar). They had the same stuff in them, so I simply deleted B, as it wasn't useful. Even after republishing, the installation insisted on trying to get something from URL B, which never had a reason to exist. I couldn't find any file that referenced B, and it wasn't part of the Click Once deployment that I was able to find. Therefore, my question WAS: Where am I not looking? Why is the installation looking for B when it should be looking for A, which has all that it needs? I must have set something wrong, but I can't find where.

And then I decided to get the actual wording of the message, only to find that the error I get at home is quite different. In the folder at URL A is Publish.htm along with the application manifest file foo4bar.application. What I am seeing at home is the error message "Downloading A/publish.htm/foo4bar.application did not succeed. The remote server returned an error: (404)."

Now, this really isn't my thing, but A/ has both publish.htm AND foo4bar.application. I'm not sure what that / is about, but there is no mention of URL B, as I was seeing at work, yesterday. So, I'm not quite sure if the error message is misleading, or if this is somehow different. I suspect that, despite the error I am seeing here talking about downloading A, it is actually trying to access B.

Any suggestions?

Well, I asked for suggestions, so I'll leave this up, but I found one that might be just a little TOO easy. I can't test it until Monday, but I believe that both A and B are an old domain that we no longer use, but might be still redirecting from, and that could be the whole problem.

Well, THAT wasn't the answer.

The folder has publish.htm and A.application in it. It still results in this error:

"Downloading A/publish.htm/foo4bar.application did not succeed. The remote server returned an error: (404)."

Where is it getting that publish.htm/foo4bar.application from?

it gives me the effect of eisntein asking on a forum asking why xy-z... doesn't work. I'm glad to know people like you exist. thank you.

This is such a weird issue, and hard to study because it does different things in different environments. Just did a bit more testing. For those who aren't familiar with Click Once, you get a deployment page that offers an install button and a launch link. The href for the install button is just "setup.exe", while the href for the launch link is "yourApp.application". The deployment page is "yourURL/publish.htm".

Since the href is a relative URL, I would expect that an href of "yourApp.application" would resolve to "yourURL/yourApp.application". Therefore, this morning, I tried that explicitly...and it worked. The application installed. The href looks correct, and if the page behaved the way I expected it to, then the installation would have worked, as well. For some reason, the relative href resolved to yourURL/publish.htm/yourApp.application rather than yourURL/yourApp.application. It is seeing publish.htm as part of the URL for the site, even though it is clearly not.

I'm not even clear on who is making the mistake. After all publish.htm is just HTML. Viewing the source shows the href looks entirely fine. The launch link is just an <a> tag within a <span> where the href is "foo.application". I would assume that it was the browser that took the href from the a tag and used that to figure out what to ask the server for. I wouldn't expect the server to be doing that, but perhaps it is.

I don't know enough about how URLs are processed to know where to look next.

Back in the day there was a "Base href" tag that could be used to say "any relative href's in this page should use this as the base". Not sure if that tag is even used or supported any more, or in play here, but I thought I would mention it.

If you can post the entire html of the page, or as much as possible if you need to remove some for the sake of privacy, etc., that might help. Also, any linked to .css files or .js files, etc.

I could post something, but it's a simple page made up of nested tables. MANY MANY nested tables. So, it's a long nesting of TD/TR. I don't think there is any js, as it's an ultra simple page: Text in a few blocks, with one link and one button. I wouldn't expect that you'd want to see all the deeply nested tables, but I could supply that. The <a> tags are very simple, the TR/TD all add a small amount of formatting, but nothing much. I'll have to look at it later, as I'm currently on a web meeting, and will be for the rest of the day, but what would be worth looking for? What would be worth looking at?

Quote:

---

Originally Posted by Shaggy Hiker

I could post something, but it's a simple page made up of nested tables. MANY MANY nested tables. So, it's a long nesting of TD/TR. I don't think there is any js, as it's an ultra simple page: Text in a few blocks, with one link and one button. I wouldn't expect that you'd want to see all the deeply nested tables, but I could supply that. The <a> tags are very simple, the TR/TD all add a small amount of formatting, but nothing much. I'll have to look at it later, as I'm currently on a web meeting, and will be for the rest of the day, but what would be worth looking for? What would be worth looking at?

---

When one wishes to identify a malfunction, it is advisable, if one does not have one, to recreate a logic diagram. Sometimes, we manage to solve ONE malfunction, but if it's a logical bug (and not a coding bug) it works, then it doesn't work anymore and it works again .. taking the time to redo the organization chart is the right method.

the empirical method is longer. it works, then not at all, and it works again and so on.

(google traduction)

Right now, all I can offer is there seems to be a configuration problem either with the ClickOnce generated/deployed files, or the configuration of the web server, or some combination of both. But, you obviously already know that, because those are basically the only two things in play.

If you right-click the link that brings you to the wrong URL and choose "Copy Link" and paste it into notepad, is it already wrong? If not, then perhaps some broken redirect is in play. If so, then it points to something in the HTML that is causing the destination path to be built in a weird way.

Quote:

---

Originally Posted by Shaggy Hiker

What would be worth looking for? What would be worth looking at?

---

All of it, by a fresh set of eyes. Something that might explain the behavior you are seeing.

Hmmm, I like what you said there. This was working for years, then sometime in the last year, it stopped working. I can't narrow down when that was very tight, though, because I didn't get any notice until last fall. There were LOTS of significant changes in the few months before this issue was reported to me, most of which I am largely unaware of, so the chance that something was broken during all that is reasonably high.

Unfortunately, I can't provide much of anything, at the moment. I just confirmed that outside the business network, all I get is a 404 on the install link. That much DOES work when I'm inside the firewall. That's how I was able to see the HTML, as the install page would load fine, but neither of the links on the install page were working, as reported. From here, nothing but a 404, so no HTML to report.

I'd like to say that if I can solve that, then the problem will be solved, which may be the case....but I've thought that before with this problem, so we'll see. To be more clear: We'll see next week, because I've done enough driving for this week, and will be working on other things until Monday or Tuesday.

Stay tuned....

Just to clarify, because there can be different URL's in play when inside the firewall vs. outside the firewall, in your case are you going to:


1. http://www.somesite.com/installPath from both inside and outside the firewall

or

2. http://www.somesite.com/installPath from outside the firewall, and either

http://internalServerName/installPath or http://10.0.0.1/installPath from inside the firewall (where 10.0.0.1 just represents the internal IP of the web server)

If 1 is in play, I would be curious if you were to ping www.somesite.com both from a device behind the firewall, and from one outside of the firewall, and see if the IP's match.

In either case, if it works internally and 404's from the outside world, then to me that would point toward some weird issue where the firewall is directing inbound web traffic either to an old web server, or an old web site on the existing web server where that path wasn't valid.

If you have the ability to create a simple test page at some nonsensical path on the site, like www.somesite.com/test1234.htm, and then try to access that new page both from behind the firewall and from outside of the firewall, and it works from behind the firewall but 404's from outside the firewall, then that would rule out everything ClickOnce related (for this newly reported situation) and narrow it down to firewall/web server issue.*

Who knows, maybe there are two web servers in play here, an internal one and an external one, and they are supposed to have their content synced, and that syncing is broken or something like that. From this latest update you posted, the possible causes have grown significantly.

*Edit to add: This is starting to sound like one of those situations where there are several things wonky. ClickOnce configuration still might be in play for part of it...

It is the former. The URL I am using, whether inside or outside, is from a document...cause I haven't copied it anywhere and I certainly don't bother memorizing it.

Well, I think you are probably right, overall. I'll give that test a try. I'm inclined to say that I've done that, and there IS different behavior inside and outside the firewall, but thinking back over it, I just can't be sure that I have removed all other confounding variables, so it is worth doing such a test explicitly to be sure.

Ultimately, OB1 put me on the right path. The suggestion to try some plain vanilla html page was a good one, even though I never actually DID do that. While looking at that, I was surprised to find that the publish.htm wasn't actually present. In fact, a bit of checking with other people showed that everybody else got a 404, whether in the network or outside the network. For some reason, my computer was returning that publish.htm that nobody else found. I didn't think that caching was possible, in this case (it happened over the course of a week while no publish.htm was available for even longer than that, and I felt that I restarted the computer several times in that week), but it's still the most likely explanation for how I was able to get to that publish.htm when it did not, in fact, exist.

Once I realized that, I was able to restore the publish.htm, and the problem was solved.

Ultimately, that's not really the answer, though. After all, the publish.htm WAS there when I started this thread, I had managed to kill it along the way, and hadn't restored it, but it HAD been there when this saga started. I believe that there may have been up to three different issues that all happened at roughly the same time (actually, they were just noticed at the same time, they may have happened over the course of a year, or all at once, can't say which). Over the course of this event (which really began last October, but was dormant for several months in the middle), I believe I fixed various things, but since they weren't ALL the problems, I wasn't able to realize that I had fixed things. Towards the end, here, I got that errant publish.htm, which sent me off down a blind alley.

Therefore, I really have no good lesson to suggest from any of this. It was a matter of looking at the problem from different angles on different computers until all the issues were revealed.

Quote:

---

Originally Posted by Shaggy Hiker

Therefore, I really have no good lesson to suggest from any of this.

---

Success!