CoPilot and .NET Dependency Graphing #150626
Unanswered
gilmorem560
asked this question in
Copilot
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Select Topic Area
Question
Body
My organization has recently been evaluating CoPilot as a solution for modernizing a legacy codebase as well as allowing for rapid bootstrapping of new projects against a well established set of project structures (essentially our implementation of Microsoft Clean Code).
A problem I'm running into repeatedly is effectively using CoPilot to analyze dependency relationships between projects in a C#.NET solution. To lay out a general example, take for instance a solution which contains three projects:
The BusinessObjects library contains public classes which are utilized as data contracts for the other two projects, enforcing the data structures used both for the service calls and their interaction with the outside world. Where the difficulty lies is I've tried all sorts of variations on tasking CoPilot with enumerating the .cs files in the BusinessObjects library which are utilized in the methods and classes inside of the other two projects. After several iterative attempts, CoPilot seems to be squarely stuck on a fundamental misunderstanding that "using" statements at the top of .cs files represent class references rather than namespace references, when in reality the situation looks more like:
The using statements represent the namespaces in which locally unresolved references in a given class may derive from.
Parity between the namespaces expressed in a using statement and the namespace statement inside a file in the workspace indicate that the class object(s) defined therein are in the list of possible resolution targets when an otherwise unknown object name is referenced in code.
The dependency relationship is then, even if just speculative, the subset of files in the dependency project which exist in the namespace referenced in a using which then expose a class whose name matches the object reference in the dependent object.
As an example, say there is a namespace, Product.BusinessObjects.ConcernA, utilized in said BusinessObjects library. A class is then defined, in this namespace, called ObjectA.
Say then there is a service class in the Service project called ServiceA, presented as ServiceA.cs in the filesystem. This file contains a using statement, "using Product.BusinessObjects.ConcernA;" and then within the class in ServiceA.cs, there is a line, "private readonly ObjectA myObject;" which is then populated by the constructor.
What I'm finding with CoPilot is if I sic it on this hypothetical solution, I would expect prompts to the effect of "Generate a list of class objects from project 'BusinessObjects' which are dependencies of classes in project 'Service'" to then generate a list including "BusinessObjects/ObjectA.cs" since is a candidate satisfying that dependency relationship. While yes there is the possibility of a name being multiply defined in more than one imported namespace, in most circumstances, there would only be a single definition, as in that specific scenario the references would have to be qualified with more parts of the namespace string to disambiguate them anyway.
Instead, all variations I've tried thus far on this task have instead implied that "Product.BusinessObjects.ConcernA" is a class name, all such generated scripts from this process have included a function to aggregate the list of using statements at the top of the file which contain the term "BusinessObjects" but none of them seem to then look inside the namespaces, aggregate the actual objects defined "public class", and generate a listing of which symbols following "public class" anywhere in "BusinessObjects" then correspond with object definition refrences in "Service" or "API".
Does anyone have any pointers? Am I expecting too much of CoPilot in expecting it to provide me the names of specific classes based on their being referenced as fields/properties in another set of classes? Is there any "secret sauce" to getting CoPilot to be more aware of the logical structure of C# projects and what class objects, across a solution, would resolve external references in any given class?
I appreciate any suggestions!
Beta Was this translation helpful? Give feedback.
All reactions