[Tests] Local Testing of single Mapster Projects fails for SolutionDir is not always set when building a project directly via dotnet test

[DevTKSS]

I was locally trying around with the DI Package to look into my suggested Idea to enable something like MapsterOptions from appsettings.json.

But testing via dotnet test path/to/csproj fails on the Directory.Build.props file uses SolutionDir which is not or not always set, which causes that Copilot constantly edits the Directory.Build.props with this:

<!--
	SolutionDir is not always set when building a project directly (e.g. `dotnet test path/to/csproj`).
	Fall back to the key path relative to this props file (src/Mapster/Mapster.snk).
-->
<AssemblyOriginatorKeyFile Condition="Exists('$(SolutionDir)Mapster\\Mapster.snk')">$(SolutionDir)Mapster\Mapster.snk</AssemblyOriginatorKeyFile>
		<AssemblyOriginatorKeyFile Condition=" '$(AssemblyOriginatorKeyFile)' == '' and Exists('$(MSBuildThisFileDirectory)Mapster\\Mapster.snk')">$(MSBuildThisFileDirectory)Mapster\Mapster.snk</AssemblyOriginatorKeyFile>

Which includes in the .csproj the marked lines:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net10.0;net9.0;net8.0;</TargetFrameworks>
    <Description>Dependency Injection supports for Mapster</Description>
    <IsPackable>true</IsPackable>
    <PackageTags>Mapster;DependencyInjection</PackageTags>
+    <SignAssembly>true</SignAssembly>
+    <AssemblyOriginatorKeyFile>Mapster.DependencyInjection.snk</AssemblyOriginatorKeyFile>
    <Version>10.0.0-pre01</Version>
  </PropertyGroup>

Since I so far never worked with Signing Assemblys or similar, I don't know for what build/release step we are exactly needing this, assuming just for the Package Creation - Release step, isnt it?

I am quite sure @andrerav or you others @DocSvartz @stagep might have some information and solution? 😁

How do you do this when you others are testing locally?
Is there some kind of trick, except from always building the solution? 😓
Could we have this fixed possibly?

[DocSvartz]

In VS it always working. 😅 Excluding auto-generated projects for benchmarks.

Something like this should work.

if you run it in this dir -> ..\Mapster.DependencyInjection.Tests>

dotnet test Mapster.DependencyInjection.Tests.csproj -property:SolutionDir="..\"

[DevTKSS]

@DocSvartz why do we need to manually set this in the dotnet CLI?🤔
Is there a way to correctly set this by a csproj property or better a Directory.Build.props property pullet to each one, but use a always working variable?🤔

[DocSvartz]

Is there some kind of trick, except from always building the solution?

This is the very trick you asked for to quickly solve the problem. :)

> file uses SolutionDir which is not or not always set,

I don't think it can be left unset.
It's most likely set by default to the current folder from which dotnet test is run (similar to the working directory for programs).
That's why when you launch it, you get an invalid path to the signature file.

I checked again, and it really doesn't seem to be setting. For some reason, I thought the error output indicated a relative path.😅

[DocSvartz]

I think the signature-related parts in Directory.Build.props should be removed.
Since signing different assemblies with the same signature is odd anyway.

And add it to the Mapster project:

+    <SignAssembly>true</SignAssembly>
+    <AssemblyOriginatorKeyFile>Mapster.DependencyInjection.snk</AssemblyOriginatorKeyFile>

[DevTKSS]

@DocSvartz just a thought but for what do we need the signing in the end of the day really?

Am I right that it is for when we want to push a release? 🤔

If so, what do you think about simply adding all Signing related properties in a seperate PropertyGroup (or was it ProjectPropertys 😅) that would get added a Condition= matching the case, when we really want to require it?

And for the SolutionDir🤔 I would assume, this is only set, if you choose dotnet build Path/to/Solution.slnx but is not set when only building one of the projects. So... I think the Mapster.Tool used Directory file I created for my own project might be able to remember which Variables were used there🤔 I am currently not on my computer.

[DevTKSS]

@DocSvartz here:

• https://github.com/DevTKSS/DevTKSS.MyManufacturerERP/blob/master/src%2FWebApi%2FWebApi%2FWebApi.csproj
• https://github.com/DevTKSS/DevTKSS.MyManufacturerERP/blob/master/src%2FDirectory.Build.targets

What do you think of using some of those variables ?

Adding this central Mapster Tool sample or even providing it maybe as dotnet new is still on my list, as soon as I finally got Auth working on my project desktop target 😅

[DocSvartz]

Am I right that it is for when we want to push a release? 🤔

Yes, but I don't use signed assemblies either, so I don't know for sure.

If so, what do you think about simply adding all Signing related properties in a seperate PropertyGroup (or was it ProjectPropertys 😅) that would get added a Condition= matching the case, when we really want to require it?

The problem here is that what kind of condition will this be? Otherwise, it will be no different from the current situation. 😅

I checked again, and it really doesn't seem to be setting. For some reason, I thought the error output indicated a relative path.😅

Based on the current build directory. But this is a relative path, relative to the file itself.

Therefore, this will also work from the project's root directory. I thought it a relative path Based on the current build directory. But this is a relative path, relative to the file project.

This will work too

C:\Users\DocSv\source\repos\DocSvartz\Mapster\src> 
dotnet test .\Mapster.DependencyInjection.Tests\Mapster.DependencyInjection.Tests.csproj -property:SolutionDir="..\"

[DevTKSS]

@andrerav could you let us know about when we need the Signing for real, so we are enabled to set up the correct condition and fix this?

@DocSvartz 🤔 I honestly prefer the idea to keep this Signing relevant Propertys as much as possible in one place like Directory.Build.props but use Variables to point to each own Signing file.

If you others would agree and we can evaluate the condition when to require this, I could try to take care of this 👍

[DocSvartz]

I honestly prefer the idea to keep this Signing relevant Propertys as much as possible in one place like Directory.Build.props but use Variables to point to each own Signing file.

Try it on one or two projects, as you see fit. I think this approach will be more difficult to understand what is happening😂.

[DocSvartz]

@DevTKSS Check out this article. If you're going to use infrastructure magic, then maybe It's worth using this on Full Power 😁 .