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]
