Roslyn Source Generator with Unity.Mathematics reference

Hey! I would like to reference the Unity.Mathematics.dll from my source generator.
The problem is that the source generator projects needs net standard 2.0 as target, but the Unity.Mathematics.dll is compiled against net standard 2.1 which does not work.

Downloading and older version from here:
and then linking against this version, e.g. version 1.1.0 does work in the source generator project, because it it´s compiled for net standard 2.0, but when the source generator dll is then copied in the actual Unity project, it does not work, because Unity.Mathematics.dll v.1.1.0 is missing.

Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Unity.Mathematics, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

Copying this dll also over, then removing all build targets and tagging it as RoslynAnalyzer lead to the error:

Plugin 'Assets/Unity.Mathematics.dll' has the same filename as Assembly Definition File 'Packages/com.unity.mathematics/Unity.Mathematics/Unity.Mathematics.asmdef'. Rename the assemblies to avoid hard to diagnose issues and crashes.

Removing then the Unity.Mathematics from the Project Manager let the source generator work, but brings the problem that I cannot use Unity.Mathematics.dll in my normal code anymore, because the copied over dll only exists in the source generator scope.

I also could not manage to install an old version of the Unity.Mathematics from the package manager

So how can I link Unity.Mathematics correctly to my source generator

You could just copy over the library’s sources into your own source generator project and use it directly. You would be able to access all the functionality from within the source generator and still be able to use whatever version of the package the project proper requires.

I tried it out, and the source generator project is working, but in Unity I still get the error

Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Unity.Mathematics, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

I guess the problem is that Unity does not copy the Unity.Mathematics.dll in the scope of the analyzer.

I don't quite understand why you would link to the DLL when Unity.Mathematics is a package that's available as source code. Mathematics doesn't even exist as a DLL until you import the package in your project and Unity compiles it.

Nevertheless, I think you need to upgrade your source generator project because Unity is targeting .NET Standard 2.1 through and through since at least Unity 2021.3. See Player Settings:

Engine API target has nothing to do with the use of source generators (and Roslyn analyzers) by the language compiler. Source generators are meant to target .NET Standard 2.0. This is the case for standard .NET tooling and for Unity as well (as it uses the same compiler technology).
OP did mention this already.

The expectation is that the source generators and code analyzers ("Roslyn [compiler] analyzers") along with all their dependency assemblies are provided to Unity pre-compiled, such that they are ready for use by the compilation pipeline for all applicable source code. If you have indeed copied over the source code into the source generator project, the error might just indicate that you have a leftover reference to the Unity.Mathematics assembly in your generator's csproj. The generator should not reference an external copy of Unity.Mathematics, as that would be redundant at this point.

Also, note that the current master branch of Unity.Mathematics will still compile on its own under .NET Standard 2.0 when the UnityEngine-reliant code isn't included. If you were so inclined, you could instead put the Unity.Mathematics code into your own assembly with a name that is unique, e.g. Unity.Mathematics.ForSourceGen, and link your source generator assembly to that, if it turned out that multiple source generators need that code and code duplication isn't tasteful.

The reason why I want to link against the Unity.Mathematics.dll is not the code, but the types. I have not tried out your idea about renaming the dll. I fear a bit that I have then every type twice which would lead to bugs when comparing types not being equal, but I have not tried it out.
I also wasted now hours into this topic and want to leave this behind
For now I will remove the dependency to Unity.Mathematics and use everywhere string names, so "uint3" instead of typeof(uint3).Name for example. Because the type names in the assembly will anyway never change, this is for me now an acceptable workaround.

Also interesting. Linking against the UnityEngine.dll works. I´m doing this to also get the types, e.g. Vector4

Nevertheless it would be interesting what the Unity way would be. Unity uses internally also SourceGenerators, so I guess they also have to link Unity.Mathematics somehow

No, they do not magically reference Unity.Mathematics. Why would they? You said it yourself, you can simply use strings in your generated code. Using actual assemblies to just add the names of types to generated code seems ridiculous, to be completely honest. I would wager this is not something that more experienced developers do. Everything you need should be available in the compilation and source code or the semantic models for them. If a library using Unity.Mathematics is being processed by the source generator, the generator can extract appropriate metadata for both the code under analysis and the assemblies referenced by it, including Unity.Mathematics. This should be sufficient for enumerating types, members, implemented interfaces, etc.

Also, if you have a constant (literal) type, using typeof(float4x4).Name isn’t very clean. You can just easily say nameof(float4x4).