@craftworkgames Sure thing. I’ve been digging through the MonoGame.Framework and MonoGame.Extended sources trying to figure out an elegant way to wire this all up.
The issue is that with regular references in .mgcb, it is a relative path only. From what I can tell, there isn’t even a place in the code where global variables are used to swap anything out of the string for /reference:
Once could use some of tricks already discussed in this thread to create a variable in MSBuild, but that is only for the build process and wouldn’t put the reference into the .mgcb when using the MonoGame Pipeline Tool UI (which I would think we’d still want).
Looking at csproj files, there is a difference between locally pathed references and NuGet references (where there is an implied translation of where these paths go). I really feel like MonoGame needs something similar. Something like a /packageReference: in the .mgcb so that it knows to reference the global NuGet package store.
However, maybe trying to get a change done in the actual MonoGame.Framework is not the way to go. If not, the other option I was looking into was a way to make a NuGet package that creates a lib output folder as part of the build. I’ve seen things like this for packages that create x86 and x64 folders, and I’m hoping that maybe the same could be done for a NuGet. So after an initial build, the Nuget package would put the right files in the right place for the local references to work. Whewn NuGet is updated, those files would be too.
What are your thoughts?