Is it bad practice to write a library that defines an interface dependent on another library?
I know tight coupling is bad, but does this still apply when using .NET classes?
For example, in .NET, if I have a library that returns a Color object, it would force a dependancy on System.Drawing on anything that uses my library. Would I be better off creating my own Color-type class inside my library?
If it's a standard .NET library, I wouldn't worry about it. No reason to map from one class to another ... what if System.Color changed in the next .NET release? You'd have to change your mapping code too, and possibly have to detect the version and map accordingly. That's a real pain.
With all of my libraries, I return objects that depend only on things in the library.
I would ask myself why I was writing a library that would depend upon another namespace that was not implicit. It seems to go against the whole "Encapsulation" concept.
So just by going off of my own reasoning and knowledge of OOP, I would say you are on the right track with returning your own non-dependent object.
I distinguish between Volatile and Stable Dependencies.
In general, Color looks like a Stable Dependency because it's already in the BCL, it's deterministic in nature and doesn't involve any resource-intensive out-of process communication, and neither does it rely on a particular set-up of its run-time environment.
The only consideration here is that when it comes to Color, there are more than one such class in the BCL, so make sure that you really mean to target only Windows Forms applications with your API, because WPF has its own definition of Color.
If you just need the Color to paint parts of the UI in a certain color, then the built-in Color class is probably fine, but if Color is a main concept in your Domain Model, and you need to target different UIs (WPF, Windows Forms, Web) you would probably be better of by defining your own abstraction.
In such a more advanced case, you could subsequently create Adapters and Mappers around your abstraction to bridge the gap between the abstraction and the concrete Color classes.
You pose an excellent question. The answer is: it depends. In the case of standard libraries that will always be available, then it's fine; the core library references different .DLLs all the time.
In the case of a third party library you run into issues. It's not always a good idea to roll your own if something else does what you want, but then you have a dependency on another library, which is a logistical problem for users.
There's no right answer here, you just have to go with what makes the most sense for your project. Try to decouple as much as possible, yes, but sometimes you just gotta cuddle up and get the job done.
It depends on your usage of the class.
If you ever need to obtain an instance of the system Color class from an instance of your Color class (for example if you draw to a windows form) then it would be better to use the System class - it saves you the effort of having to convert between the two types and gives you the advantage of being able to use all the "Features" of the Color class for free (such as built in constants for "Red", "Black", "Green" etc...
If on the other hand you are simply working with arbitrary RGB values (perhaps for scientific calculations) and never need to convert to an instance of System.Color, then it might make sense to create your own class.
In all likelihood you are better off using the System.Color class - yes encapsulation and all that is a good idea, however not at the expense of saving you massive amounts of time!
You shouldn't worry about using anything in the .NET core library. You wouldn't get very far in writing a DLL without it. The only place possibly to be careful around it is the System.Web namespace as I believe .NET 4 has a client profile installer which basically means if you use this installer it will only install things expected to be used on a client. I personally think it is a bad idea on Microsoft's Part as it just adds un-necessary complication for saving a small amount of download time.