Change reference to mscorlib

[zehmueller]

Hi Jeroen
Hi All
I'd like to statically compile (ikvmc) a .net assembly (dll) from a jar file that I'd like to use in a silverlight application. A dll that can be used in silverlight needs to reference a special mscorlib dll (e.g. C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll) which is different that the standard .Net Framework mscorlib.dll.
Is there a way to instruct ikvmc to use the silverlight subset of the .Net framework instead of the "real" framework?
I wouldn't mind trying to fiddle around with the ikvm sources to do that, although this would probably generate a lot of subsequent questions ;-) - anyway - any suggestion that would require tweaking the ikvm sources is welcome as well.
Thanks for any hint
Chris

[Jeroen Frijters]

Hi Chris,

There is currently no Silverlight support (and I haven't really looked into it yet). I'm interested in this, but don't expect any short term work on it.

It should be fairly easy to hack IKVM.Reflection.Emit to write out assemblies that reference the Silverlight version of mscorlib instead of the desktop CLR, but it is currently impossible to actually use the Silverlight version of mscorlib in ikvmc (i.e. to get an error/warning if you reference a type/member that doesn't exist in Silverlight).

Regards,
Jeroen

> -----Original Message-----
> From: zehmueller [mailto:chrism@...]
> Sent: Monday, September 14, 2009 3:54 PM
> To: ikvm-developers@...
> Subject: [Ikvm-developers] Change reference to mscorlib
>
>
> Hi Jeroen
> Hi All
> I'd like to statically compile (ikvmc) a .net assembly (dll) from a jar
> file that I'd like to use in a silverlight application. A dll that can
> be used in silverlight needs to reference a special mscorlib dll (e.g.
> C:\Program Files\Reference
> Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll) which is
> different that the standard .Net Framework mscorlib.dll.
> Is there a way to instruct ikvmc to use the silverlight subset of the
> .Net framework instead of the "real" framework?
> I wouldn't mind trying to fiddle around with the ikvm sources to do
> that, although this would probably generate a lot of subsequent
> questions ;-) - anyway - any suggestion that would require tweaking the
> ikvm sources is welcome as well.
> Thanks for any hint
> Chris
> --
> View this message in context: http://www.nabble.com/Change-reference-
> to-mscorlib-tp25436172p25436172.html
> Sent from the IKVM .NET - Dev mailing list archive at Nabble.com.
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Ikvm-developers mailing list
> Ikvm-developers@...
> https://lists.sourceforge.net/lists/listinfo/ikvm-developers

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ikvm-developers mailing list
Ikvm-developers@...
https://lists.sourceforge.net/lists/listinfo/ikvm-developers

[zehmueller]

Hi Jeroen,
I tried toying around a bit with the ikvm source code to reference the Silverlight Framework DLLs (like mscorlib.dll) instead of the .Net Framework DLLs. I was able to build ikvm(c) and to debug into it. I also managed to alter the code to force ikvmc to only reference assemblies speciefied in the -reference parameters. This way, I thought I could force ikvmc to use a defined set of assemblies. But I ran into a couple of problems:

It turns out that Assembly.Load[From|ReflectionOnly...] completely refuses to load mscorlib, no matter if it is any of the .Net-Framework versions or the Silverlight version. In addition I found some places in the code where type references aren't generated from assemblies previously loaded with Assembly.Load[From|ReflectionOnly...] but with direct references from the currently running application. This means that a DLL generated by ikvmc will always reference the mscorlib.dll that was used to build ikvm.

When looking for a solution I stepped over Mono.Cecil which seems to be an alternative approach to inspect assemblies. It is capable of inspecting and reading type data from arbitrary assemblies, you can also read mscorlib.dll of other versions than the one currently used by the code. In addition it can read in, inspect, alter and emit IL code. It cannot, however, in contrast to System.Reflection, dynamically invoke methods on the inspected assembly.

I thought about writing a wrapper library that has about the same interface as System.Reflection but implements all the functionality internally using Mono.Cecil. I already spent 2 days writing that library, but I guess this is going to be a bigger project... Before really investing into that I would like to ask you a couple of questions.

1. Do you see any general problem with using Mono.Cecil for inspecting referenced DLLs.

2. Do you see any problem with the fact that Mono.Cecil has no equivalent for MethodInfo.Invoke?

3. I did not yet fully understand how ikvmc emits code. There seems to be a self-written emitter, but I can also see System.Reflection.Emit calls. When trying to write a wrapper that emulates System.Reflection, do you think it is necessary to wrap System.Reflection.Emit as well or could we use ikvm's self-written IL-code emitter?
The easier way would be to only wrap System.Reflection's Assembly-inspection functionality and leave the Emit functionality to something already self-implemented. If, however, we cannot get around using System.Reflection.Emit, I would need to wrap the Emit functionality, too. So, if you see a way how ikvm(c) can already work now without using System.Reflection.Emit functionality, I'd be glad for some hints how to do that.

Thanks a lot for your answer,
Chris

zehmueller wrote:

Hi Jeroen
Hi All
I'd like to statically compile (ikvmc) a .net assembly (dll) from a jar file that I'd like to use in a silverlight application. A dll that can be used in silverlight needs to reference a special mscorlib dll (e.g. C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll) which is different that the standard .Net Framework mscorlib.dll.
Is there a way to instruct ikvmc to use the silverlight subset of the .Net framework instead of the "real" framework?
I wouldn't mind trying to fiddle around with the ikvm sources to do that, although this would probably generate a lot of subsequent questions ;-) - anyway - any suggestion that would require tweaking the ikvm sources is welcome as well.
Thanks for any hint
Chris

[Jeroen Frijters]

Hi Chris,

OK, you forced my hand :-) I didn't yet want to publish this, but at this exact moment I'm working on IKVM.Reflection (to go with IKVM.Reflection.Emit) to solve this problem. This also solves some ugly edges of IKVM.Reflection.Emit having to integrate with System.Reflection.

After the 0.42 release of IKVM (don't know yet when that will be), I plan to merge in this work.

My previous suggestion was to simply hack IKVM.Reflection.Emit to substitute any references to the desktop CLR version of mscorlib with the Silverlight version. I think this should be possible and fairly easy (look into ImportAssemblyRef in /ikvm/refemit/ModuleBuilder.cs).

In response to 3: Yes, ikvmc uses a self written implementation of the System.Reflection.Emit API called IKVM.Reflection.Emit (see /ikvm/refemit/) to workaround the various bugs in System.Reflection.Emit.

I also looked at Mono.Cecil, but it didn't have either the quality or performance level I needed. See my blog entries:
http://weblog.ikvm.net/CommentView.aspx?guid=c8ee66de-d82a-4383-a285-bef105972b9f
http://weblog.ikvm.net/CommentView.aspx?guid=afda88af-e2cf-47d6-917b-5f3134b681c1

Regards,
Jeroen

> -----Original Message-----
> From: zehmueller [mailto:chrism@...]
> Sent: Tuesday, September 22, 2009 4:20 PM
> To: ikvm-developers@...
> Subject: Re: [Ikvm-developers] Change reference to mscorlib
>
>
> Hi Jeroen,
> I tried toying around a bit with the ikvm source code to reference the
> Silverlight Framework DLLs (like mscorlib.dll) instead of the .Net
> Framework
> DLLs. I was able to build ikvm(c) and to debug into it. I also managed
> to
> alter the code to force ikvmc to only reference assemblies speciefied
> in the
> -reference parameters. This way, I thought I could force ikvmc to use a
> defined set of assemblies. But I ran into a couple of problems:
>
> It turns out that Assembly.Load[From|ReflectionOnly...] completely
> refuses
> to load mscorlib, no matter if it is any of the .Net-Framework versions
> or
> the Silverlight version. In addition I found some places in the code
> where
> type references aren't generated from assemblies previously loaded with
> Assembly.Load[From|ReflectionOnly...] but with direct references from
> the
> currently running application. This means that a DLL generated by ikvmc
> will
> always reference the mscorlib.dll that was used to build ikvm.
>
> When looking for a solution I stepped over Mono.Cecil which seems to be
> an
> alternative approach to inspect assemblies. It is capable of inspecting
> and
> reading type data from arbitrary assemblies, you can also read
> mscorlib.dll
> of other versions than the one currently used by the code. In addition
> it
> can read in, inspect, alter and emit IL code. It cannot, however, in
> contrast to System.Reflection, dynamically invoke methods on the
> inspected
> assembly.
>
> I thought about writing a wrapper library that has about the same
> interface
> as System.Reflection but implements all the functionality internally
> using
> Mono.Cecil. I already spent 2 days writing that library, but I guess
> this is
> going to be a bigger project... Before really investing into that I
> would
> like to ask you a couple of questions.
>
> 1. Do you see any general problem with using Mono.Cecil for inspecting
> referenced DLLs.
>
> 2. Do you see any problem with the fact that Mono.Cecil has no
> equivalent
> for MethodInfo.Invoke?
>
> 3. I did not yet fully understand how ikvmc emits code. There seems to
> be a
> self-written emitter, but I can also see System.Reflection.Emit calls.
> When
> trying to write a wrapper that emulates System.Reflection, do you think
> it
> is necessary to wrap System.Reflection.Emit as well or could we use
> ikvm's
> self-written IL-code emitter?
> The easier way would be to only wrap System.Reflection's Assembly-
> inspection
> functionality and leave the Emit functionality to something already
> self-implemented. If, however, we cannot get around using
> System.Reflection.Emit, I would need to wrap the Emit functionality,
> too.
> So, if you see a way how ikvm(c) can already work now without using
> System.Reflection.Emit functionality, I'd be glad for some hints how to
> do
> that.
>
> Thanks a lot for your answer,
> Chris
>
>
> zehmueller wrote:
> >
> > Hi Jeroen
> > Hi All
> > I'd like to statically compile (ikvmc) a .net assembly (dll) from a
> jar
> > file that I'd like to use in a silverlight application. A dll that
> can be
> > used in silverlight needs to reference a special mscorlib dll (e.g.
> > C:\Program Files\Reference
> > Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll) which
> is
> > different that the standard .Net Framework mscorlib.dll.
> > Is there a way to instruct ikvmc to use the silverlight subset of the
> .Net
> > framework instead of the "real" framework?
> > I wouldn't mind trying to fiddle around with the ikvm sources to do
> that,
> > although this would probably generate a lot of subsequent questions
> ;-) -
> > anyway - any suggestion that would require tweaking the ikvm sources
> is
> > welcome as well.
> > Thanks for any hint
> > Chris
> >
>
> --
> View this message in context: http://www.nabble.com/Change-reference-
> to-mscorlib-tp25436172p25530753.html
> Sent from the IKVM .NET - Dev mailing list archive at Nabble.com.
>
>
> -----------------------------------------------------------------------
> -------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Ikvm-developers mailing list
> Ikvm-developers@...
> https://lists.sourceforge.net/lists/listinfo/ikvm-developers

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ikvm-developers mailing list
Ikvm-developers@...
https://lists.sourceforge.net/lists/listinfo/ikvm-developers

[zehmueller]

Hi Jeroen,

thanks a lot for that information. I should have asked earlier :-) I'll try your "hack" approach to toy around and see if I can generally create a silverlight-enabled dll with a rather small references footprint. If that works I'm looking forward to your upcoming release with an unlimited System.Reflection replacement. That way it should become easy to add functionality to ikvmc that will allow users to specify a self-defined set of Framework and base libraries.

Thanks again,
Chris

Jeroen Frijters <jeroen@...> hat am 22. September 2009 um 16:45 geschrieben:

> Hi Chris,
>
> OK, you forced my hand :-) I didn't yet want to publish this, but at this exact moment I'm working on IKVM.Reflection (to go with IKVM.Reflection.Emit) to solve this problem. This also solves some ugly edges of IKVM.Reflection.Emit having to integrate with System.Reflection.
>
> After the 0.42 release of IKVM (don't know yet when that will be), I plan to merge in this work.
>
> My previous suggestion was to simply hack IKVM.Reflection.Emit to substitute any references to the desktop CLR version of mscorlib with the Silverlight version. I think this should be possible and fairly easy (look into ImportAssemblyRef in /ikvm/refemit/ModuleBuilder.cs).
>
> In response to 3: Yes, ikvmc uses a self written implementation of the System.Reflection.Emit API called IKVM.Reflection.Emit (see /ikvm/refemit/) to workaround the various bugs in System.Reflection.Emit.
>
> I also looked at Mono.Cecil, but it didn't have either the quality or performance level I needed. See my blog entries:
> http://weblog.ikvm.net/CommentView.aspx?guid=c8ee66de-d82a-4383-a285-bef105972b9f
> http://weblog.ikvm.net/CommentView.aspx?guid=afda88af-e2cf-47d6-917b-5f3134b681c1
>
> Regards,
> Jeroen
>
> > -----Original Message-----
> > From: zehmueller [mailto:chrism@...]
> > Sent: Tuesday, September 22, 2009 4:20 PM
> > To: ikvm-developers@...
> > Subject: Re: [Ikvm-developers] Change reference to mscorlib
> >
> >
> > Hi Jeroen,
> > I tried toying around a bit with the ikvm source code to reference the
> > Silverlight Framework DLLs (like mscorlib.dll) instead of the .Net
> > Framework
> > DLLs. I was able to build ikvm(c) and to debug into it. I also managed
> > to
> > alter the code to force ikvmc to only reference assemblies speciefied
> > in the
> > -reference parameters. This way, I thought I could force ikvmc to use a
> > defined set of assemblies. But I ran into a couple of problems:
> >
> > It turns out that Assembly.Load[From|ReflectionOnly...] completely
> > refuses
> > to load mscorlib, no matter if it is any of the .Net-Framework versions
> > or
> > the Silverlight version. In addition I found some places in the code
> > where
> > type references aren't generated from assemblies previously loaded with
> > Assembly.Load[From|ReflectionOnly...] but with direct references from
> > the
> > currently running application. This means that a DLL generated by ikvmc
> > will
> > always reference the mscorlib.dll that was used to build ikvm.
> >
> > When looking for a solution I stepped over Mono.Cecil which seems to be
> > an
> > alternative approach to inspect assemblies. It is capable of inspecting
> > and
> > reading type data from arbitrary assemblies, you can also read
> > mscorlib.dll
> > of other versions than the one currently used by the code. In addition
> > it
> > can read in, inspect, alter and emit IL code. It cannot, however, in
> > contrast to System.Reflection, dynamically invoke methods on the
> > inspected
> > assembly.
> >
> > I thought about writing a wrapper library that has about the same
> > interface
> > as System.Reflection but implements all the functionality internally
> > using
> > Mono.Cecil. I already spent 2 days writing that library, but I guess
> > this is
> > going to be a bigger project... Before really investing into that I
> > would
> > like to ask you a couple of questions.
> >
> > 1. Do you see any general problem with using Mono.Cecil for inspecting
> > referenced DLLs.
> >
> > 2. Do you see any problem with the fact that Mono.Cecil has no
> > equivalent
> > for MethodInfo.Invoke?
> >
> > 3. I did not yet fully understand how ikvmc emits code. There seems to
> > be a
> > self-written emitter, but I can also see System.Reflection.Emit calls.
> > When
> > trying to write a wrapper that emulates System.Reflection, do you think
> > it
> > is necessary to wrap System.Reflection.Emit as well or could we use
> > ikvm's
> > self-written IL-code emitter?
> > The easier way would be to only wrap System.Reflection's Assembly-
> > inspection
> > functionality and leave the Emit functionality to something already
> > self-implemented. If, however, we cannot get around using
> > System.Reflection.Emit, I would need to wrap the Emit functionality,
> > too.
> > So, if you see a way how ikvm(c) can already work now without using
> > System.Reflection.Emit functionality, I'd be glad for some hints how to
> > do
> > that.
> >
> > Thanks a lot for your answer,
> > Chris
> >
> >
> > zehmueller wrote:
> > >
> > > Hi Jeroen
> > > Hi All
> > > I'd like to statically compile (ikvmc) a .net assembly (dll) from a
> > jar
> > > file that I'd like to use in a silverlight application. A dll that
> > can be
> > > used in silverlight needs to reference a special mscorlib dll (e.g.
> > > C:\Program Files\Reference
> > > Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll) which
> > is
> > > different that the standard .Net Framework mscorlib.dll.
> > > Is there a way to instruct ikvmc to use the silverlight subset of the
> > .Net
> > > framework instead of the "real" framework?
> > > I wouldn't mind trying to fiddle around with the ikvm sources to do
> > that,
> > > although this would probably generate a lot of subsequent questions
> > ;-) -
> > > anyway - any suggestion that would require tweaking the ikvm sources
> > is
> > > welcome as well.
> > > Thanks for any hint
> > > Chris
> > >
> >
> > --
> > View this message in context: http://www.nabble.com/Change-reference-
> > to-mscorlib-tp25436172p25530753.html
> > Sent from the IKVM .NET - Dev mailing list archive at Nabble.com.
> >
> >
> > -----------------------------------------------------------------------
> > -------
> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> > now&#33;
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Ikvm-developers mailing list
> > Ikvm-developers@...
> > https://lists.sourceforge.net/lists/listinfo/ikvm-developers

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ikvm-developers mailing list
Ikvm-developers@...
https://lists.sourceforge.net/lists/listinfo/ikvm-developers