I have a class library that calls dll_A.

dll_A has dependencies on WPF.

How to I wrap or isolate my class library so that the code calling my library does not need to have a dependency on WPF?

(My class library obviously has to depend on WPF, but the only output is Byte[]).

In other words, I want my library to act as an entirely different process, as a sort of 'buffer', and the calling code does not care about how it works, only that it outputs Byte[].

  • 1
    Why does the code calling your library require a dependency on WPF, if the only output is byte[]? Are you requiring the caller to pass in parameters that are WPF-specific? – Robert Harvey Jan 13 '18 at 17:21
  • @RobertHarvey: dll_A itself requires a dll that can draw using the WPF framework. I don't need any rendering (I only output Byte[]), but it still means there is a dependency on WPF. – DefenestrationDay Jan 25 '18 at 9:21

For getting this level of isolation, you probably don't need a separate process. A separate "AppDomain" will probably be enough.

For this, let either the calling code not link against your lib, or your library not link directly against dll_A. Instead, load the WPF dependent libs at run-time into a separate AppDomain and use the .Net frameworks reflection mechanism to call the methods of your library, like shown in this older SO post, or this Microsoft page.

If you really want isolation on the process level, you need to put the code of your class library which is linked against dll_A into a separate wrapper program (maybe a command line tool), implement some kind of interprocess communication (IPC) and provide a second class library which can communicate with the wrapper program and provides an API for the calling code. But beware, IPC always adds some overhead, this has always an impact on the performance and the required programming effort.


You have to separate the code into different dlls. That is, create Adll which offers the function you described above (Afunction which hopefully does not depend on WPF). Create another dll Bdll with the functionality which requires WPF; it may have a dependency on Adll.

This strategy won't work if the Afunction requires WPF features.

I faced a similar problem when I added some "business logic" plus a Windows Forms UserControl into one dll, and then tried to use the business logic (which did not at all depend on the UserControl) in Asp.Net.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.