[BUG] Dotnet build doesn't work

Question

[BUG] Dotnet build doesn't work

Closed this issue 4 months ago · 15 comments

Hi, I wanted to try to use this plugin.

When running :Dotnet build I get the following error.

I didn't have time to debug it yet. Maybe it gets confused, because there are several .sln files in the project...
I didn't configure anything. I just tried to use it out of the box.

Answer 1 · 2024-09-12T11:02:39.000Z

Ah I think I found the error. We have a common.csproj.props file in our main solution. This files resides in the root folder with the .sln file
Within the solution file you find

Project("{2150XXX-XXX-XX}") = "Solution Items", "Solution Items", "{39B08XX-XX-XX-XX}"
	ProjectSection(SolutionItems) = preProject
		.editorconfig = .editorconfig
		.gitignore = .gitignore
		common.csproj.props = common.csproj.props
		XX.XXXX.ruleset = XX.XXXX.ruleset
		Directory.Build.props = Directory.Build.props
		Directory.Packages.props = Directory.Packages.props
		README.md = README.md
	EndProjectSection
EndProject

Would it be possilble to consider that as well?

Answer 2 · 2024-09-12T15:47:22.000Z

Hmm, multiple sln files shouldnt cause this error, and neither should the common.csproj.props.
Are you using linux? There was a fix not long ago similiar to the error you reported #110
Please check if all .csproject files contains a node

Answer 3 · 2024-09-12T16:16:15.000Z

Im also interested in your usecases around multiple sln files. Please feel free to add comments to this #114

Answer 4 · 2024-09-12T16:41:04.000Z

Yes I am using Linux. I tried it today and I use lazy.nvim so I guess I hade the newest Version. I just saw that it took another csproj file to try to get the TargetFramework. But in this .csproj file is the target Framework not specified. It is in the common.csproj.props specified.
Therefore I thought it should check first if there is a common .csproj file to get the TargetVersion from it.

Answer 5 · 2024-09-13T06:06:33.000Z

Ah, there is no code to handle .csproj.props files yet. I made a pr for this feel free to test it before I merge

#115

Answer 6 · 2024-09-13T11:26:19.000Z

Hi, Thanks for the fast reply.
With the new branch there is no error anymore. When I run :Dotnet build it just freezes. Not sure if I missed any configuration or so I didn't configure anything with overseer or so. As I said I only installed the plugin as is.

Answer 7 · 2024-09-13T11:34:16.000Z

It should work perfectly without any configuration/options. Weird, if it just freezes. Do you have any other dotnet projects you could test it in. Ill try testing some more and see if I can reproduce your issue

Answer 8 · 2024-09-13T11:49:51.000Z

hmmmm... when I create a new project with dotnet new console it works. Maybe I find over the weekend some time to check what is difference. I'll let you know if I find something. But this issue can be closed with the new branch

Answer 9 · 2024-09-13T12:48:42.000Z

There was an error in one of the functions looking for Directory.Build.props so it caused an infinite loop. It is fixed in the latest commit on the branch. However I dont think it will fix any problems for you

Answer 10 · 2024-09-13T12:53:18.000Z

For the common.csproj.props is it referenced in the .csproj file or only in the solution file? Typically I expect the .csproj.props to be referenced by the csproject

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <UserSecretsId>50324eaa-1c1a-4f2a-a25f-92a283579f47</UserSecretsId>
  </PropertyGroup>
  <Import Project="..\Shared.props" />

  <ItemGroup>
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.4.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\NeovimDebugProject.Helpers\NeovimDebugProject.Helpers.csproj" />
  </ItemGroup>

</Project>

Answer 11 · 2024-09-13T12:56:12.000Z

Yes it is also referenced in the csproj file like this

<Project Sdk="Microsoft.NET.Sdk">
  <Import Project="$(RepositoryRootDir)common.csproj.props" />
  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Primitives" />
  </ItemGroup>
</Project>

Answer 12 · 2024-09-13T13:19:10.000Z

Okay so I see the issue, the code has no way to handle MSbuild variables like $(RepositoryRootDir). I want to support this but it will probably take a while to become 100% MSBuild compatible.

Answer 13 · 2024-09-13T15:52:02.000Z

I dabbled a bit and getting specifically the TargetFramework version from MSBuild is trivial, my biggest issue is responsiveness. I have to spawn a process for each project and run a dotnet msbuild <path> -getProperty:TargetFramework command and then parse the result. Im looking into implementing some form of cache for this

Answer 14 · 2024-09-13T16:26:22.000Z

Okay so I did some digging in the code and basically concluded that TargetFramework is only used for two purposes.

Showing the version in the project picker in the form of <proj>@<version>
Getting the output path for the dll. This is used for the debugger

I made some changes on the branch feat/support-.props-files, and I now use msbuild when the get_dll_path function is called. This makes responsiveness not such a large problem because it will only ever be called for one project at a time. This branch should now work perfectly for you. I will have to spend more time reading up on MSBuild before I merge this to ensure there isnt any better ways to solve this

Answer 15 · 2024-09-14T19:44:49.000Z

Pr has been merged and your issue should be resolved. Let me know if it still doesnt work.