You're taking on this problem from the complete opposite direction that you should. The proper way to have a a library project be able to project a UI element out is not by having the library project know how to do it, but by passing in the method to use as a delegate.
What happens if you're calling this library from a console application, or in an environment where a window cannot possibly be displayed?
Look up how you pass methods into other methods for execution. The brief explanation is the library will define a delegate method that will have a return type (likely void for this), and any parameters it will need to take in. For a message window likely a title, and message.
You then use this delegate as a parameter on one or more methods/constructors in your library. Usually in the constructor for the class that may want to display this message, because it's likely to do it in multiple locations.
Finally, in your UI project, you define a method that matches the signature of that delegate. Name is irrelevant, only the parameters and return type matter. That method will have all the code for displaying the message that is proper for the particular UI system. Console would be some WriteLine() calls. WinForms would likely use a dialog.
When you pass that method in as the delegate parameter to your library, the library doesn't need to know anything about the libraries/frameworks/classes used in the method. It's simply a pointer to the code that lives in the UI project. When your library calls that method, it's calling back to the UI and saying "Hey, do this thing you told me you know how to do. I don't care how, just do it."
Library projects should never be aware of any UI specific elements. As soon as they are, you are breaking a fundamental principle of software development which is separation of concerns. Keeping things separated increases testability, portability, upgradeability, etc.
