I have a small library I've written of various random extension methods. Recently I rolled a few WPF FrameworkElement
extension methods into it, but found myself getting compiler errors in another project (console application) that used my library because now it wanted references to several WPF related assemblies (cannot find FrameworkElement, etc etc). This project doesn't call any of the methods that involve FrameworkElement
.
As my extension method library grows, I'd prefer that I didn't have to break it into several small assemblies, nor do I want to add a bunch of references to WPF assemblies in non-WPF projects. Is there a way to handle this, or am I just going to have to break up my library?
I'm using VS 2013 with .NET 4.5
Turns out you can do this by putting the offending types in a different namespace. All of my extension methods were in the same Common.Extensions
namespace, which apparently causes everything in that namespace to be loaded. By moving the WPF specific extensions to Common.WPF.Extensions
I was able to keep them all in the same assembly.
Update:
The specific cause for this error came down to public facing types that were included in one of the extension methods. Turns out you CAN have an extension method for a type that you don't have a reference for, but none of those methods can have an argument, a return, or a type declaration that uses the un-referenced type. In my case I had
public static void SetParentCursor<T>(this FrameworkElement frameworkElement, Cursor cursor) where T : FrameworkElement
The where T : FrameworkElement
is what killed it in the end.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With