The server unexpectedly closed the connection

[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

 

[Gregory A. Beamer]

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.

 

[Joseph Geretz]

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

 

[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

 

[Jeff Dillon]

Why do you need the pdb on the server??

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

 

[Joseph Geretz]

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

 

[Jeff Dillon]

Not beside the point at all. Have you EVER seen a dll that large? You are
doing remote debugging on a production site??

 

[Gregory A. Beamer]

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.

 

[Joseph Geretz]

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.

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

 

[Joseph Geretz]

Not beside the point at all.

Whose point? Yours or mine?

 

[Jeff Dillon]

Neither. The doctors point:

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

Doctor - Then don't do that

 

[Joseph Geretz]

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...

 

[Jeff Dillon]

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.

 

[Gregory A. Beamer]

Hi Gregory,


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

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.

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.

 

[Joseph Geretz]

Hey Gregory,

It has to do with the connection type. And, with most people, it will not
be a problem.

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