You already used the terms:
- Interface projects
- internal core dll projects
Why should the DLLs have any business asking the user for something? I would rethink the entire design so that the DLLs just do actual work. Everything else, like asking the user what to do, should only be done in the user interface projects.
You could create callbacks the DLLs can call to inquire what to do, but you should in no way assume that the calls provide user interaction. That means: You should design it in a way so that the DLLs don't need to know how the information is returned to them, only that the information is returned to them.
For example: Assume one of your DLLs contains a function to copy files from folder A
to folder B
. If copying of one file fails, you want the user to decide whether he wants to abort or continue with all other files. You could create an event like this:
public class QueryContinueEventArgs : EventArgs
{
public QueryContinueEventArgs(string failedFile, Exeption failure)
{
FailedFile = failedFile;
Failure = failure;
Continue = false;
}
public string FailedFile { get; private set; }
public Exception Failure { get; private set; }
public Continue { get; set; }
}
public event EventHandler<QueryContinueEventArgs> QueryContinueAfterCopyFailure;
protected bool OnQueryContinueAfterCopyFailure(string fileName, Exception failure)
{
if (QueryContinueAfterCopyFailure != null)
{
QueryContinueEventArgs e = new QueryContinueEventArgs(fileName, failure);
QueryContinueAfterCopyFailure(this, e);
return e.Continue;
}
return false;
}
The assigned event handler could provide user interaction and set the Continue
flag accordingly.