I have a Winforms Dot Net 2.0 (VS2005) project that I have been publishing to a server as a ClickOnce project for some time now. A couple of days ago I found I was unable to publish anything to any server. After the successful build, VS output simply freezes on

Connecting to 'http://<server name>/<app name>/'...

There are no warnings or error messages that I can find. There is no eventual timeout. The server is definitely up and running and I have made no radical changes to this program. As I said, I have published versions of this particular program at least 20 times. I've also tried publishing test programs with identical results.

I've had our support people do a major virus scan on my hard drive and they swear it's clean. (It did seem that the ability to publish came back momentarily when the Internet advanced optionswerereset to default but that did not last.) Support also claims there's nothing wrong with the office network. I've also tried uninstalling and reinstalling VS without any luck. There is nothing particularly exotic about our PCs, servers, or network, although my own machine has been in use for over 2 years.

(At this time it appears that a co-worker's computer may have just started acting up as well. Too soon to tell.)

Suggestions? The only thing left to try is probably reimaging my machine.

If logging into the server and publishing works, then you are definitely having some kind of communication problem with the server.

I don't know if you're on an intranet in a corporate environment or deploying across the internet. If you can log into the server, can you log in while publishing remotely and see if any files are coming across? I can usually do that if I'm ftp'ing the files to our server.

You're probably going to need to go back to whoever supports your network and ask them to sniff it and see if they are even seeing your connection request from your machine when publishing the application.

You can also get a network sniffer like Charles and run it on your machine while publishing and see if it's sending anything across.

RobinDotNet

No, definitely no request for credentials. It's sitting in front of me now, just waiting. If memory serves, I've left it that way for as long as 10 to 15 minutes with no change. Granted I do get impatient.

A coworker has suggested an alternate theory that I'm about to look into. He suggested that there might bea limitation with the server on the number of connections allowed. In the past this particular server has been notorious for limiting the number of Remote Desktop Connections at one time. (Not that I necessarily think this is related but I haven't had that problem for some time. Also I can't publish to any server, not justthat particularserver.)

Also I should mention that given this problem I have been logging into the server via RDC, and publishing the program to itself with it's own install of VS2005. That works without problem.

If logging into the server and publishing works, then you are definitely having some kind of communication problem with the server.

I don't know if you're on an intranet in a corporate environment or deploying across the internet. If you can log into the server, can you log in while publishing remotely and see if any files are coming across? I can usually do that if I'm ftp'ing the files to our server.

You're probably going to need to go back to whoever supports your network and ask them to sniff it and see if they are even seeing your connection request from your machine when publishing the application.

You can also get a network sniffer like Charles and run it on your machine while publishing and see if it's sending anything across.

RobinDotNet

Thanks but I am increasing convinced that my main problem is an old seriously fouled up machine that needs reimaging.  It appears that due to my repair attempts, I've also lost the ability to edit web projects.  There is simply too much going wrong with this thing. 

(In all honesty I may have given the wrong impression earlier.  This machine is not particularly 'exotic'.  It's running Windows XP Pro.  Unfortunately it's running an official company image of Xp Pro that may be somewhat non-standard and may or may not have a few problems.  i.e. It wasn't designed with programmers in mind.  But it's what I'm forced to use.)