The server unexpectedly closed the connection

  • Thread starter Thread starter Joseph Geretz
  • Start date Start date
J

Joseph Geretz

Visual Studio 2005:

Why do I get this error when publishing my web application?

....
Connecting to https://host.domain.com/app/...
Publishing folder /...
Publishing folder bin...
Unable to add 'bin/AppUtils.pdb' to the Web. The server unexpectedly closed
the connection.
========== Build: 5 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========

Thanks for your advice,

Joseph Geretz
 
The PDB may be too large. You can avoid publishing them by not having them
created in the first place. You will have to move to a release build and/or
specify not to create them.

--
Gregory A. Beamer
MVP: MCP: +I, SE, SD, DBA

Blog:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think Outside the Box! |
********************************************
 
Hi Gregory,

Thanks, that makes sense. This PDB is by far and away the largest file.

Followup: Is there a definition for 'too large' and can this be adjusted per
server?

Thanks!

Joseph Geretz
 
BTW, I publish the same application to a variety of servers. On some this
file succeeds, but on others it fails. Is the max upload file a configurable
value, and if so, where can I set this?

Thanks!

Joseph Geretz
 
Why do you need the pdb on the server??

Joseph Geretz said:
BTW, I publish the same application to a variety of servers. On some this
file succeeds, but on others it fails. Is the max upload file a
configurable value, and if so, where can I set this?

Thanks!

Joseph Geretz
Click to expand...
 
Remote debugging?

But isn't this question a bit beside the point? What is going to happen when
I have a large DLL file which needs to be deployed?

I'd like to know please where the parameter is defined for the maximum size
for an uploaded file.

Thank you,

Joseph Geretz
 
Not beside the point at all. Have you EVER seen a dll that large? You are
doing remote debugging on a production site??
 
The problem comes with network issues. There is not an actual "too large"
that can be named. What is most likely happening is you are timing out
before publish is complete.

A better way is to publish locally and then migrate the files to the server,
rather than have VS do it for you. Then you have complete control over the
deployment. When VS 2010 comes out, unless something changes, there will be
even better deploy options.

--
Gregory A. Beamer
MVP: MCP: +I, SE, SD, DBA

Blog:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think Outside the Box! |
********************************************
 
Hi Gregory,
The problem comes with network issues. There is not an actual "too large"
that can be named. What is most likely happening is you are timing out
before publish is complete.
Click to expand...

Perhaps. I didn't realize that the publication process is so brain-dead,
that it can't accommodate large files. Our own application has been passing
large (multi-meg) files via HTTP since WSE 2.0. It never occurred to me that
Visual Studio Publishing would have difficulty with this.

Oh well. FTP works.

Thanks for your advice,

Joseph Geretz
 
Neither. The doctors point:

Patient - Doctor, doctor, my arm hurts when I do this

Doctor - Then don't do that
 
You might want to think about finding a new doctor. You'd be amazed at some
of the new therapeutic techniques. Of course if you're happy to stop moving
your arm, as long as the pain is alleviated, then hey - suit yourself.

It's a good thing you're not a software developer...
 
I am a software developer, at a very large company. Largest?

I am open to suggestions when I am going down the wrong path. Sign of a
professional!

Hey lighten up, I'm just messing with you. I hope you get your issue figured
out.
 
Joseph Geretz said:
Hi Gregory,


Perhaps. I didn't realize that the publication process is so brain-dead,
that it can't accommodate large files.
Click to expand...

There is a trade off. FTP, by its nature, is more prone to corruption when
it temporarily loses connection. Not as much today, as the early days, but
still some danger. WebDav and other upload methods die instead of allowing
corruption. Each has its strengths.

Personally, I do not use tools like Expression or Visual Studio to upload. I
find them too costly. Much better to publish locally and then upload with
something that I can move the bits over myself. With VS 2010 and the One
Click Deployment, I might change my mind.
Our own application has been passing large (multi-meg) files via HTTP since
WSE 2.0. It never occurred to me that Visual Studio Publishing would have
difficulty with this.
Click to expand...

It has to do with the connection type. And, with most people, it will not be
a problem. I would imagine Microsoft has huge pipes when testing these
things. I have never had an issue, but I have never relied on the publish
feature to publish to an ISP, except in testing how the feature worked.

--
Gregory A. Beamer
MVP: MCP: +I, SE, SD, DBA

Blog:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think Outside the Box! |
********************************************
 
Hey Gregory,
It has to do with the connection type. And, with most people, it will not
be a problem.
Click to expand...

Hmm. I've bumped up against this problem when publishing to servers on the
local intranet. No bandwidth issues here. Are you sure it doesn't have more
to do with a WebDav or FP Extensions *software* limitation when handling
large files?

Thanks,

Joseph Geretz
 
Back
Top