By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,118 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

Seeking advice on transferring a file via WebMethod

P: n/a
Up to this point, our application has been using Windows File Sharing to
transfer files to and from our application document repository. This
approach does not lend itself toward a secure environment and so we are in
the process of imposing a WebService gateway between our application client
and the repository.

(As a starting point, the WebService won't be a richly featured application
server; business rules are still implemented in the client. But this will
ensure that all access to the document repository is made via our software.
Although the WebMethod below accepts only a single parameter, I'll shortly
be adding authentication parameters to this method to ensure that accesses
to this WebMethod actually originate from our client application.)

Here is the method which I've defined (below). I have two questions, one
which relates to functionality, and the other which relates to performance.

1. I can't get this to work! When I test this I get the following error
message:

Could not open C:\Winzip.log --> Access to the path
"C:\Winzip.log" is denied.

Here's the line of code on which the exception occurs:

FileStream FS = new FileStream(FileSpec, FileMode.Open);

I can't imagine that this is a Windows security problem. I have anonymous
access disabled, integrated Windows authentication enabled, so the request
must be running using my credentials and I'm able to open this file via the
Windows shell. I imagine that perhaps I need to tweak a setting somewhere,
but I'm not sure where.

2. Is this the quickest way to stream a file back to a remote client? Speedy
delivery of the document to the client is critical and so anything that I
can do to improve performance is important to me. Maybe conversion to
Base64String is not as efficient? If I can use a more efficient format I
will. Just bear in mind that I need to stream binary files (e.g. JPG) as
well as textual, so I need a format which will preserve every bit as it
travels via HTTP.

Thanks very much for your advice!

- Joe Geretz -

[WebMethod]
public string GetFileStream(string FileSpec)
{
try
{
FileStream FS = new FileStream(FileSpec, FileMode.Open);
byte[] FileBytes = new byte[FS.Length];
FS.Read(FileBytes, 0, (int)FS.Length);
FS.Close();
return System.Convert.ToBase64String(FileBytes, 0, FileBytes.Length);
}
catch (Exception e)
{
throw new Exception("Could not open " + FileSpec, e);
}
}
Nov 17 '05 #1
Share this Question
Share on Google+
24 Replies


P: n/a
Joseph Geretz wrote:
Up to this point, our application has been using Windows File Sharing to
transfer files to and from our application document repository. This
approach does not lend itself toward a secure environment and so we are in
the process of imposing a WebService gateway between our application client
and the repository.

(As a starting point, the WebService won't be a richly featured application
server; business rules are still implemented in the client. But this will
ensure that all access to the document repository is made via our software.
Although the WebMethod below accepts only a single parameter, I'll shortly
be adding authentication parameters to this method to ensure that accesses
to this WebMethod actually originate from our client application.)

Here is the method which I've defined (below). I have two questions, one
which relates to functionality, and the other which relates to performance.

1. I can't get this to work! When I test this I get the following error
message:

Could not open C:\Winzip.log --> Access to the path
"C:\Winzip.log" is denied.

Here's the line of code on which the exception occurs:

FileStream FS = new FileStream(FileSpec, FileMode.Open);

I can't imagine that this is a Windows security problem. I have anonymous
access disabled, integrated Windows authentication enabled, so the request
must be running using my credentials and I'm able to open this file via the
Windows shell. I imagine that perhaps I need to tweak a setting somewhere,
but I'm not sure where.

2. Is this the quickest way to stream a file back to a remote client? Speedy
delivery of the document to the client is critical and so anything that I
can do to improve performance is important to me. Maybe conversion to
Base64String is not as efficient? If I can use a more efficient format I
will. Just bear in mind that I need to stream binary files (e.g. JPG) as
well as textual, so I need a format which will preserve every bit as it
travels via HTTP.

Thanks very much for your advice!

- Joe Geretz -

[WebMethod]
public string GetFileStream(string FileSpec)
{
try
{
FileStream FS = new FileStream(FileSpec, FileMode.Open);
byte[] FileBytes = new byte[FS.Length];
FS.Read(FileBytes, 0, (int)FS.Length);
FS.Close();
return System.Convert.ToBase64String(FileBytes, 0, FileBytes.Length);
}
catch (Exception e)
{
throw new Exception("Could not open " + FileSpec, e);
}
}


For transferring a file via SOAP take a look at the Microsoft WSE and
the SOAP Attachments specification it implements.

Cheers
Jimbo.
Nov 17 '05 #2

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:uJ**************@tk2msftngp13.phx.gbl...
Up to this point, our application has been using Windows File Sharing to
transfer files to and from our application document repository. This
approach does not lend itself toward a secure environment and so we are in
the process of imposing a WebService gateway between our application
client and the repository.

(As a starting point, the WebService won't be a richly featured
application server; business rules are still implemented in the client.
But this will ensure that all access to the document repository is made
via our software. Although the WebMethod below accepts only a single
parameter, I'll shortly be adding authentication parameters to this method
to ensure that accesses to this WebMethod actually originate from our
client application.)

Here is the method which I've defined (below). I have two questions, one
which relates to functionality, and the other which relates to
performance.

1. I can't get this to work! When I test this I get the following error
message:

Could not open C:\Winzip.log --> Access to the path
&quot;C:\Winzip.log&quot; is denied.


Is this file on the Client's filesystem or the Server's?

Why don't you just use Windows SharePoint Services. It's part of the OS,
and that's what it's for.

David
Nov 17 '05 #3

P: n/a
Hi David,

Thanks for your response.

The file is on the server. That's the whole point, we're imposing the
WebService as a gateway between the server-side file repository and the
clients.

I am able to get access, by placing the following directive inside the
Web.config file:

<identity impersonate="true" userName="SRS\Joseph" password="foobar"/>

However, the following directive doesn't work, even though I am logged in as
SRS\Joseph.

<identity impersonate="true" userName="" password=""/>

I'm curious as to why the latter doesn't work. My site is set up to use
integrated Windows authentication. Shouldn't the transaction be using the
credentials SRS\Joseph in the latter case, just as it is in the former case?
Why don't you just use Windows SharePoint Services. It's part of the OS,
and that's what it's for.
Sharepoint stores its files inside SQL Server. BLOB access is not as quick
as native filesystem access. If we wanted to go that route, we'd have been
storing our documents inside SQL Server a long time ago.

Thanks,

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:%2****************@tk2msftngp13.phx.gbl...
"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:uJ**************@tk2msftngp13.phx.gbl...
Up to this point, our application has been using Windows File Sharing to
transfer files to and from our application document repository. This
approach does not lend itself toward a secure environment and so we are
in the process of imposing a WebService gateway between our application
client and the repository.

(As a starting point, the WebService won't be a richly featured
application server; business rules are still implemented in the client.
But this will ensure that all access to the document repository is made
via our software. Although the WebMethod below accepts only a single
parameter, I'll shortly be adding authentication parameters to this
method to ensure that accesses to this WebMethod actually originate from
our client application.)

Here is the method which I've defined (below). I have two questions, one
which relates to functionality, and the other which relates to
performance.

1. I can't get this to work! When I test this I get the following error
message:

Could not open C:\Winzip.log --> Access to the path
&quot;C:\Winzip.log&quot; is denied.


Is this file on the Client's filesystem or the Server's?

Why don't you just use Windows SharePoint Services. It's part of the OS,
and that's what it's for.

David

Nov 17 '05 #4

P: n/a
> However, the following directive doesn't work, even though I am logged in
as SRS\Joseph.

<identity impersonate="true" userName="" password=""/>
Cancel that. It does work.

- Joe Geretz -

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:uN**************@TK2MSFTNGP14.phx.gbl... Hi David,

Thanks for your response.

The file is on the server. That's the whole point, we're imposing the
WebService as a gateway between the server-side file repository and the
clients.

I am able to get access, by placing the following directive inside the
Web.config file:

<identity impersonate="true" userName="SRS\Joseph" password="foobar"/>

However, the following directive doesn't work, even though I am logged in
as SRS\Joseph.

<identity impersonate="true" userName="" password=""/>

I'm curious as to why the latter doesn't work. My site is set up to use
integrated Windows authentication. Shouldn't the transaction be using the
credentials SRS\Joseph in the latter case, just as it is in the former
case?
Why don't you just use Windows SharePoint Services. It's part of the OS,
and that's what it's for.


Sharepoint stores its files inside SQL Server. BLOB access is not as quick
as native filesystem access. If we wanted to go that route, we'd have been
storing our documents inside SQL Server a long time ago.

Thanks,

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:%2****************@tk2msftngp13.phx.gbl...

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:uJ**************@tk2msftngp13.phx.gbl...
Up to this point, our application has been using Windows File Sharing to
transfer files to and from our application document repository. This
approach does not lend itself toward a secure environment and so we are
in the process of imposing a WebService gateway between our application
client and the repository.

(As a starting point, the WebService won't be a richly featured
application server; business rules are still implemented in the client.
But this will ensure that all access to the document repository is made
via our software. Although the WebMethod below accepts only a single
parameter, I'll shortly be adding authentication parameters to this
method to ensure that accesses to this WebMethod actually originate from
our client application.)

Here is the method which I've defined (below). I have two questions, one
which relates to functionality, and the other which relates to
performance.

1. I can't get this to work! When I test this I get the following error
message:

Could not open C:\Winzip.log --> Access to the path
&quot;C:\Winzip.log&quot; is denied.


Is this file on the Client's filesystem or the Server's?

Why don't you just use Windows SharePoint Services. It's part of the OS,
and that's what it's for.

David


Nov 17 '05 #5

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:uN**************@TK2MSFTNGP14.phx.gbl...
Hi David,

Thanks for your response.

The file is on the server. That's the whole point, we're imposing the
WebService as a gateway between the server-side file repository and the
clients.

I am able to get access, by placing the following directive inside the
Web.config file:

<identity impersonate="true" userName="SRS\Joseph" password="foobar"/>

However, the following directive doesn't work, even though I am logged in
as SRS\Joseph.

<identity impersonate="true" userName="" password=""/>

I'm curious as to why the latter doesn't work. My site is set up to use
integrated Windows authentication. Shouldn't the transaction be using the
credentials SRS\Joseph in the latter case, just as it is in the former
case?
Why don't you just use Windows SharePoint Services. It's part of the OS,
and that's what it's for.


Sharepoint stores its files inside SQL Server. BLOB access is not as quick
as native filesystem access. If we wanted to go that route, we'd have been
storing our documents inside SQL Server a long time ago.


Transfering over SOAP will require Base64 encoding and lots of memory on the
server, as you've discovered. Which is a far cry from native filesystem
access.

David
Nov 17 '05 #6

P: n/a
> Transfering over SOAP will require Base64 encoding and lots of memory on
the server, as you've discovered. Which is a far cry from native
filesystem access.
Yes. Our situation is such that we need to support two file access types.

Native Filesystem Access (Best Performance / Worst Security)
Via Web Gateway (Worst Performance / Best Security)

We're looking for a 'common denominator' repository so that clients can
easily transition from one approach to the other, or even support a mixed
approach, with workstations on the intranet using native filesystem access
and remote workstations using the Web Gateway access. Filesystem seems to
meet this criteria for us.

We've been doing filesystem access for years, so no issues there. Serving
these files up via HTTP will be a new option.
Transfering over SOAP will require Base64 encoding
Is this an absolute given? Is there no way to transfer via HTTP using a
binary protocol? Should I be using Web Services at all for this? Maybe I
should be using Remoting? Jimbo mentioned a protocol called DIME which is
used to send attachments via Web Services. Maybe this is the best way to go?

Has anyone had experience with this; specifically the transport of binary
data via HTTP?

Thanks for your advice,

Joseph Geretz

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:ux**************@TK2MSFTNGP15.phx.gbl...
"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:uN**************@TK2MSFTNGP14.phx.gbl...
Hi David,

Thanks for your response.

The file is on the server. That's the whole point, we're imposing the
WebService as a gateway between the server-side file repository and the
clients.

I am able to get access, by placing the following directive inside the
Web.config file:

<identity impersonate="true" userName="SRS\Joseph" password="foobar"/>

However, the following directive doesn't work, even though I am logged in
as SRS\Joseph.

<identity impersonate="true" userName="" password=""/>

I'm curious as to why the latter doesn't work. My site is set up to use
integrated Windows authentication. Shouldn't the transaction be using the
credentials SRS\Joseph in the latter case, just as it is in the former
case?
Why don't you just use Windows SharePoint Services. It's part of the
OS, and that's what it's for.


Sharepoint stores its files inside SQL Server. BLOB access is not as
quick as native filesystem access. If we wanted to go that route, we'd
have been storing our documents inside SQL Server a long time ago.


Transfering over SOAP will require Base64 encoding and lots of memory on
the server, as you've discovered. Which is a far cry from native
filesystem access.

David

Nov 17 '05 #7

P: n/a
And one more follow up question:
Transfering over SOAP will require Base64 encoding ...
So if I download a PDF from the web, or stream an audio / video file over
the web it always travels in Base64 format? Is there a more compact way in
which this can be transmitted in binary format?

Thanks,

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:ux**************@TK2MSFTNGP15.phx.gbl...
"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:uN**************@TK2MSFTNGP14.phx.gbl...
Hi David,

Thanks for your response.

The file is on the server. That's the whole point, we're imposing the
WebService as a gateway between the server-side file repository and the
clients.

I am able to get access, by placing the following directive inside the
Web.config file:

<identity impersonate="true" userName="SRS\Joseph" password="foobar"/>

However, the following directive doesn't work, even though I am logged in
as SRS\Joseph.

<identity impersonate="true" userName="" password=""/>

I'm curious as to why the latter doesn't work. My site is set up to use
integrated Windows authentication. Shouldn't the transaction be using the
credentials SRS\Joseph in the latter case, just as it is in the former
case?
Why don't you just use Windows SharePoint Services. It's part of the
OS, and that's what it's for.


Sharepoint stores its files inside SQL Server. BLOB access is not as
quick as native filesystem access. If we wanted to go that route, we'd
have been storing our documents inside SQL Server a long time ago.


Transfering over SOAP will require Base64 encoding and lots of memory on
the server, as you've discovered. Which is a far cry from native
filesystem access.

David

Nov 17 '05 #8

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...
And one more follow up question:
Transfering over SOAP will require Base64 encoding ...


So if I download a PDF from the web, or stream an audio / video file over
the web it always travels in Base64 format? Is there a more compact way in
which this can be transmitted in binary format?


Yes. HTTP is a binary protocol, ASMX web service use SOAP and are XML
(text) over HTTP.

It's quite easy to send/recieve binary files directly over HTTP.
In ASP.NET you can access the request/response stream objects and write
bytes to the wire directly.
http://www.codeproject.com/aspnet/fileupload.asp
http://www.ondotnet.com/pub/a/dotnet...04/01/asp.html
http://www.15seconds.com/issue/010504.htm

You can also send binary files using web services, but you need an enhanced
web services implementation on client and server like Microsoft Web Services
Enhancements 2.0
http://msdn.microsoft.com/webservice...e/default.aspx

Which impmenents Direct Internet Message Encapsulation DIME for attaching
binary messages to web services.
http://msdn.microsoft.com/library/de...ml/wsedime.asp
David
Nov 17 '05 #9

P: n/a
Thanks for your help, David. We sure have a lot more choices these days. I
want to be sure I get this right.

Given the choice between classic ASP (i.e. using Request, Response, etc. to
communicate between client and server) and using Web Srvices with DIME (WSE)
what would you recommend? Can you point out some pros and cons to either
approach?

I've done several web applications in the past so I'm familiar with the
ASP/IIS object model, and I'm currently researching Web Service Extensions /
DIME. I can engineer the client to interface with either of these server
side approaches. Is it six of one / half dozen of the other? Or do you see
any of these approaches as being superior to the other?

Any quick pointers from someone who's 'been there / done that' will be
extremely appreciated.

Thanks!

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:Oo**************@TK2MSFTNGP10.phx.gbl...

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...
And one more follow up question:
Transfering over SOAP will require Base64 encoding ...


So if I download a PDF from the web, or stream an audio / video file over
the web it always travels in Base64 format? Is there a more compact way
in which this can be transmitted in binary format?


Yes. HTTP is a binary protocol, ASMX web service use SOAP and are XML
(text) over HTTP.

It's quite easy to send/recieve binary files directly over HTTP.
In ASP.NET you can access the request/response stream objects and write
bytes to the wire directly.
http://www.codeproject.com/aspnet/fileupload.asp
http://www.ondotnet.com/pub/a/dotnet...04/01/asp.html
http://www.15seconds.com/issue/010504.htm

You can also send binary files using web services, but you need an
enhanced web services implementation on client and server like Microsoft
Web Services Enhancements 2.0
http://msdn.microsoft.com/webservice...e/default.aspx

Which impmenents Direct Internet Message Encapsulation DIME for attaching
binary messages to web services.
http://msdn.microsoft.com/library/de...ml/wsedime.asp
David

Nov 17 '05 #10

P: n/a
Thanks for your help, David. We sure have a lot more choices these days. I
want to be sure I get this right.

Given the choice between classic ASP (i.e. using Request, Response, etc. to
communicate between client and server) and using Web Srvices with DIME (WSE)
what would you recommend? Can you point out some pros and cons to either
approach?

I've done several web applications in the past so I'm familiar with the
ASP/IIS object model, and I'm currently researching Web Service Extensions /
DIME. I can engineer the client to interface with either of these server
side approaches. Is it six of one / half dozen of the other? Or do you see
any of these approaches as being superior to the other?

Any quick pointers from someone who's 'been there / done that' will be
extremely appreciated.

Thanks!

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:Oo**************@TK2MSFTNGP10.phx.gbl...

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...
And one more follow up question:
Transfering over SOAP will require Base64 encoding ...


So if I download a PDF from the web, or stream an audio / video file over
the web it always travels in Base64 format? Is there a more compact way
in which this can be transmitted in binary format?


Yes. HTTP is a binary protocol, ASMX web service use SOAP and are XML
(text) over HTTP.

It's quite easy to send/recieve binary files directly over HTTP.
In ASP.NET you can access the request/response stream objects and write
bytes to the wire directly.
http://www.codeproject.com/aspnet/fileupload.asp
http://www.ondotnet.com/pub/a/dotnet...04/01/asp.html
http://www.15seconds.com/issue/010504.htm

You can also send binary files using web services, but you need an
enhanced web services implementation on client and server like Microsoft
Web Services Enhancements 2.0
http://msdn.microsoft.com/webservice...e/default.aspx

Which impmenents Direct Internet Message Encapsulation DIME for attaching
binary messages to web services.
http://msdn.microsoft.com/library/de...ml/wsedime.asp
David

Nov 17 '05 #11

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:u0**************@TK2MSFTNGP11.phx.gbl...
Thanks for your help, David. We sure have a lot more choices these days. I
want to be sure I get this right.

Given the choice between classic ASP (i.e. using Request, Response, etc.
to communicate between client and server) and using Web Srvices with DIME
(WSE) what would you recommend? Can you point out some pros and cons to
either approach?

I've done several web applications in the past so I'm familiar with the
ASP/IIS object model, and I'm currently researching Web Service Extensions
/ DIME. I can engineer the client to interface with either of these server
side approaches. Is it six of one / half dozen of the other? Or do you see
any of these approaches as being superior to the other?

If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP. The WSE route adds additional
dependencies, and complexity while not really adding anything in this
scenario.

David
Nov 17 '05 #12

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:u0**************@TK2MSFTNGP11.phx.gbl...
Thanks for your help, David. We sure have a lot more choices these days. I
want to be sure I get this right.

Given the choice between classic ASP (i.e. using Request, Response, etc.
to communicate between client and server) and using Web Srvices with DIME
(WSE) what would you recommend? Can you point out some pros and cons to
either approach?

I've done several web applications in the past so I'm familiar with the
ASP/IIS object model, and I'm currently researching Web Service Extensions
/ DIME. I can engineer the client to interface with either of these server
side approaches. Is it six of one / half dozen of the other? Or do you see
any of these approaches as being superior to the other?

If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP. The WSE route adds additional
dependencies, and complexity while not really adding anything in this
scenario.

David
Nov 17 '05 #13

P: n/a
Thanks David.
If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.
Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?

Thanks again, your advice has been very helpful!

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:eW**************@TK2MSFTNGP10.phx.gbl...
"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:u0**************@TK2MSFTNGP11.phx.gbl...
Thanks for your help, David. We sure have a lot more choices these days.
I want to be sure I get this right.

Given the choice between classic ASP (i.e. using Request, Response, etc.
to communicate between client and server) and using Web Srvices with DIME
(WSE) what would you recommend? Can you point out some pros and cons to
either approach?

I've done several web applications in the past so I'm familiar with the
ASP/IIS object model, and I'm currently researching Web Service
Extensions / DIME. I can engineer the client to interface with either of
these server side approaches. Is it six of one / half dozen of the other?
Or do you see any of these approaches as being superior to the other?

If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP. The WSE route adds
additional dependencies, and complexity while not really adding anything
in this scenario.

David

Nov 17 '05 #14

P: n/a
Thanks David.
If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.
Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?

Thanks again, your advice has been very helpful!

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:eW**************@TK2MSFTNGP10.phx.gbl...
"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:u0**************@TK2MSFTNGP11.phx.gbl...
Thanks for your help, David. We sure have a lot more choices these days.
I want to be sure I get this right.

Given the choice between classic ASP (i.e. using Request, Response, etc.
to communicate between client and server) and using Web Srvices with DIME
(WSE) what would you recommend? Can you point out some pros and cons to
either approach?

I've done several web applications in the past so I'm familiar with the
ASP/IIS object model, and I'm currently researching Web Service
Extensions / DIME. I can engineer the client to interface with either of
these server side approaches. Is it six of one / half dozen of the other?
Or do you see any of these approaches as being superior to the other?

If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP. The WSE route adds
additional dependencies, and complexity while not really adding anything
in this scenario.

David

Nov 17 '05 #15

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl...
Thanks David.
If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.


Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?


Classic ASP will work fine.

David
Nov 17 '05 #16

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl...
Thanks David.
If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.


Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?


Classic ASP will work fine.

David
Nov 17 '05 #17

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl...
Thanks David.
If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.


Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?


On second thought, doing this in classic ASP will requre a 3rd party COM
component to handle the download. VBScript just isn't up to the task. It's
not hard, and there's a ton of ASP download libraries. I always wrote my
own. VB6 will work fine for this, or VB.NET through COM interop. The trick
is getting access to the ASP Response object in your component.

David
Nov 17 '05 #18

P: n/a

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl...
Thanks David.
If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.


Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?


On second thought, doing this in classic ASP will requre a 3rd party COM
component to handle the download. VBScript just isn't up to the task. It's
not hard, and there's a ton of ASP download libraries. I always wrote my
own. VB6 will work fine for this, or VB.NET through COM interop. The trick
is getting access to the ASP Response object in your component.

David
Nov 17 '05 #19

P: n/a
Thanks David,
On second thought, doing this in classic ASP will requre a 3rd party COM
component to handle the download.
That shouldn't be any problem. I've plenty of experience with IIS
applications where a single ASP page was simply the host gateway to the VB6
Server-Side application. Naturally, interfacing with the IIS intrinsic
objects (Request, Response, etc.) from within VB6 is the foundation for this
type of system.

And from the client, I'm thinking of using XmlHttp to interface with the ASP
page.

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:ef**************@TK2MSFTNGP10.phx.gbl...
"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl...
Thanks David.
If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.


Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?


On second thought, doing this in classic ASP will requre a 3rd party COM
component to handle the download. VBScript just isn't up to the task.
It's not hard, and there's a ton of ASP download libraries. I always
wrote my own. VB6 will work fine for this, or VB.NET through COM interop.
The trick is getting access to the ASP Response object in your component.

David

Nov 17 '05 #20

P: n/a
Thanks David,
On second thought, doing this in classic ASP will requre a 3rd party COM
component to handle the download.
That shouldn't be any problem. I've plenty of experience with IIS
applications where a single ASP page was simply the host gateway to the VB6
Server-Side application. Naturally, interfacing with the IIS intrinsic
objects (Request, Response, etc.) from within VB6 is the foundation for this
type of system.

And from the client, I'm thinking of using XmlHttp to interface with the ASP
page.

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:ef**************@TK2MSFTNGP10.phx.gbl...
"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl...
Thanks David.
If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.


Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?


On second thought, doing this in classic ASP will requre a 3rd party COM
component to handle the download. VBScript just isn't up to the task.
It's not hard, and there's a ton of ASP download libraries. I always
wrote my own. VB6 will work fine for this, or VB.NET through COM interop.
The trick is getting access to the ASP Response object in your component.

David

Nov 17 '05 #21

P: n/a
Hi Jimbo,

I am attempting to use your suggested approach; that is to use WSE and DIME
for sending binary attachments along with a Web Service method call.

I've set everything up as documented and my code compiles, but it generates
an exception at runtime because I don't get a valid reference to the
ResponseSoapContext object to my WebService. I'm trying to use WSE and DIME
to send attachments via Web Service. I created a brand new WebService
project and added in the reference to WSE. I didn't modify the Web.Config
file myself, but when I looked I was pleasantly surprised to see that all
entries were added automatically for me (see Web.config file below).

Here is the Web Service method which I've defined:

[WebMethod]
public int DropDIMEOnMe(string FileSpec)
{
SoapContext respContext = ResponseSoapContext.Current;
DimeAttachment dimeAttach = new DimeAttachment("file/unknown",
TypeFormat.MediaType, FileSpec);
respContext.Attachments.Add(dimeAttach);
return respContext.Attachments.Count;
}

The statement

respContext.Attachments.Add(dimeAttach);

trips the following error:

Object reference not set to an instance of an object.

The crux of the problem is that ResponseSoapContext.Current = <undefined
value> when I attempt to access it. Why am I unable to get access to the
ResponseSoapContext object?

Thanks for any assistance which you can provide!

- Joe Geretz -

Here's my Web.Config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="microsoft.web.services2"
type="Microsoft.Web.Services2.Configuration.WebSer vicesConfiguration,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</configSections>
<system.web>
<compilation defaultLanguage="c#" debug="true" />
<customErrors mode="RemoteOnly" />
<authentication mode="Windows" />
<authorization>
<allow users="*" />
</authorization>
<trace enabled="false" requestLimit="10" pageOutput="false"
traceMode="SortByTime" localOnly="true" />
<sessionState mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data
source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" />
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<webServices>
<soapExtensionTypes>
<add type="Microsoft.Web.Services2.WebServicesExtension ,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" priority="1" group="0" />
</soapExtensionTypes>
</webServices>
</system.web>
<microsoft.web.services2>
<diagnostics />
</microsoft.web.services2>
</configuration>

"Jimbo" <ji***@notexist.domain.com> wrote in message
news:df*********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
Joseph Geretz wrote:
Up to this point, our application has been using Windows File Sharing to
transfer files to and from our application document repository. This
approach does not lend itself toward a secure environment and so we are
in the process of imposing a WebService gateway between our application
client and the repository.

(As a starting point, the WebService won't be a richly featured
application server; business rules are still implemented in the client.
But this will ensure that all access to the document repository is made
via our software. Although the WebMethod below accepts only a single
parameter, I'll shortly be adding authentication parameters to this
method to ensure that accesses to this WebMethod actually originate from
our client application.)

Here is the method which I've defined (below). I have two questions, one
which relates to functionality, and the other which relates to
performance.

1. I can't get this to work! When I test this I get the following error
message:

Could not open C:\Winzip.log --> Access to the path
&quot;C:\Winzip.log&quot; is denied.

Here's the line of code on which the exception occurs:

FileStream FS = new FileStream(FileSpec, FileMode.Open);

I can't imagine that this is a Windows security problem. I have anonymous
access disabled, integrated Windows authentication enabled, so the
request must be running using my credentials and I'm able to open this
file via the Windows shell. I imagine that perhaps I need to tweak a
setting somewhere, but I'm not sure where.

2. Is this the quickest way to stream a file back to a remote client?
Speedy delivery of the document to the client is critical and so anything
that I can do to improve performance is important to me. Maybe conversion
to Base64String is not as efficient? If I can use a more efficient format
I will. Just bear in mind that I need to stream binary files (e.g. JPG)
as well as textual, so I need a format which will preserve every bit as
it travels via HTTP.

Thanks very much for your advice!

- Joe Geretz -

[WebMethod]
public string GetFileStream(string FileSpec)
{
try
{
FileStream FS = new FileStream(FileSpec, FileMode.Open);
byte[] FileBytes = new byte[FS.Length];
FS.Read(FileBytes, 0, (int)FS.Length);
FS.Close();
return System.Convert.ToBase64String(FileBytes, 0,
FileBytes.Length);
}
catch (Exception e)
{
throw new Exception("Could not open " + FileSpec, e);
}
}


For transferring a file via SOAP take a look at the Microsoft WSE and the
SOAP Attachments specification it implements.

Cheers
Jimbo.

Nov 17 '05 #22

P: n/a
Hi Joseph,

i would recommend using WSS on the server side vecause it gives you good
security on files.

i also recommend you to look at WSE 3, with the MTOM implementation, the
downloads would get smaller.

hope it helps
"Joseph Geretz" wrote:
Thanks David,
On second thought, doing this in classic ASP will requre a 3rd party COM
component to handle the download.


That shouldn't be any problem. I've plenty of experience with IIS
applications where a single ASP page was simply the host gateway to the VB6
Server-Side application. Naturally, interfacing with the IIS intrinsic
objects (Request, Response, etc.) from within VB6 is the foundation for this
type of system.

And from the client, I'm thinking of using XmlHttp to interface with the ASP
page.

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:ef**************@TK2MSFTNGP10.phx.gbl...

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:Oz**************@TK2MSFTNGP11.phx.gbl...
Thanks David.

If you own the code on both sides of the file transfer, I would just use
ASP.NET to transfer the files over raw HTTP.

Or classic ASP would suffice as well? We're not yet a .NET shop and this
would have been our first foray into .NET. Unless ASP.NET add something
compelling to the mix, I'm going to tackle this using classic ASP.

Is there anything that ASP.NET would add to this particular task?


On second thought, doing this in classic ASP will requre a 3rd party COM
component to handle the download. VBScript just isn't up to the task.
It's not hard, and there's a ton of ASP download libraries. I always
wrote my own. VB6 will work fine for this, or VB.NET through COM interop.
The trick is getting access to the ASP Response object in your component.

David


Nov 17 '05 #23

P: n/a
Hi Luis,

I am trying to use WSE 2 but I'm having a problem. (I can't use WSE3 because
it's not production yet.)

I created a brand new WebService project and added in the reference to WSE.
I didn't modify the Web.Config
file myself, but when I looked I was pleasantly surprised to see that all
entries were added automatically for me (see Web.config file below).

Here is the Web Service method which I've defined:

[WebMethod]
public int DropDIMEOnMe(string FileSpec)
{
SoapContext respContext = ResponseSoapContext.Current;
DimeAttachment dimeAttach = new DimeAttachment("file/unknown",
TypeFormat.MediaType, FileSpec);
respContext.Attachments.Add(dimeAttach);
return respContext.Attachments.Count;
}

The statement

respContext.Attachments.Add(dimeAttach);

trips the following error:

Object reference not set to an instance of an object.

The crux of the problem is that ResponseSoapContext.Current = <undefined
value> when I attempt to access it. Why am I unable to get access to the
ResponseSoapContext object?

Thanks for any assistance which you can provide!

- Joe Geretz -

Here's my Web.Config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="microsoft.web.services2"
type="Microsoft.Web.Services2.Configuration.WebSer vicesConfiguration,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</configSections>
<system.web>
<compilation defaultLanguage="c#" debug="true" />
<customErrors mode="RemoteOnly" />
<authentication mode="Windows" />
<authorization>
<allow users="*" />
</authorization>
<trace enabled="false" requestLimit="10" pageOutput="false"
traceMode="SortByTime" localOnly="true" />
<sessionState mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data
source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" />
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<webServices>
<soapExtensionTypes>
<add type="Microsoft.Web.Services2.WebServicesExtension ,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" priority="1" group="0" />
</soapExtensionTypes>
</webServices>
</system.web>
<microsoft.web.services2>
<diagnostics />
</microsoft.web.services2>
</configuration>

"Luis Azedo" <Lu*******@discussions.microsoft.com> wrote in message
news:0C**********************************@microsof t.com...
Hi Joseph,

i would recommend using WSS on the server side vecause it gives you good
security on files.

i also recommend you to look at WSE 3, with the MTOM implementation, the
downloads would get smaller.

hope it helps
"Joseph Geretz" wrote:
Thanks David,
> On second thought, doing this in classic ASP will requre a 3rd party
> COM
> component to handle the download.


That shouldn't be any problem. I've plenty of experience with IIS
applications where a single ASP page was simply the host gateway to the
VB6
Server-Side application. Naturally, interfacing with the IIS intrinsic
objects (Request, Response, etc.) from within VB6 is the foundation for
this
type of system.

And from the client, I'm thinking of using XmlHttp to interface with the
ASP
page.

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:ef**************@TK2MSFTNGP10.phx.gbl...
>
> "Joseph Geretz" <jg*****@nospam.com> wrote in message
> news:Oz**************@TK2MSFTNGP11.phx.gbl...
>> Thanks David.
>>
>>> If you own the code on both sides of the file transfer, I would just
>>> use
>>> ASP.NET to transfer the files over raw HTTP.
>>
>> Or classic ASP would suffice as well? We're not yet a .NET shop and
>> this
>> would have been our first foray into .NET. Unless ASP.NET add
>> something
>> compelling to the mix, I'm going to tackle this using classic ASP.
>>
>> Is there anything that ASP.NET would add to this particular task?
>>
>
> On second thought, doing this in classic ASP will requre a 3rd party
> COM
> component to handle the download. VBScript just isn't up to the task.
> It's not hard, and there's a ton of ASP download libraries. I always
> wrote my own. VB6 will work fine for this, or VB.NET through COM
> interop.
> The trick is getting access to the ASP Response object in your
> component.
>
> David
>


Nov 17 '05 #24

P: n/a
I have got this figured out now. Evidently, when you run client and
webservice projects in a signle solution, Visual Studio does not create the
proxy. I removed the webservice project and instead added a reference to the
webservice to the client project; Voila! Visual Studio created the proxy
class for me. Of course, I still had to tweak the proxy class, but getting
the proxy class created was 90% of the solution.

- Joe Geretz -

"Joseph Geretz" <jg*****@nospam.com> wrote in message
news:uy**************@TK2MSFTNGP14.phx.gbl...
Hi Luis,

I am trying to use WSE 2 but I'm having a problem. (I can't use WSE3
because it's not production yet.)

I created a brand new WebService project and added in the reference to
WSE. I didn't modify the Web.Config
file myself, but when I looked I was pleasantly surprised to see that all
entries were added automatically for me (see Web.config file below).

Here is the Web Service method which I've defined:

[WebMethod]
public int DropDIMEOnMe(string FileSpec)
{
SoapContext respContext = ResponseSoapContext.Current;
DimeAttachment dimeAttach = new DimeAttachment("file/unknown",
TypeFormat.MediaType, FileSpec);
respContext.Attachments.Add(dimeAttach);
return respContext.Attachments.Count;
}

The statement

respContext.Attachments.Add(dimeAttach);

trips the following error:

Object reference not set to an instance of an object.

The crux of the problem is that ResponseSoapContext.Current = <undefined
value> when I attempt to access it. Why am I unable to get access to the
ResponseSoapContext object?

Thanks for any assistance which you can provide!

- Joe Geretz -

Here's my Web.Config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="microsoft.web.services2"
type="Microsoft.Web.Services2.Configuration.WebSer vicesConfiguration,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</configSections>
<system.web>
<compilation defaultLanguage="c#" debug="true" />
<customErrors mode="RemoteOnly" />
<authentication mode="Windows" />
<authorization>
<allow users="*" />
</authorization>
<trace enabled="false" requestLimit="10" pageOutput="false"
traceMode="SortByTime" localOnly="true" />
<sessionState mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data
source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"
/>
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<webServices>
<soapExtensionTypes>
<add type="Microsoft.Web.Services2.WebServicesExtension ,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" priority="1" group="0" />
</soapExtensionTypes>
</webServices>
</system.web>
<microsoft.web.services2>
<diagnostics />
</microsoft.web.services2>
</configuration>

"Luis Azedo" <Lu*******@discussions.microsoft.com> wrote in message
news:0C**********************************@microsof t.com...
Hi Joseph,

i would recommend using WSS on the server side vecause it gives you good
security on files.

i also recommend you to look at WSE 3, with the MTOM implementation, the
downloads would get smaller.

hope it helps
"Joseph Geretz" wrote:
Thanks David,

> On second thought, doing this in classic ASP will requre a 3rd party
> COM
> component to handle the download.

That shouldn't be any problem. I've plenty of experience with IIS
applications where a single ASP page was simply the host gateway to the
VB6
Server-Side application. Naturally, interfacing with the IIS intrinsic
objects (Request, Response, etc.) from within VB6 is the foundation for
this
type of system.

And from the client, I'm thinking of using XmlHttp to interface with the
ASP
page.

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:ef**************@TK2MSFTNGP10.phx.gbl...
>
> "Joseph Geretz" <jg*****@nospam.com> wrote in message
> news:Oz**************@TK2MSFTNGP11.phx.gbl...
>> Thanks David.
>>
>>> If you own the code on both sides of the file transfer, I would just
>>> use
>>> ASP.NET to transfer the files over raw HTTP.
>>
>> Or classic ASP would suffice as well? We're not yet a .NET shop and
>> this
>> would have been our first foray into .NET. Unless ASP.NET add
>> something
>> compelling to the mix, I'm going to tackle this using classic ASP.
>>
>> Is there anything that ASP.NET would add to this particular task?
>>
>
> On second thought, doing this in classic ASP will requre a 3rd party
> COM
> component to handle the download. VBScript just isn't up to the task.
> It's not hard, and there's a ton of ASP download libraries. I always
> wrote my own. VB6 will work fine for this, or VB.NET through COM
> interop.
> The trick is getting access to the ASP Response object in your
> component.
>
> David
>


Nov 17 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.