Conflicting Castle reference

[gregsaab]

It would be great if the nuget package depended on Castle.Core and the aforementioned library was not merged into NSub's dll. This issue was referenced at: http://stackoverflow.com/questions/12266279/how-to-fix-type-exists-in-both-assemblies-failure-when-using-dynamicproxy-type

[dtchepak]

I'm happy for someone to setup a non-merged version in the build. I'd like to keep the ilmerged package as well though, as both approaches have their own drawbacks (example).

To work around the current issue you could try using a namespace alias.

[jrnail23]

@dtchepak, I just hit this same problem myself, interestingly I was doing the exact same thing @gregnehus was trying to do in his SO question.
Unfortunately namespace alias doesn't help this scenario.
The problem is that the if you have both Castle.Core and NSubstiture referenced in the same project, then you have two separately defined types with completely identical type names, including the full namespace. The compiler can't figure out which Castle.DynamicProxy.IProxyTargetAccessor we're trying to use.

Perhaps there's a way to make NSubstitute's usage of IProxyTargetAccessor internal, such that the type doesn't have to be visible to consuming projects? I see that you're explicitly listing it in your ilmerge.exclude file, although never having done any IL merging myself, I have no idea what the implications are either way.

[jrnail23]

Per this blog post (http://www.davidarno.org/c-howtos/aliases-overcoming-name-conflicts-part-2-extern-alias/), apparently the work around is to use extern alias
I did it and it worked.

[dtchepak]

Closing as NSubstitute 3.0 no longer ilmerges dependencies. 2.x works with extern alias.