Most of our company's applications depend on a few core libraries, so there is a build rule in the MSBuild scripts that automatically adds the reference to them:
<When Condition=" '$(OutputType)' == 'WinExe' ">
<ItemGroup>
<ProjectReference Include="(project filepath)">
<Project>{(assembly GUID)}</Project>
<Name>(project name)</Name>
</ProjectReference>
</ItemGroup>
</When>
However, I'm running into a situation where, for a few particular applications, I want to load a different version of those libraries to provide different runtime backings. I can add a reference to them manually, but this build rule will still apply, causing assembly load and duplicate name resolution conflicts.
So, what can I enter as an additional condition that I can use to check the project references that already exist, and thus avoid linking the default project in this build script? If I can't check for project references, is there something else I can add to my code that I can check for?
EDIT: Note that this is related to this question of mine from a while back - the idea here is that core classes are being replaced entirely and referenced from generated code (this is already being done for different platforms). Yes, this is a very non-.NET way to go about things, but is more analogous to how utilities like Linux's valgrind
replace malloc
and free
to do instrumentation.