[Mono-devel-list] mono and .net web services

[Daniel Pinto de Mello e Silva]

On Thu, 2004-01-15 at 07:36, Jonathan Pryor wrote:
> Alas, I can only answer one of your questions...
> 
> On Wed, 2004-01-14 at 22:26, Daniel Pinto de Mello e Silva wrote:
> <snip/>
> > The web-service ASMX file is being interpreted just fine in the first
> > IIS server.  From its WSDL file Mono's wsdl tool created a client
> > proxy.  The proxy library (compiled with Mono's mcs) is placed in the
> > second IIS server.
> 
> <snip/>
> 
> > Are .Net assemblies compiled with Mono's mcs supposed to work under
> > Microsoft's VM and IIS?
> 
> The answer is a resounding maybe.
> 
> Yes, the IL generated by mcs will execute properly under .NET and IIS.
> 
> Unfortunately, IL isn't the only concern.  The other concern (and the
> primary concern in this case) is the behavior with shared assemblies.
> 
> First of all, mcs doesn't (AFAIK) place the public key token from the
> assemblies it's linked against into the generated file.  Which means you
> can't have two shared Foo.dll's, signed by different companies, and have
> Mono/mcs load the correct Foo.dll.  (Not that this is a problem, as with
> the current design of Mono -- with no GAC -- there could only be one
> Foo.dll in $prefix/lib, which is the default search directory, so you
> can't really have two Foo.dll's installed anyway...)
> 
> Even if this were fixed, there's the second issue.  You're compiling
> under Linux, so you'll be compiling against Mono's
> System.Web.Services.dll, which will (most assuredly) have a different
> public key token than Microsoft's System.Web.Services.dll.  Thus, even
> with properly generated IL referencing the "correct" strongly-named
> Assembly, you'd be referencing Mono's assembly, not Microsoft's.

Thanks for the explanation.  That's too bad...

> There are two solutions to your problem:
> (1) Copy Mono's System.Web.Services.dll into the same directory as the
> proxy library.  Since Mono's System.Web.Services.dll is a private
> Assembly and is in the same directory as your proxy library (which is
> effectively referencing a private assembly, as it lacks the public key
> token information needed for shared assemblies), your proxy should now
> load properly.  The (possible) problem is that you'll be using Mono's
> System.Web.Services.dll, not Microsoft's, which may not be desired.
> 

Unfortunately, this doesn't seem to work.  Another error shows up when I
copy Mono's System.Web.Services.dll to ./bin:

"""
Exception Details: System.NullReferenceException: Object reference not
set to an instance of an object.

Source Error: 
Line 43:     public void OnSubmit(Object sender, EventArgs e)
Line 44:       {
Line 45:       Calc.CalculatorSoap service = new Calc.CalculatorSoap();

Source File: d:\iishome\dsilva\calculator-client.aspx    Line: 45 

Stack Trace: 

[NullReferenceException: Object reference not set to an instance of an
object.]
   System.Reflection.CustomAttribute.GetObject() +287

[CustomAttributeFormatException: ParameterStyle property specified was
not found.]
   System.Reflection.CustomAttribute.GetObject() +358
  
System.Reflection.CustomAttribute.CheckConsistencyAndCreateArray(CustomAttribute caItem, Type caType) +539
   System.Reflection.CustomAttribute.GetCustomAttributes(MemberInfo
member, Type caType, Boolean inherit) +453
   System.Reflection.RuntimeMethodInfo.GetCustomAttributes(Type
attributeType, Boolean inherit) +54
  
System.Web.Services.Protocols.LogicalMethodInfo.GetCustomAttributes(Type
type) +120
  
System.Web.Services.Protocols.SoapReflector.GetSoapMethodAttribute(LogicalMethodInfo methodInfo) +49
  
System.Web.Services.Protocols.SoapReflector.ReflectMethod(LogicalMethodInfo methodInfo, Boolean client, XmlReflectionImporter xmlImporter, SoapReflectionImporter soapImporter, String defaultNs) +133

[InvalidOperationException: Method CalculatorSoap.Div can not be
reflected.]
  
System.Web.Services.Protocols.SoapReflector.ReflectMethod(LogicalMethodInfo methodInfo, Boolean client, XmlReflectionImporter xmlImporter, SoapReflectionImporter soapImporter, String defaultNs) +5419
   System.Web.Services.Protocols.SoapClientType..ctor(Type type) +828
   System.Web.Services.Protocols.SoapHttpClientProtocol..ctor() +151
   Calc.CalculatorSoap..ctor() +10
   ASP.calculator_client_aspx.OnSubmit(Object sender, EventArgs e) in
d:\iishome\dsilva\calculator-client.aspx:45
   System.Web.UI.HtmlControls.HtmlInputButton.OnServerClick(EventArgs e)
+108
  
System.Web.UI.HtmlControls.HtmlInputButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +57
   System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
sourceControl, String eventArgument) +18
   System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
+33
   System.Web.UI.Page.ProcessRequestMain() +1277
"""


> (2) Compile all your code with csc.exe on a Windows box.  csc.exe knows
> about shared assemblies, and will properly reference against the
> appropriate .NET libraries.

Hmm ok.

> This is likely to remain a problem into the future, even after mcs gets
> proper public-key-token support and Mono gets a GAC.  As long as
> Microsoft and Mono use different public/private keys for assembly
> signing, .NET will want to use the Mono assemblies when executing
> mono/mcs-generated assemblies.  Such is the price of strong versioning. 
> Compatibility is largely one-way: Mono can execute most .NET-generated
> programs, but .NET might not be able to handle the Mono-generated ones.
> 

Thanks for your quick response.

Daniel