Note: This question is duplicated on StackOverflow at http://stackoverflow.com/questions/15140280/is-it-possible-to-internalize-castle-projects-dynamicproxy-classes-using-ilmerg. I'm asking here to hopefully engage a more targeted audience.
I have a .NET library that internally has a dependency on Castle.Core.dll, since I use Castle's DynamicProxy to perform interception of method calls for custom processing. Because my assembly is strongly-named, I want to use ILMerge to combine all of my dependencies into a single assembly for deployment, internalizing the types of my dependencies so as to not expose them unnecessarily to my consumers. This is particularly important for the NuGet case, where if my assembly is strongly-named, I have to set my package dependencies to the *specific* version of the dependency, or the assembly name resolution breaks, because Castle.Core.dll is also strongly-named. Note that releasing my project as a strongly-named assembly is a feature valued by my users, so removing the strong-name is not an option. Apparently, DynamicProxy requires some of its classes to be public to work properly. No problem, I can exclude certain types from being internalized by ILMerge. However, problems occur when I have a user who references my library, but also references Castle.Core.dll. The public types are now provided by two assemblies, and references to types found in Castle.Core.dll are ambiguous. If I don't internalize Castle.Core.dll using ILMerge, shipping it alongside my own assembly, which risks version conflicts between my version and my users' versions. If I use ILMerge to internalize the assembly, I'm forced to exclude internalizing the types that DynamicProxy requires to work properly. This approach will break any project that references both my assembly and Castle.Core.dll because of the ambiguous types. Am I forced into one of these two suboptimal courses of action? Or is there some solution I've not yet thought of? I suppose I could dig into the code of DynamicProxy and try to submit a patch or bending its code to do exactly what I need it to do, but that seems very much like reinventing the wheel to me. --Jim -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/castle-project-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
