Maybe i dont understand this correctly, as i dont know much about broad .NET dev. But what you pretend seems not possible.
An Analyzer works by being embedded into the compilation pipeline. You cannot compile the analyzer ALONG the compilation of the rest of assemblies. Even though it could sound ideal, the Analyzer should be pre-compiled in all cases. If you want to reference your original framework assembly from within the Analyzer, then that should also be pre-compiled on its own, and then referenced from the Analyzer csproj.
I believe you have no workaround for including the Analyzer into a Unity Project as source-code. It should always be externally compiled.
However some things could be done for it to be less cumberstone. If you check the folder structure of the example provided by @Spy-Master, you see that the Source for the Analyzer is within a folder that is named “Source~”. The final “~” signals Unity that it should ignore that folder, so you can effectively have your Analyzer .NET project inside your package folder, without Unity generating .meta files or touching it in any way. Then, on the Analyzer .csproj, you can setup post-build callbacks that will directly copy the “.dll” in you desired folder each time you compile it through your IDE (and now that you project lives within the package, you could just use relative paths like “../../YourAnalyzer.dll”)
<!-- This is my normal setup for copying the Dll, but im seeing now that
in the example provided by @Spy-Master they do this more elegantly.
I still leave it for reference
-->
<Project Sdk="Microsoft.NET.Sdk">
...
<PropertyGroup>
<RunPostBuildEvent>OnOutputUpdated</RunPostBuildEvent>
...
</PropertyGroup>
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="start XCOPY /Y /R "$(TargetPath)" "$(ProjectDir)..\..\..\$(TargetFileName)""/>
</Target>
</Project>
This way, whenever you want to edit your Analyzer, you can just compile from IDE and Unity will auto-pick it up without you having to move around the .dll. Also your source-code will be within the package itself (alas in another project, but at least you have them together for dev purposes).
As for referencing your framework within the Analyzer. I understand that this also can be helpfull, but maybe you should avoid it, and just deal with strings. If you still want to, my recommendation would be that you extract the bare-minimun core Types into an independent .dll, and reference that. This way you can still develop your package source-code in Unity. but referencing a “Core features” .dll that will be externally compiled. The Analyzer would also reference that “Core features” (whatever its name) .dll.
This would work only if those “Core” Types you are extracting are not likely to change often, if not it would be just a waste of time, but i myself think you don’t have many more options, except for it being a fully externally compiled .dll (i could perfectly be completely wrong)
PD: i just realized this was necroed soz