Kenny is right.
Keeping these specific resource assemblies out of the mkbundle output seems
to be the way to go. Should work since an mkbundled app still looks for
referenced assemblies both in the bundle and in the regular search paths
(gac, execution directory, etc).
regards,
Yoni.
On Mon, D
Laurent,
I don't think that is the case.
Mono can deal with multiple cultures of an assembly.
My test app works without any issues, as long as I don't mkbundle it.
The problem is that mkbundle refuses to bundle 2 resource dlls (it
doesn't see the difference between the 2 ==> embedding 2 identi
Hello,
I came to the same conclusion after some testing. I thought that there was
something missing in Monobjc, but it appears that there is huge limitation
in the embedding API of the Mono runtime.
In the "mono/metadata/assembly.c", the "mono_assembly_open_from_bundle" is
responsible for loading
Hi,
As you said it might've been caused by MonobjC, I just tested some
more, to see if I could rule out MonobjC/determine for sure it was
MonobjC.
So, I compiled my application using Visual Studio.
And did mkbundle manually on the commandline (instead of using the
MonobjC NAnt task).
So
Hello,
I think this is a Monobjc issue, because the name of the satellite
assemblies is mis-generated during the assembly phase. I have already make
some corrections to handle assembly name with space, but I have missed the
satellite case.
I will try to give it a try this week-end.
Regards, Laur
5 matches
Mail list logo
