question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

csproj: HintPath of local assembly reference is ignored

See original GitHub issue

Versions

Microsoft Windows [Version 10.0.18363.720] Microsoft Visual Studio Community 2019, Version 16.5.0 dotnet --version => 5.0.100-preview.1.20155.7 Also occurs with 3.1 LTS SDK

How to reproduce:

  1. Unpack and open contained sln file in Visual Studio 2019: Bug.zip
│   Bug.sln
│
├───MyApp
│       MyApp.csproj
│       Program.cs
│
└───MyLib
        MyClass.cs
        MyLib.csproj

MyLib represents any assembly that only exists for x86/x64 but not for Any CPU. This is the case for some C++/CLI assemblies I got from a vendor of USB cameras. MyLib is configured to store the built assemblies inside the MyApp folder. There is no ProjectReference, only Project Build Order to build MyLib before MyApp. After building MyLib, the files look like this:

│   Bug.sln
│
└───MyApp
    │   MyApp.csproj
    │   Program.cs
    │
    └───libs
        ├───x64
        │   └───netstandard1.0
        │           MyLib.dll
        │
        └───x86
            └───netstandard1.0
                    MyLib.dll
  1. Select solution platform “x64” and build. -> builds without warnings
  2. Launch MyApp project (x64) -> runs without exceptions
  3. Select solution platform “x86” and build. -> builds with warnings:
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2081,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "x86" and the processor architecture of the reference "MyLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, ProcessorArchitecture=X86", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
2>CSC : warning CS8012: Referenced assembly 'MyLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' targets a different processor.
  1. Launch MyApp project (x86) -> crashes with exception:
System.BadImageFormatException
  HResult=0x8007000B
  Message=Could not load file or assembly 'MyLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

The reason for this is because the build system ignores the HintPath which points to the x86 version of the assembly and instead uses the x64 version of the assembly, probably because the string “x64” is sorted before “x86”. I used ILSpy to verify that “Bug\MyApp\bin*x86*\Debug\netcoreapp3.1\MyLib.dll” is indeed the x64 version.

The issue also occurs when using MSBuild from the command line, so it is no specific to Visual Studio:

dotnet build -p:Platform=x86
dotnet build -p:Platform=x64

Failed Workarounds

  • Adding ProcessorArchitecture to the names of the references: Before: <Reference Include="MyLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null> After: <Reference Include="MyLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, ProcessorArchitecture=Amd64">

Successful Workarounds

  • A: Move libs folder one up so that it is not inside the csproj’s folder and correct <HintPath> accordingly.
  • B: Add the following lines to MyApp.csproj:
  <ItemGroup>
    <None Remove="libs\**" />
  </ItemGroup>

Issue Analytics

  • State:open
  • Created 3 years ago
  • Comments:6 (1 by maintainers)

github_iconTop GitHub Comments

5reactions
dsplaistedcommented, Apr 8, 2020

What happens if instead of using the HintPath, you use the path you want directly in the itemspec, ie:

<Reference Include="libs\x64\netstandard1.0\MyLib.dll" />
1reaction
mingpepecommented, Jul 26, 2023

It takes me a day to find this solution.

Read more comments on GitHub >

github_iconTop Results From Across the Web

HintPath vs ReferencePath in Visual Studio
My own experience has been that it's best to stick to one of two kinds of assembly references: A 'local' assembly in the...
Read more >
Please solve: Adding a reference to an assembly should ...
Please solve: Adding a reference to an assembly should not expand symlinks in the HintPathClosed - Lower Priority View resolution
Read more >
After update to SDK style projects are Hintpaths now ...
It seems that Hintpaths are now required for references that would be in the build output folder.
Read more >
VS: Provide Option for <HintPath> Only References (#19621)
On a current project I was using Xceed.Wpf.Toolkit and ZedGraph. Both of these are C# Assemblies that have UI controls in them.
Read more >
10 ways to make your .NET projects play nice with others
“It works on my machine” is not enough – no local references! Here's a good place to kick off: someone sends over a...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found