XC 10 - Tip #8: When assembly hell breaks loose - hunt & fix

Just a few days before a big milestone, we need to deliver our Sitecore Commerce solution to a customer, Sitecore decides to bring out version 10.1. In my daily development flow, I restart my Sitecore Commerce Engine project again from Visual studio to do some debugging... and everything stops working.

When the Sitecore Commerce Engine stops working, the first thing I do is opening the local URL https://localhost:5000/api/$metadata to see if everything is ok. But this time it was NOT ok:

[
  "Could not load file or assembly 'Sitecore.Commerce.Core, Version=7.0.0.0, Culture=neutral, PublicKeyToken=null'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)"

]

Ehhh.... 7.0.0.0? We are still on Sitecore Commerce version 10.0, and most assemblies have version 6.0.92.0... It was almost the end of the day. So after some investigations we assumed something went wrong with the NuGet feed of Sitecore (we had a similar issue before), a colleague created a support ticket with Sitecore, and we called it a day.

This morning the deployments to our test server were broken as well, and none of my team members could continue working on their local machines anymore. You don't do much Sitecore Commerce development with a broken Sitecore Commerce Engine. I decided to do some more digging...

NuGet package management

The first thing is why are NuGet packages automatically updated... Because the Sitecore.Commerce.Engine application is always rebuilt, we have a NuGet configuration file that updates assemblies automatically:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <!--
  Used to specify the default Sources for list, install and update.
  -->
    <packageSources>
        <add key="Official Sitecore" value="https://sitecore.myget.org/F/sc-packages/api/v3/index.json" />
        <add key="Stylelabs_PartnerPublic" value="https://slpartners.myget.org/F/m-public/api/v3/index.json" />
        <add key="Official Sitecore Commerce" value="https://sitecore.myget.org/F/sc-commerce-packages/api/v3/index.json" />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    </packageSources>


    <activePackageSource>
        <!-- this tells that all of them are active https://sitecore.myget.org/F/sc-commerce-packages/api/v3/index.json -->
        <add key="All" value="(Aggregate source)" />
    </activePackageSource>
    <packageRestore>
        <add key="enabled" value="True" />
        <add key="automatic" value="True" />
    </packageRestore>
    <solution>
        <add key="disableSourceControlIntegration" value="true" />
    </solution>
    <config>
        <add key="globalPackagesFolder" value="./packages" />
    </config>

</configuration>

The important part in this file:

    <packageRestore>
        <add key="enabled" value="True" />
        <add key="automatic" value="True" />

    </packageRestore>

This would normally never lead to issues, but now it did!

On the Sitecore XP side, Sitecore provides all required assemblies already in the bin folder of the site, and we exclude these assemblies from project deployment using the approach developed by Anders Laub. So these issues will not occur that fast on Sitecore XP.

Assembly binding issues

In the old .NET days when I had assembly loading issues, the first thing I did was open up Fuslogvw.exe (Assembly Binding Log Viewer). For .NET Core this tool does not work anymore. After some searching, I stumbled across a GitHub issue that describes that it is replaced by an environment variable setting called COREHOST_TRACE.

I headed over to my project Debug output folder ...\CommerceEngine\src\Project\Sitecore.Commerce.Engine\bin\Debug\netcoreapp3.1 and executed the following commands:

set COREHOST_TRACE=1
dotnet Sitecore.Commerce.Engine.dll

I now got a huge amount of output in my console window. Luckily enough I use ConEmu with the largest buffer size enabled and using the built-in search feature I found that multiple assemblies were now on version 7.0.34. Something was clearly wrong...

When I checked the file Sitecore.Commerce.Engine.deps.json which generated next to Sitecore.Commerce.Engine.dll I saw multiple wrong dependencies, for example:

      "Sitecore.Commerce.Plugin.BusinessUsers/6.0.92": {
        "dependencies": {
          "Sitecore.Commerce.Plugin.Shops": "6.0.92",
          "Sitecore.Commerce.Plugin.Views": "7.0.34"

        },

How can a 10.0 assembly with version 6.0.92 be dependent on a 7.0.34 assembly of Sitecore 10.1?!

Determining assembly versions quickly

I opened up the file explorer and did the following steps to get a better overview of what assemblies were affected:

1. While in the netcoreapp3.1 folder, right-click on the column row and select “More…”
2. Search for and mark the item called “File version” and click OK
3. You should now see a column with the version number!

After string on the version column I found three assemblies with version 7.0.34.0:

Although most colleagues working on the project already had "updated" their assemblies and ruined their system, there was one colleague that had its day off. I called him up, asked for a zip file with his "old" assemblies, and after a quick patch of copying over the three "old" assemblies everything started working again.

A simple workaround

While still waiting for Sitecore to fix this issue, I created a simple workaround so we can finally continue working and deploying:

I added the "old" versions of the assemblies that were affected to the root of the project, and on the properties set Copy to Output Directory to Copy always.

This solves the issue for now, let's hope Sitecore comes with a solution fast.