Go to Definition not working with non-default OutDir

[sponomarenkoMSFT]

Used Visual Studio

Visual Studio 2022

Are the latest Visual Studio updates installed?

Yes

Content of reqnroll.json (if present)

No response

Issue Description

Issue Summary
The Reqnroll Visual Studio extension does not support Go To Definition functionality when the project uses a custom OutDir property pointing to a non-default location (e.g., an artifacts folder in the repository root).

Observed Behavior
In this scenario, the Reqnroll output window displays the following message:
Info: AndBindingSourceIsValid: Test assembly not found. Please build the project to enable the Reqnroll Visual Studio Extension features.

Root Cause
The extension appears to search for assemblies in the default path:
{project_location}\bin\$(Configuration)\$(TargetFramework)\$(AssemblyName)

When OutDir is set to a custom path, such as:
<OutDir>..\artifacts\bin\$(MSBuildProjectName)\$(Configuration)</OutDir>
the assemblies are no longer located in the expected directory. As a result, the extension cannot detect them, causing Go To Definition functionality to break.

Steps to Reproduce

1. Create new Test project with simple feature and steps implementation
2. Change build directory in .csproj file to something like <OutDir>..\artifacts\bin\$(MSBuildProjectName)\$(Configuration)\</OutDir>
3. Build project
4. Go to feature file and press F12

Expected behavior
Cursor moved to defined step in dedicated Bindings file

Actual behavior
Nothing happens

Notes

For clean results /bin folder must be cleaned up before steps of reproduction execution. Also after OutDir changes you need to restart VS as it is still caching path to steps and it will still navigate if you add OutDir. Only after VS restart and rebuild issue is reproducible.

Link to a project repository that reproduces the issue

No response

[gasparnagy]

We query the output path from VS when calling the GetOutputAssemblyPath method that calls GetOutputPath.

In order to diagnose this issue, these methods would need to be debugged and somehow try to understand why the VS API does not return the right output path.

@sponomarenkoMSFT Could you please help us and try that out?

[sponomarenkoMSFT]

@gasparnagy thank you for reply.
I actually already dig around source codes for VS extension and saw that implementation. So i tried to fetch that information myself and as i can see it is just taking information in the way that it is pointing to standard bin location:
So outcome was something like:

• GetOutputFileName returns correct dll name
• GetProjectFolder - returns real project location similar to $(MSBuildProjectDirectory) value. Thing that i know about it, that it is retrieved in source code over FullPath property which is somehow pre-hardcoded solution path to that project, so not easy to manipulate or change. That means it will always point to real project locaiton
• GetOutputPath - is looking for proj OutputPath property or constructed over some complex path calculation. Usually it is pointing to something like bin\$(Configuration)\$(TargetFramework) path by default
  So as result combined path will try to look for dll always at some sub-directory ($(OutputPath)) relative to current project and if solution like in my case has some top level directory for all project artifacts overridden by OutDir property - it is not recognized at all.

There is actually workaround which i found to mitigate this issue by setting extra properties in project:

<PropertyGroup>
		<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
		<OutputPath>$(OutDir)</OutputPath>
	</PropertyGroup>

As you can see setting explicitly OutputPath to real location of the assemblies helps to construct correct location path.
That works just because luckily path combine function Path.Combine(projectFolder, outputPath, outputFileName); totally ignores first path part of projectFolder when outputPath is presented as absolute path and not as relative. As result it just combines OutputPath with result outputFileName and provides valid way for assembly.
Small addition is that you must also set AppendTargetFrameworkToOutputPath property to False in other case it will try always to add TargetFrameword moniker at the end of the OutputPath making it as well incorrect.

[gasparnagy]

Thx for the detailed analysis. What I don't understand is why the "OutputPath" property of the active configuration here is not returning the ..\artifacts\bin\xxx setting that you have configured. Do I understand right that it returns the standard bin\Debug\... value even if you have specified a custom OutDir from MsBuild?

[sponomarenkoMSFT]

Yes that is correct, it is by default pointing always to that directory. So i have something like that returned: bin\Debug\net8.0-windows\ . I can take a look why but if I am not wrong is that because it is other way round OutDir is constructed over OutputPath, which means if you do not override it, it will point to default location.

[sponomarenkoMSFT]

I think here is some clarification about that: https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-by-directory?view=vs-2022
Also similar topic discussed here: dotnet/msbuild#87
If shortly use of OutDir overrides other variables for path setup including OutputPath something i believe came more frequent with Artifacts build output pattern and new .net SDK in place. So it might be VS extension should also consider such aspects similar to that code from msbuild: https://github.com/dotnet/msbuild/blob/044c796561d5c06be5c8caeac8a7bf0334e4232d/src/Build/Construction/Solution/SolutionProjectGenerator.cs#L1742

[gasparnagy]

@sponomarenkoMSFT Thx. That makes sense.

It was really a long time ago when I did this, so I don't remember fully but as far as I recall it was not that trivial to get MsBuild properties on that context, but I might be wrong. Do you want to play with that further?

[sponomarenkoMSFT]

@gasparnagy sorry didn't get your last comment. Do you ask me if I still would like to see that fixed, or you asking me if i can provide some branch with a fix?

[gasparnagy]

@gasparnagy sorry didn't get your last comment. Do you ask me if I still would like to see that fixed, or you asking me if i can provide some branch with a fix?

The latter... 😉