On Wed, Jun 8, 2011 at 11:25, Lars Magnusson <lav...@gmail.com> wrote: > 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?
> On Wed, Jun 8, 2011 at 9:49 AM, Jordan Justen <jljus...@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.
>> 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.
Ok. Now I think I know where you are coming from (and probably why you 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.
On Wed, Jun 8, 2011 at 10:36 PM, Jordan Justen <jljus...@gmail.com> wrote: > On Wed, Jun 8, 2011 at 11:25, Lars Magnusson <lav...@gmail.com> wrote: >> 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 <jljus...@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.
>>> 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
> -- > You received this message because you are subscribed to the Google Groups "MonoXNA" group. > To post to this group, send email to monoxna@googlegroups.com. > To unsubscribe from this group, send email to monoxna+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
On Wed, Jun 8, 2011 at 15:02, Lars Magnusson <lav...@gmail.com> wrote: > 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.
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.
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.
Regarding the issue #68. This is supposed to be supported. MonoXNA aspires to be binary compatible with MS XNA.
On Thu, Jun 9, 2011 at 1:33 AM, Jordan Justen <jljus...@gmail.com> wrote: > On Wed, Jun 8, 2011 at 15:02, Lars Magnusson <lav...@gmail.com> wrote: >> 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.
> 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
> -- > You received this message because you are subscribed to the Google Groups "MonoXNA" group. > To post to this group, send email to monoxna@googlegroups.com. > To unsubscribe from this group, send email to monoxna+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
On Wed, Jun 8, 2011 at 22:15, Lars Magnusson <lav...@gmail.com> wrote: > 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.
> On Thu, Jun 9, 2011 at 1:33 AM, Jordan Justen <jljus...@gmail.com> wrote: >> On Wed, Jun 8, 2011 at 15:02, Lars Magnusson <lav...@gmail.com> wrote: >>> 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.
>> 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
>> -- >> You received this message because you are subscribed to the Google Groups "MonoXNA" group. >> To post to this group, send email to monoxna@googlegroups.com. >> To unsubscribe from this group, send email to monoxna+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "MonoXNA" group. > To post to this group, send email to monoxna@googlegroups.com. > To unsubscribe from this group, send email to monoxna+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
