Dino Viehland wrote:
For some reason the re-write didn't work. After the re-write the new binary in ildasm
should have a manifest that looks like:
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 2:0:5:0
}
.assembly extern Microsoft.Scripting
{
.publickeytoken = (31 BF 38 56 AD 36 4E 35 )
.ver 0:9:5:0
}
.assembly extern IronPython
{
.publickeytoken = (31 BF 38 56 AD 36 4E 35 )
.ver 2:0:5:0
}
.assembly extern Microsoft.Scripting.Core
{
.publickeytoken = (31 BF 38 56 AD 36 4E 35 )
.ver 0:9:5:0
}
Where the key part is the 5's in all of the version strings. I did:
ildasm froob.dll /out:froob.txt
[updated version numbers]
ilasm /DLL froob.txt /resource:froob.res /out:froob2.dll
and it seems to work.
Hmm... after I do the rewrite I *still* get the exception once I import
from the assembly ("from froob import Smoog"). I wonder if this is
because I'm on 64bit Vista?
SystemError: Could not load type
'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly
'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'.app.py
Michael Foord
-----Original Message-----
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, April 21, 2009 4:02 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
Do you have a simple repro XAP you can send me and I'll take a look?
I'm not entirely sure I'll know what's going on as CoreCLR isn't the
CLR I'm used to debugging but it's not that different :)
Attached is a xap file. It has a very simple package compiled with Pyc
- and importing it throws the same error.
Michael
-----Original Message-----
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, April 21, 2009 2:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
You're compiling to a DLL and then trying to import (vs compiling
to
an EXE)?
Yes - it's support packages we're trying to compile. I would have
thought that compiling an exe for Silverlight was a lost cause... :-
)
There are two motivations, mainly speeding up import time but also
source code obfuscation. If the assembly is genuinely serializable
then we may at least achieve the second, so long as it doesn't make
import time worse.
Michael
-----Original Message-----
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, April 20, 2009 3:07 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Michael Foord wrote:
Jb Evain wrote:
Hey Michael,
On 4/20/09, Michael Foord <fuzzy...@voidspace.org.uk> wrote:
I guess a full IL writer would be needed - which means back to
Cecil and the like and seeing if parts of them could be run on
Silverlight.
*sigh*
You just want to change the references to an assembly from the
desktop
version to the SL version? With Cecil it's like:
var assembly = AssemblyFactory.GetAssembly (file); foreach (var
reference in assembly.MainModule.AssemblyReferences)
{
if (!IsTargetAssembly (reference))
continue;
reference.Version = new Version (2, 0, 5, 0); }
AssemblyFactory.SaveAssembly (assembly, file);
Now it doesn't guarantee that the resulting assembly is
coherent,
visibility wise, as you may have used methods that are not
visible
or
not existent in SL.
Thanks for that - if it would work it would be really useful,
however...
I think I've done the equivalent of this using ildasm / ilasm.
I've disassembled the assembly to IL, then replaced the
references
with
the
references to Silverlight assemblies and re-assembled.
The resulting assembly throws exactly the same error - which
makes
me
think that the assemblies compiled by Pyc are using things that
aren't
available in Silverlight. *However* -
Microsoft.Runtime.CompilerServices.StrongBox does exist in
Silverlight. I think I'll try the whole process again just to
see.
My
guess is that rewriting would require an intimate knowledge of
the
differences between the CoreCLR and standard .NET.
No - I've rerun the whole process from compiling with Pyc through
to replacing the references in the il and reassembling. Same
error.
Shame.
SystemError: Could not load type
'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly
'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'.app.py
Michael Foord
I can't import it in a Silverlight application though (the
following
code does work on the desktop version of IronPython):
import clr
clr.AddReference('Microsoft.Scripting')
clr.AddReference('Microsoft.Scripting.Core')
from Microsoft.Runtime.CompilerServices import StrongBox
ImportError: No module named Runtime
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
