 | |
Seeking advice on transferring a file via WebMethod
Dotnet Framework (Performance) microsoft.public.dotnet.framework.performance
 |
| | Thread Tools | Search this Thread | Display Modes |
#11
 
| |||
| |||
|
Re: Seeking advice on transferring a file via WebMethod -
08-31-2005
, 10:08 AM
|
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
#12
| |||
| |||
|
|
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. |
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 meat (AT) hotmail (DOT) com> wrote in
message news:eW8xCWjrFHA.1132 (AT) TK2MSFTNGP10 (DOT) phx.gbl...
Quote:
|
"Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote in message news:u0CB8EcrFHA.3796 (AT) TK2MSFTNGP11 (DOT) 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 |
#13
| |||
| |||
|
|
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? |
David
#14
| |||
| |||
|
|
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? |
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
#15
| |||
| |||
|
|
On second thought, doing this in classic ASP will requre a 3rd party COM component to handle the download. |
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 meat (AT) hotmail (DOT) com> wrote in
message news:efaykIkrFHA.1132 (AT) TK2MSFTNGP10 (DOT) phx.gbl...
Quote:
|
"Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote in message news:OzbHLBkrFHA.1168 (AT) TK2MSFTNGP11 (DOT) 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 |
#16
| |||
| |||
|
|
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. |
#17
| |||
| |||
|
|
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 meat (AT) hotmail (DOT) com> wrote in message news:efaykIkrFHA.1132 (AT) TK2MSFTNGP10 (DOT) phx.gbl... "Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote in message news:OzbHLBkrFHA.1168 (AT) TK2MSFTNGP11 (DOT) 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 |
#18
| |||
| |||
|
|
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 meat (AT) hotmail (DOT) com> wrote in message news:efaykIkrFHA.1132 (AT) TK2MSFTNGP10 (DOT) phx.gbl... "Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote in message news:OzbHLBkrFHA.1168 (AT) TK2MSFTNGP11 (DOT) 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 |
#19
| |||
| |||
|
|
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" <LuisAzedo (AT) discussions (DOT) microsoft.com> wrote in message news:0C739F45-78EA-44C5-B144-8988277BED79 (AT) microsoft (DOT) 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 meat (AT) hotmail (DOT) com> wrote in message news:efaykIkrFHA.1132 (AT) TK2MSFTNGP10 (DOT) phx.gbl... "Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote in message news:OzbHLBkrFHA.1168 (AT) TK2MSFTNGP11 (DOT) 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 |
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.