The IL is the same - it's a dependency on the assembly name being used. In your original code, you named the soapsuds-generated shim 'server' while the real server was called 'remoting2'. When soapsuds extracted the wsdl from the server, the server returned information indicating that the assembly-qualied name of the type was "ServiceClass, Remoting2, culture=blah blah blah". When soapsuds created the shim dll, it recorded that information in the SoapType attribute that it applied to the proxy class called ServiceClass that it generated. If you use the -gc switch in addition when you run soapsuds, you'll see that the format of the assembly-qualified name looks like what you see in the error message you were getting:
"Cannot load type soap:ServiceClass, http://schemas.microsoft.com/clr/nsassem/Server/Remoting2%2C%20Version%3 D1.0 .1137.27545%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull." Just do the following substitutions on that string: %2C => , %20 => (space) %3D => = which yields an xml "namespace" of "soap:ServiceClass, http://schemas.microsoft.com/clr/nsassem/Server/Remoting2, Version=1.0.1137.27545, Culture=neutral, PublicKeyToken=null." It's easier to spot that it's a an assembly-qualified type name masquerading as an xml namespace. So it leads to a discrepancy between what your client program thinks the name of the type is (ServiceClass, server, ...) and what the server thinks the name of the type is (ServiceClass, remoting2, ...) causing the failure you saw. There are actually two work arounds. The first is the one I mentioned - just make sure the name of the soapsuds-generated proxy dll is the same as the name of the real server assembly. But since this coupling can lead to maintenance/evolution problems down the road for the server (i.e., never being able to change the name of its server-side assembly w/o fear of breaking all existing clients), there's a 2nd work around. The 2nd work around is to use add a <soapInterop> element to your server-side remoting configuration file and use the <interopXmlType> sub-element to map what the client says is the type name onto what the server knows is the real type name, for example (under /configuration/system.runtime.remoting/application in the server config file): <soapInterop> <!-- map requests from clients for type "RemoteCalc, RemoteCalcAssembly" onto the actual concrete implementation type (CalcImpl) and assembly (server) --> <interopXmlType clr="CalcImpl, server" xml="RemoteCalc, RemoteCalcAssembly" /> </soapInterop> -Mike DevelopMentor http://staff.develop.com/woodring > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of Sean Chase > Sent: Thursday, February 13, 2003 9:28 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Asynch Remoting Call Fails > > > Thanks Mike, changing the output DLL filename for the > soapsuds command line > fixed the problem. Is the dependency actually on the name, or > does the IL > get generated differently because of the name used in the > soapsuds command > line utility? I didn't see much difference in ILDASM. > > Thanks again, > > Sean > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of > Mike Woodring > (DevelopMentor) > Sent: Wednesday, February 12, 2003 3:12 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Asynch Remoting Call Fails > > > Switch your soapsuds -oa switch from -oa:server.dll to > -oa:remoting2.dll so > that the soapsuds-generated shim assembly used by the client > has the same > name as the actual target server assembly (remoting2). Be sure not to > overwrite the real server assembly when you do this :-). > Then update your > client project to reference this newly named dll and try again. > > -Mike > DevelopMentor > http://staff.develop.com/woodring > > > -----Original Message----- > > From: Moderated discussion of advanced .NET topics. > > [mailto:[EMAIL PROTECTED]] On Behalf Of Sean Chase > > Sent: Wednesday, February 12, 2003 1:57 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] Asynch Remoting Call Fails > > > > > > Hi Mike, > > > > Thanks for your reply. > > > > The syntax I used at the command line for soapsuds is: > > > > soapsuds -url:http://localhost:1095/ServiceClass?WSDL -oa:Server.dll > > > > The directory structure for the server console app is: > > > > My Documents\Visual Studio Projects\Remoting2\bin\Debug > > > > ...and the client directory is: > > > > Visual Studio Projects\Remoting2Client\bin\Debug > > > > The soapsuds generated DLL is in: > > > > My Documents\Visual Studio Projects\Remoting2Client > > > > The exception text is: > > > > "Cannot load type soap:ServiceClass, > > http://schemas.microsoft.com/clr/nsassem/Server/Remoting2%2C%2 > > 0Version%3D1.0 > > .1137.27545%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull. > > > > [snip] >
