I have an executable project called A.EXE which references a C# class library B.DLL.
A.EXE generates events which are handled by a class in B.DLL. The events use a custom EventArgs child called ProjectEventArgs.
Do I need to add a reference for A.EXE to the B.DLL project so that the ProjectEventArgs class is defined? That doesn’t seem quite right to me as I think this is a circular dependency.
Is there some way to refactor my code to avoid this?
thanks, Andy
You can’t reference a.exe from b.dll in the first place, so no, that isn’t the solution. Even if a was a DLL, you wouldn’t be able to do the reference because it would introduce a circular reference between assemblies, which is not allowed.
First decision in refactoring your code, decide whether or not ProjectEventArgs belongs in the dll or the application. The way to do this is to check what other dependencies the ProjectEventArgs class has – is it depending on other types from A.exe, or has no other dependencies? (If the latter, stick it into the dll).
In the case it does have dependencies inside A, you need to abstract the functionality of the ProjectEventArgs into a base (abstract) class, or an interface. (Or, since it’s a child of EventArgs already – can you not capture all the functionality you need by simply using the EventArgs from B?)
Really could do with a code sample of your ProjectEventArgs class, and a snippet of where you use/call it to give an actual sample solution.