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