System.Net differences

[Ross]

Greetings.

This problem has cropped up while I was writing a file uploader piece
to a much larger project.

The uploader compiles in both 1.1 and 2.0. In 2.0, the file will
successfully upload; in 1.1, I get a familiar error: "Unable to write
data to the transport connection."

Why would the uploader work in one version of .NET but not the other?
Somewhere along the line, implementation of System.Net.Connection has
been changed.

All my code does is create a new HttpWebRequest using
WebRequest.Create, assign the appropriate headers, open a file stream
to the file, then write the output of that stream to the input of the
HttpWebRequest.

Anyone have any resources on the topic?

Thanks,
Ross

 

[Jon Skeet [C# MVP]]

All my code does is create a new HttpWebRequest using
WebRequest.Create, assign the appropriate headers, open a file stream
to the file, then write the output of that stream to the input of the
HttpWebRequest.

Anyone have any resources on the topic?

I don't, but if you show us your code (preferably in the form of a
short but complete program that demonstrates the problem) we may well
be able to spot the bug.

Jon

 

[Ross]

I don't, but if you show us your code (preferably in the form of a
short but complete program that demonstrates the problem) we may well
be able to spot the bug.

Jon

I'm not sure it will matter... Apparently all of our locations have
the 2.0 framework and I can upgrade the entire project to 2.0... it's
still aggravating when our friends in Redmond do something without
documenting it (or at least making the change documentation hard to
find).

At any rate, I think I've found the original example that I've modeled
(read: shamelessly plagiarized) my work after:
http://www.c-sharpcorner.com/UploadFile/gregoryprentice/DotNetBugs12062005230632PM/DotNetBugs.aspx

Thanks.
-Ross

 

[Jon Skeet [C# MVP]]

I'm not sure it will matter... Apparently all of our locations have
the 2.0 framework and I can upgrade the entire project to 2.0... it's
still aggravating when our friends in Redmond do something without
documenting it (or at least making the change documentation hard to
find).

Well, it could well be that your code previously worked but wasn't
guaranteed to, and they made a change which wouldn't affect anyone with
genuinely correct code. However, it's hard to say without seeing the
exact code.

At any rate, I think I've found the original example that I've modeled
(read: shamelessly plagiarized) my work after:
http://www.c-sharpcorner.com/UploadFile/gregoryprentice/DotNetBugs120
62005230632PM/DotNetBugs.aspx

Well, a short but complete example would still make life a lot simpler
- otherwise we don't know whether you introduced the bug, or what.

 

[Ross]

Well, it could well be that your code previously worked but wasn't
guaranteed to, and they made a change which wouldn't affect anyone with
genuinely correct code. However, it's hard to say without seeing the
exact code.


Well, a short but complete example would still make life a lot simpler
- otherwise we don't know whether you introduced the bug, or what.

--
Jon Skeet - <[email protected]>
Web site:http://www.pobox.com/~skeet 
Blog:http://www.msmvps.com/jon_skeet
C# in Depth:http://csharpindepth.com

You can download the complete snippet at that link, I'm fairly
certain.

The only things I modified were some return values - the project
expects the total number of bytes transferred back. (Our original
library, written in C++, used wininet to accomplish this, so I tried
to model the C# version a little more closely to that. I prefer my
code changes to be of minimal impact as far as method definitions
go.) I also tossed in some debug logging, just in case.

I'll put together a condensed example later today that exhibits the
same behavior. I didn't have the moment yesterday... at work, the
only guarantee I have is more work, and my internet at home has been
on the fritz.

-Ross