MonoXna.Internal library - was MonoXna mouse scroll
Jordan Justen
> First off, thanks for investigating this problem.
>
> But, if we are going to continue discussing this subject, you should
> create a new post with a more suitable subject.
Well, the current motivation was to find a solution to the mouse
scroll issue. :)
So, based on the fact that InternalsVisibleTo will not work with XNA's
2048 bit keys until mono 2.10, is it acceptable to consider a
MonoXna.Internal library to allow private data sharing between the
MonoXna's XNA compatible libraries?
Would another name, such as MonoXna.dll be preferable?
Thanks,
-Jordan
> On Wed, Jun 8, 2011 at 9:49 AM, Jordan Justen <jlju...@gmail.com> wrote:
>> On Sun, Jun 5, 2011 at 23:09, Lars Magnusson <lav...@gmail.com> wrote:
>>> The keys was created by timpambor at one point (along with delayed
>>> signing in the mono framework), but I've never been able to get it to
>>> work properly. I haven't had the time to investigate myself, but I
>>> think there might be an open issue relating to the subject.
>>
>> After further investigation, the issue seems to be a bug in mono where
>> perhaps only 1024 bit keys work properly. The XNA keys are 2048 bit.
>>
>> Here is the commit the mono commit that should fix things:
>> https://github.com/mono/mono/commit/8dab9d20d4d5a
>>
>> And the bug report:
>> https://bugzilla.novell.com/show_bug.cgi?id=664618
>>
>> The developer of the commit above confirmed that this should fix the
>> 2048 bit key issue, and that it should be released in mono 2.10.
>> Unfortunately that means a lot of systems will not have the fix for
>> quite some time.
>>
>> Once again, I think it would be good to consider a separate assembly
>> that the public XNA DLLs could depend on.
>>
>> Thanks,
>>
>> -Jordan
Lars Magnusson
didn't create a new post).
I would much rather prefer that we skip the (non working) signing and
use the attribute I mentioned in the previous post to circumvent the
problem. I see no reason to add a dedicated assembly for this purpose.
Please update the issue at
http://code.google.com/p/monoxna/issues/detail?id=68 with the
information you provided in your last post, and I'll remove the
signing (for now).
-lavima
> --
> You received this message because you are subscribed to the Google Groups "MonoXNA" group.
> To post to this group, send email to mon...@googlegroups.com.
> To unsubscribe from this group, send email to monoxna+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
>
>
Jordan Justen
> I would much rather prefer that we skip the (non working) signing and
> use the attribute I mentioned in the previous post to circumvent the
> problem. I see no reason to add a dedicated assembly for this purpose.
>
> Please update the issue at
> http://code.google.com/p/monoxna/issues/detail?id=68 with the
> information you provided in your last post, and I'll remove the
> signing (for now).
This is not the change I would recommend based on my investigation.
As far as I have seen, the signing is working reasonably well when
using the XNA public keys. I did find that if I build an application
with MonoXna, and then run it with XNA, it will only work properly if
the (current) XNA 2048 bit keys are used.
The only issue that I have seen with the 2048 bit keys is that the
InternalsVisibleTo attribute does not work.
It sounds like bug #68 above might be that someone:
1. Built an XNA application on Windows, and
2. Tried to run it on MonoXna.
Let me try this out before you consider removing the current signing.
-Jordan
Lars Magnusson
whole purpose of the keys are to make them binary compatible with MS
XNA, which they currently do not.
Regarding the issue #68. This is supposed to be supported. MonoXNA
aspires to be binary compatible with MS XNA.
-lavima
Jordan Justen
> What do you mean that the signing is working reasonably well? The
> whole purpose of the keys are to make them binary compatible with MS
> XNA, which they currently do not.
What is the evidence that the signing does not work? If it is bug 68,
has this been confirmed?
My investigations are not pointing out an issue with the signing
process. Rather, the issue is with mono's class library.
> Regarding the issue #68. This is supposed to be supported. MonoXNA
> aspires to be binary compatible with MS XNA.
Yes, this compatibility seems to be a critical part of MonoXna. Have
you been able to reproduce issue 68 personally?
What I can say is I confirmed that if I build under mono with MonoXna,
then the game will run under MS XNA.
This will seem obvious, but I can also confirm that building under
MonoXna will run under MonoXna.
The last case is to build under MS XNA, and make sure MonoXna will run
the game. I think issue 68 says this does not work, but I'd like to
verify it.
If you change the keys, then you will break the 'build under MonoXna
and then run under MS XNA' case, and I don't think this is good
either.
-Jordan