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
Your B.DLL shouldn't know anything about A.EXE - you're right, you are creating a circular dependency.
You need to refactor the code so that the methods that generate the events are in B.DLL or a third assembly referenced by both A and B. At the very least the definition of ProjectEventArgs needs to be moved out of A.
Without seeing your code and a more detailed project structure it's going to be difficult to say which will be the best approach.
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.