[Mono-devel-list] mono and .net web services
jonpryor at vt.edu
Thu Jan 15 07:36:55 EST 2004
Alas, I can only answer one of your questions...
On Wed, 2004-01-14 at 22:26, Daniel Pinto de Mello e Silva wrote:
> 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.
> 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.
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.
(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.
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.
More information about the Mono-devel-list