I understand the question. It's "please finish my homework assignment for me?"

Or you can set .CommandType to ystem.Data.CommandType.StoredProcedure and set .CommandText to the name of the stored procedure. I think this is supposed to run slightly faster as the server doesn't have to parse out the "CALL" command.

I'm suspicious of your Content-Length. I believe SOAP won't see anything past the 115th character of your request, which is a lot less than all of it.

I'm sure I'm not the only one wondering why you'd implement a web server within a network driver. I can imagine you just want a really small web server--but then it doesn't have to be part of a driver. Or I can imagine you want a driver whose configuration utility is http-based--but then the utility doesn't have to be part of the driver either. So I wonder if you could explain a little more what you're trying to do... or why. I think the best answer depends a lot on whether your environment supports things like stdin/stdout, sockets, and the like. And of course what operating system you're working with. (If your environment lets you use inetd, writing a web server gets a lot easier! You simply read a request on stdin and push the response onto stdout.)

Rather than writing all that client-side code, you could let your server return an XML content-type. The browser will prompt the user as to where to save the content.

Well Mike, yes and no. I've got the Runtime Callable Wrapper, and I can use it (still) from an ordinary console application, but I'm still getting those errors when I try to instantiate the object from within a web service. I found out that when I just try to load the assembly directly using System.Reflection.Assembly.LoadFile(filename) it fails with the same error. But System.Reflection.Assembly.LoadFrom(filename) appears to work, as does System.Reflection.Assembly.ReflectionOnlyLoadFrom(filename). When I use System.Security.Permissions.FileIOPermission to determine my ASPNET user's rights on the assembly DLL, it tells me I have full rights, so it's not a matter of file access. And I pulled apart the reflection data to find that I'm depending only on mscorlib, which can't be the problem either. I finally tried signing my RCW assembly just in case it was ASPNET not wanting to run unsigned code. So... it looks my specific question is: what is it about the ASPNET environment that makes loading a RCW assembly (or any assembly?) so different from a console environment? Is there a document that addresses that? Thanks to all.

Hi everyone. My customer has a COM object called validatecom.dll. I need to use this in my VS2005/C# web service. So I used tlbimp.exe to create a Runtime Callable Wrapper for validatecom.dll, defining the namespace as "wsl" because that makes sense in their environment. The COM interface is called IValidate, thus giving me a class called CValidateClass. In my unit test, which runs as an ordinary .NET application, I can instantiate a wsl.CValidateClass object and call methods on it. No problem. When I try to instantiate wsl.CValidateClass in my Web Service, however, I get an error, to wit: System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID... yadda yadda yadda... failed due to the following error: 80070005. And as we all know, 80070005 is another way of saying "Access Denied." Now I'm wondering why I can access the RCW assembly from an ordinary application, but not from a Web Service. I tried giving "full control" rights to "everyone" on that RCW assembly, but still no joy. Any ideas on this? I'd be happy with a pointer to an MSDN article, a Google term, anything! Thanks to all for your help.

Outstanding, Mike--that's exactly what I was looking for! I appreciate your help on this.

Good answer--why am I expecting SOAP to carry my HTTP headers in the first place? :rolleyes: Thanks for the perspective, and for the smack in the head. What do you think would be "best practice" if I want to push the contents of that cookie (which is all the authentication system gives me to work with) to my web service? I'm thinking it should be just another element in the SOAP request. Is there a more elegant way to do what I'm trying to do?

Hi all. I hope this is the right forum section for this kind of question. My production environment gives the user a cookie that contains encrypted authorization data. My web service (which does not produce the cookie) is expected to read the value of the cookie, do some magic with it, and extract the name of the authorized user. That's what they give me. A cookie. The client side calls my service via SOAP and passes the cookie value through the "Cookie:" header. All other headers are seen by the service, but "Cookie:" is not. (I can see that Context.Request.Cookies is empty, and Context.Request.ServerVariables contains all of my headers except "HTTP_COOKIE".) I can even pass my cookie data in another header, as long as it's not called "Cookie:". It sure looks as though .NET doesn't want services to see cookies, to the point of filtering out the "Cookie:" header when it's sent. My question is--am I crazy, or does the .NET Framework remove cookies from SOAP web service requests? And if so, is there a way to override that behavior, other than by building an equivalent to the "Cookie:" header and parsing it on the service side? Again, the user is already authenticated through another mechanism, they already have the cookie, and I'm supposed to use the cookie to figure out who's making the request. Thanks in advance for any insights as to how .NET Framework handles cookies on web service requests.