CoPilot and .NET Dependency Graphing

[gilmorem560]

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:

• API
• Service
• BusinessObjects

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!

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[gilmorem560]

For the record CoPilot has continued to be relatively useless in this project so I've turned to writing my own solution using the Roslyn SDK which is working out much better. Given that Microsoft's entrenched position in all things C#, .NET, Roslyn, GitHub, CoPilot, etc. I would personally expect better integrations between all of these different technologies but this does appear to be the state of things currently, that Microsoft's CoPilot on Microsoft's GitHub struggles to use Microsoft's Roslyn SDK to analyze Microsoft's C# language for characteristics of implementation of solutions based on Microsoft's .NET Core framework.