[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