1

There are many other (older) MSB3270 mismatch errors questions posted on SO, but many of them are a decade old and for generations before NET 5. I have a set of NET 5 solutions that are all set to Debug AnyCPU in the Build / Configuration Manager. Yet I still get the warning message about mismatched architectures.

Here is my MSBuild command line:

%msbdir%\msbuild -nologo -m -V:q "%1" /t:Clean;Restore;Rebuild;Publish
 /p:PublishProtocol=FileSystem /p:PublishDir=%coredir% /p:RuntimeIdentifier=win-x64

Here is the output:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin
Microsoft.Common.CurrentVersion.targets(2203,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "HsLogger", "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. [c:\dev\HsUtils.csproj] Publish Ok - hsutils\hsutils.sln to c:\dev\holding\core.plt

I am certain that everything is set to Debug AnyCPU, so why is MSBuild protesting? I read somewhere else that AnyCPU is pretty meaningless and that I should specify x64 or x32 (or both) in my build configurations. I have net5.0-windows7.0 for a TargetFramework in the project files, but nothing else (no RunTimeIdentifier settings).

I wonder if the msbuild parameter /p:RuntimeIdentifer=win-x64 has something to do with it, but I don't know enough for sure. Should I be explicitly adding runtime identifiers to all my project files?

Is explicitly picking x64 the way out of these warnings, or should I just suppress them in my MsBuild command-line options? (Suppression seems like a bad move because it's a pretty serious issue if there is a true mismatch.) Thank you

UPDATE

In case it helps, my project files all look like this:

<PropertyGroup>
    <TargetFramework>net5.0-windows7.0</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <SelfContained>false</SelfContained>
    <PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>
Kevin
  • 1,548
  • 2
  • 19
  • 34
  • Clearly the 3rd party logging framework **HsLogger** that you are using is `x64` so you will need to compile assemblies that depend on it directly or indirectly _likewise_ –  Jan 04 '22 at 05:20
  • Well, clearly not. Of course, that was the first thing I checked. I said I was certain, and I am. The utilities library and the logger library have exactly the same settings. – Kevin Jan 04 '22 at 06:20
  • _"The utilities library and the logger library have exactly the same settings"_ - well clearly not. **MSIL** does **not** mean **x86** _**nor**_ *x64** and _"mismatch between the processor architecture"_ proves you have an issue. I suspect **HsUtils.csproj** is either being compiled to x86 either because you have set it so _or_ **HsUtils.csproj** is set to compile to **Any CPU** but it has a dependency to some other x64 3rd party assembly marked for x86 thus preventing it to be compiled to x64 –  Jan 04 '22 at 06:31
  • _"Is explicitly picking x64 the way out of these warnings"_ - yes. If you know you have at least **one x64 assembly dependency 3rd party or otherwise** you must compile **all dependent assemblies the same**. x86 will not load x64 or vice versa (unless of course the dll is a _COM server_ in which case you can create an opposite bitness surrogate process) –  Jan 04 '22 at 06:33
  • @MickyD, thank you for your suggestions. I dug through my projects and HsUtils depends on ChoETL 1.2.1.28 (NET Core App v2.0). I updated the post with a typical project file for my projects. Is there a way to tell how the ChoETL package was compiled so that I can change all my settings to agree? BTW, everything works fine despite the warnings. I only get the warnings with the runtime parameter on the command line, and it's the same as the RID listed in the project files. – Kevin Jan 05 '22 at 01:20
  • I read more and finally understand MSIL (AnyCPU, or CPU bitness x86/x64 not specified at MSBuild time), x86/64 specified at MSBuild time, and the behavior of the JIT compiler at runtime. The JIT compiler MUST pick x86/x64 at runtime according to what is needed/forced by dependencies and other assemblies. In my case, MSbuild was saying, 'you picked AnyCPU and depend on something that is x64, so something bad might happen at runtime if the JIT compiler picks x86 for some other assembly dependency." I will convert my dozens of projects to x64. Thank you MickyD for your help! – Kevin Jan 05 '22 at 03:30
  • My pleasure good sir :) –  Jan 05 '22 at 04:21
  • I'm still not clear on the need for both Platforms (x64) and RuntimeIdentifier(win-x64). Wouldn't the RID be enough? Doesn't it imply/force the x64 platform? Thank you – Kevin Jan 05 '22 at 21:01
  • I'm not familiar with `RuntimeIdentifier` sorry. Typically I just use _["MSBuild yourproject.sln /property:Configuration=Release /property:Platform=x64"](https://stackoverflow.com/a/29311331/585968)_. `Platform=` _xxx_ is the key. Looking at the [doco](https://learn.microsoft.com/en-us/dotnet/core/rid-catalog) maybe the identifier is just used as metadata? –  Jan 06 '22 at 03:50
  • 1
    My best guess is that the platform specifies bitness, the RID specifies which runtime to use, and the TargetFramework defines the API that runs on the runtime which runs on the platform. Oh well. It's working now. Thanks for your example command-line example! – Kevin Jan 06 '22 at 04:01
  • No problem. Yes I see .NET Core _moved the cheese_ a little bit. hehe +1 –  Jan 06 '22 at 04:06

0 Answers0