Let me clarify:
I have built a class library to be used in several projects. As part of this DLL I want to add a few different custom providers for Owin Cookies by
The rules:
Microsoft.Owin.Security.Cookies
assembly, then other assemblies can safely compile with your DLL without referencing that assembly.Microsoft.Owin.Security.Cookies
also don't call any code in your assembly that would then in turn attempt to call code in Microsoft.Owin.Security.Cookies
, that assembly need not be present at runtime.The tricky part on that second point is that what constitutes "calling code in Microsoft.Owin.Security.Cookies
" is not always clear. Typically, as long as you don't access the types in the assembly at all, .NET won't try to execute any code in that assembly. But it's not hard to accidently access the types even when they are not necessarily needed (e.g. in initializers, static
or otherwise, code that checks for interface implementations, etc.).
If you really want your clients to be able to use your DLL, which references Microsoft.Owin.Security.Cookies
, without necessarily needing that DLL to be present at runtime, you will need to be very careful to ensure you've fully supported that scenario. It is possible to do, but it's also not hard to make a mistake.
(I have to admit, I'm surprised that this useful question hasn't already been addressed on Stack Overflow. Seems like it would have come up before by now. But I was unable to find a duplicate, hence the answer above. If anyone is aware of a duplicate I've overlooked, I welcome any suitable notice of that.)