Re: java -> ikvm -> ilmerge (internalize) -> dll

Jeroen Frijters <[email protected]> Mon, 22 Dec 2014 13:39:17 +0000
Newsgroups gmane.comp.java.ikvm.devel
Message-ID <[email protected]>
If you run ikvmc without any parameters, it prints a help text that describes all the options.

> -----Original Message-----
> From: Ryan, Brent [mailto:[email protected]]
> Sent: Monday, December 22, 2014 14:26
> To: Jeroen Frijters
> Cc: [email protected]
> Subject: Re: java -> ikvm -> ilmerge (internalize) -> dll
> 
> Awesome. I'll give that a try. I didn't see this documented any place.
> Am I missing something?
> 
> Sent from my iPhone
> 
> > On Dec 22, 2014, at 3:10 AM, Jeroen Frijters <[email protected]>
> wrote:
> >
> > Hi Brent,
> >
> > You should be able to use the ikvmc option -privatepackage:<prefix> to
> do what you want. There is also the -publicpackage:<prefix> option, if
> you only want a specific package to be public. Note that both options
> can be specified multiple times if you want multiple packages to be
> private/public.
> >
> > Using ILMerge (or really any other assembly post processing tool) with
> IKVM assemblies is not supported.
> >
> > Regards,
> > Jeroen
> >
> >> -----Original Message-----
> >> From: Ryan, Brent [mailto:[email protected]]
> >> Sent: Sunday, December 21, 2014 22:08
> >> To: [email protected]
> >> Subject: [Ikvm-developers] java -> ikvm -> ilmerge (internalize) ->
> >> dll
> >>
> >> One feature of ikvm we'd like to have is the ability to internalize
> >> all of the dependencies of the dll we generate via IKVM.  Is this
> >> supported or do we still need to put our build process through
> >> ILMerge with internalize options to get this?
> >>
> >> The main reason we want to do this is that we have 2 or more java
> >> projects that we're spitting out IKVM dll files from and each of
> >> these DLLs have some of the same/shared dependencies between them,
> >> but these dependencies are only used internally to the DLL and not
> >> directly by our C# codebase.  In theory, if we could just internalize
> >> these dependencies then these conflicts would go away.
> >>
> >> Any recommendations on how to best solve this problem?
> >>
> >> The options we've come up with so far are: 1) try to extract all of
> >> the common stuff into a set of common dll files  2) Try to use extern
> >> alias features of C#  3) ILMerge with internalize support.  It seems
> >> like option 3 would be the best if it worked.
> >>
> >> --
> >> Brent Ryan
> >> Enterprise Architect
> >> skype: brent.ryan
> >> mobile: 480.229.1001

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk