Replying to my own post, simply to say there's no urgency on the issue anymore. I've changed my project to no longer use DynamicProxy or the Castle projects.
On Friday, March 1, 2013 2:27:23 PM UTC-5, Jim Evans wrote: > > 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.
