[Mono-dev] List of referenced assemblies

Vassil Vassilev v.g.vassilev at gmail.com
Wed Nov 27 08:18:41 UTC 2013


Hi Rafael,
   Thanks for the pointer it looks exactly what we need!
Cheers,
Vassil
On 11/26/2013 12:05 PM, Rafael Teixeira wrote:
> Fat Libraries would play havoc with library signatures/versioning. 
> What Mono has is mkbundle, where all managed libraries (but not the 
> native dependencies) are packaged in a single executable (huge) file.
>
> See the Bundles section in
> http://www.mono-project.com/Guide:Running_Mono_Applications
>
> Hope it helps,
> Rafael Teixeira
> O..:.)oooo
>
>
> On Mon, Nov 25, 2013 at 2:17 PM, Vassil Vassilev 
> <v.g.vassilev at gmail.com <mailto:v.g.vassilev at gmail.com>> wrote:
>
>     Is there any obvious advantage of ilmerge over adding all relevant
>     files when building that library. I.e expanding the references. I
>     can afford that because in our home-grown cmake csharp module
>     keeps track of the dependencies.
>     Vassil
>
>     On 11/25/2013 04:58 PM, Greg Young wrote:
>>     Search for "ilmerge" it can do this after the compilation.
>>
>>
>>     On Mon, Nov 25, 2013 at 5:27 PM, Vassil Vassilev
>>     <v.g.vassilev at gmail.com <mailto:v.g.vassilev at gmail.com>> wrote:
>>
>>         Hi,
>>           Thanks for the answer. This seemed not to be the case with
>>         the M$ compiler. I will double check today.
>>           Is there any way to build 'fat libraries' (standalone) i.e
>>         to tell the compiler to put everything that the library needs
>>         (of course not mscorlib) in the library itself?
>>         Cheers,
>>         Vassil
>>
>>         On 11/25/2013 12:19 PM, Rafael Teixeira wrote:
>>>         That is the rule because the compiler need to know the
>>>         details of the Interface that is defined A because it is
>>>         being used publicly as your public class implements it.
>>>
>>>         As assembly references aren't transitive you need to be
>>>         explicit (to embed proper dependency versioning metadata)
>>>         about which library you are referencing types from.
>>>
>>>         Note that if your type MyClass had just a private field of
>>>         that interface type, for instance, of if MyClass was in the
>>>         internal instead of public scope the compiler would not need
>>>         to have access to library A, but nevertheless your running
>>>         app would need to have it available to load and execute code
>>>         in library B.
>>>
>>>         Hope it helps,
>>>
>>>         Rafael Teixeira
>>>         O..:.)oooo
>>>
>>>
>>>         On Sat, Nov 23, 2013 at 1:32 PM, Vassil Vassilev
>>>         <v.g.vassilev at gmail.com <mailto:v.g.vassilev at gmail.com>> wrote:
>>>
>>>             Hi,
>>>               A silly question:
>>>               I have interface IInterface defined in a library A.
>>>               I have a class(generic) MyClass, implementing that
>>>             interface in library B.
>>>               I have a user of MyClass (the place I do new
>>>             MyClass<sometype>()), when trying to compile the code
>>>             using MyClass it tells me that I need to include not
>>>             only B but A as well. To me that is strange... Is there
>>>             a way to workaround this problem? Am I doing something
>>>             wrong?
>>>             Many thanks,
>>>             Vassil
>>>             _______________________________________________
>>>             Mono-devel-list mailing list
>>>             Mono-devel-list at lists.ximian.com
>>>             <mailto:Mono-devel-list at lists.ximian.com>
>>>             http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>
>>
>>         _______________________________________________
>>         Mono-devel-list mailing list
>>         Mono-devel-list at lists.ximian.com
>>         <mailto:Mono-devel-list at lists.ximian.com>
>>         http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>>
>>
>>     -- 
>>     Le doute n'est pas une condition agréable, mais la certitude est
>>     absurde.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20131127/5df847b1/attachment-0001.html>


More information about the Mono-devel-list mailing list