Fix up project search scenarios when no option is provided #42860
Conversation
captainsafia
added
old-area-web-frameworks-do-not-use
ghost
added
the
area-commandlinetools
| @@ -32,7 +32,7 @@ public static string GetProject(string projectPath = null) | |||
| return projectPath; | |||
| } | |||
|
|
|||
| var csprojFiles = Directory.EnumerateFileSystemEntries(Directory.GetCurrentDirectory(), "*.*proj", SearchOption.TopDirectoryOnly) | |||
| var csprojFiles = Directory.EnumerateFileSystemEntries(Directory.GetCurrentDirectory(), "*.*proj", SearchOption.AllDirectories) | |||
There was a problem hiding this comment.
Is this guaranteed to find the top most *proj? Like if my project was b.csproj but had a folder a/ with an a.csproj, that wouldn't be used instead?
There was a problem hiding this comment.
The current behavior will throw an error for the multiple project scenario as it only supports looking for a single project file within a sub-directory. We can do something like use the first project file it finds but I'm not sure that's the best option. It feels more sensible to force the user to be explicit if we cannot find something.
There was a problem hiding this comment.
We should likely just match whatever the behavior of user-secrets is yes?
There was a problem hiding this comment.
user-secrets only searches the current directory if we wanted to stick to that. This would mean that we wouldn't resolve the project file for the nested folder scenario mentioned in the original issue but we would provide a clearer error message.
Closes #42794.