Project option not working correctly for the `user-jwts` command

[glen-84]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Running dotnet user-jwts list --project src/Api/ returns:

The project file 'src/Api/src/Api/' does not exist.

Expected Behavior

No error. The equivalent user-secrets command works fine.

dotnet user-secrets list --project src/Api/

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

7.0.102

Anything else?

WSL, Debian GNU/Linux 11 (bullseye).

[captainsafia]

Looks like a bug here: https://github.com/dotnet/aspnetcore/blob/main/src/Tools/dotnet-user-jwts/src/Helpers/DevJwtCliHelpers.cs#L35-L37.

@glen-84 Any interest in submitting a pull request contributing a fix to the above?

[glen-84]

@glen-84 Any interest in submitting a pull request contributing a fix to the above?

I'm not sure when I'd have the time, and it looks like a proper fix might be more involved (factoring out common code between the JWT and secrets tools):

aspnetcore/src/Tools/dotnet-user-jwts/src/Helpers/DevJwtCliHelpers.cs

Lines 28 to 43 in 166593f

	public static string GetProject(string projectPath = null)
	{
	if (projectPath is not null)
	{
	return projectPath;
	}
	var csprojFiles = Directory.EnumerateFileSystemEntries(Directory.GetCurrentDirectory(), "*.*proj", SearchOption.TopDirectoryOnly)
	.Where(f => !".xproj".Equals(Path.GetExtension(f), StringComparison.OrdinalIgnoreCase))
	.ToList();
	if (csprojFiles is [var path])
	{
	return path;
	}
	return null;
	}

aspnetcore/src/Tools/Shared/SecretsHelpers/MsBuildProjectFinder.cs

Lines 19 to 53 in 166593f

	public string FindMsBuildProject(string project)
	{
	var projectPath = project ?? _directory;
	if (!Path.IsPathRooted(projectPath))
	{
	projectPath = Path.Combine(_directory, projectPath);
	}
	if (Directory.Exists(projectPath))
	{
	var projects = Directory.EnumerateFileSystemEntries(projectPath, "*.*proj", SearchOption.TopDirectoryOnly)
	.Where(f => !".xproj".Equals(Path.GetExtension(f), StringComparison.OrdinalIgnoreCase))
	.ToList();
	if (projects.Count > 1)
	{
	throw new FileNotFoundException(SecretsHelpersResources.FormatError_MultipleProjectsFound(projectPath));
	}
	if (projects.Count == 0)
	{
	throw new FileNotFoundException(SecretsHelpersResources.FormatError_NoProjectsFound(projectPath));
	}
	return projects[0];
	}
	if (!File.Exists(projectPath))
	{
	throw new FileNotFoundException(SecretsHelpersResources.FormatError_ProjectPath_NotFound(projectPath));
	}
	return projectPath;
	}

[glen-84]

@captainsafia Wouldn't a bug like this be fixed in a patch release? It seems quite bizarre to wait 12 months for a fix. 🙂

Maybe I'll find time in the next month or two to put a fix in place, but I also wouldn't want to do so if it meant waiting another 10 months for release. 🚀

The same is even more true for #44869, which literally results in corrupted files (imagine someone not using a VCS).

[captainsafia]

@captainsafia Wouldn't a bug like this be fixed in a patch release? It seems quite bizarre to wait 12 months for a fix. 🙂

The same is even more true for #44869, which literally results in corrupted files (imagine someone not using a VCS).

Yep! Something like this would be serviced. Typically, the process is to land it in a 8.0 preview release, validate the fix, then backport it to 7.0. The bar for these backports is a little higher (see this doc) so hence the need for some bake time.

Maybe I'll find time in the next month or two to put a fix in place, but I also wouldn't want to do so if it meant waiting another 10 months for release. 🚀

Next month or two is where I was feeling it depending on some other items. Happy to review a PR if you get to it before then but otherwise no worries.

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.