Hi, thanks for sharing this problem.

There haven't been any changes around extern aliases in NCrunch for quite some time. Most likely this hasn't been solved in a version newer than what you're using.

Are you able to reproduce this problem in a project sample that you can share with me? NCrunch does try to preserve extern aliases when it reworks project references, but it's possible there's something it's missing here in your use case.

Thanks for sharing these extra details. Looking at the way these references are declared, I think I can understand why NCrunch might have problems here. NCrunch doesn't consider the alias when attempting to uniquely identify the reference, so it's most likely getting them confused.

Although it's a goal to make NCrunch try and support edge cases like this, I do have some reservations about handling this one specifically. Mostly this is because my own experiences have shown that trying to have two different assemblies loaded into the same application domain under the same name tends to cause massive problems in the CLR. Is there a strict requirement that your dependencies be arranged like this? If at all possible, I would suggest renaming one of the DLLs to avoid tooling and runtime issues.