[Mono-dev] Strong-named assembly built with Linux Mono not working with Windows VB Web Application

[Dean Brettle]

On Tue, Sep 30, 2008 at 1:20 AM, Rolf Bjarne Kvinge <rolflists at ya.com>wrote:

>  This seems to be a MS bug (their VB compiler refuses to accept an
> assembly their own tools say is valid, and only under certain
> circumstances),
>

I'm not so sure.  See below...


> in any case here is a couple of ideas how to debug:
>
> 1.       You say the C# assembly is built and signed using Mono, but
> happens if you build with Mono and sign with MS (and vice versa)?
>
I get the same error.

>  2.       Use ildasm (MS tool) to dump both C# assemblies to disk and
> compare the files. You'll probably get a lot of noise here though.
>
To cut down on the noise, I replicated the problem with an assembly that
just contains an absolutely minimal custom web control.  I then compared
monodis output on versions built with both Mono and with .NET.  With no
options, the output is essentially the same (modulo ordering).  However,
when using monodis --assembly, I noticed the following difference:

[mono20] ~/tmp/mywebcontrol @ monodis --assembly
MyWebControlProject.Mono.dll | grep Flags
Flags:         0x00000000
[mono20] ~/tmp/mywebcontrol @ monodis --assembly MyWebControlProject.Net.dll
| grep Flags
Flags:         0x00000001

Since this is a strong-named assembly containing the public key, isn't
0x00000001 the correct value for Flags?  If MS's VB.NET compiler requires
that flag to be set for strong-named assemblies, then that would explain the
problem.

I'd like to test that hypothesis by changing the Flags value, but I don't
know how to do that off-hand.  Using .NET's sn.exe to resign the assembly
built with Mono, didn't change the Flags value.

> 3.       Try to compile the VB Web Site Project from the command line
> and/or using codedom to see if you can replicate the issue.
>
At this point, I'm using a minimal VB Web Application project and web
control and the problem is very reproducible, so I don't think going to the
command line and/or codedom is likely to be worth the effort.

> 4.       File a bug with MS (good luck with this one J)
>
Seems more likely to be a Mono bug at the moment...  That's good news to me,
since that greatly increases the odds of it getting fixed. :-)

Anyway, can someone point me to the code that creates/writes the assembly
table, so I can try making the necessary change and seeing if it solves the
problem?

Thanks,
--Dean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081001/db87e2ea/attachment.html