Issues after upgrading from ServiceStack 4.5.14 to 6.9

ServiceStack Authentication
21

Thanks for your help. we have implemented as per your suggestion. With the new ServiceStack 6.9 version I am getting another exception recently from AppHost:

Error message:
System.IO.FileLoadException: ‘Could not load file or assembly ‘Microsoft.Bcl.AsyncInterfaces, Version=5.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)’

CallStack information:

at ServiceStack.ServiceStackHost…ctor(String serviceName, Assembly assembliesWithServices)
at ServiceStack.AppHostHttpListenerBase…ctor(String serviceName, Assembly assembliesWithServices)
at HP.HPTRIM.ExchangeLink.AdminConsole.AppHost…ctor() in C:\REPOS\trim\CSharp\HP.HPTRIM.ExchangeLink.AdminConsole\Program.cs:line 26

Looks the below ServiceStack code is looking for exact version of 5.0? Currently i am referring Microsoft.Bcl.AsyncInterfaces version 7.0. Is this something i need to change back to 5.0 to compatible with Servicestack?

 protected AppHostHttpListenerBase(string serviceName, params Assembly[] assembliesWithServices)
            : base(serviceName, assembliesWithServices)
        { }

I am surprised to see this issue after my latest upgrade on Visual studio 2022.

22

You would need to downgrade to continue to using ServiceStack v6.9, otherwise I’ve just upgraded the dependencies to use Microsoft.Bcl.AsyncInterfaces v7.0.0 from v6.10.1 that’s now available in the latest pre-release NuGet packages

1 Like
23

Thanks for the response. Does downgrading to Microsoft.Bcl.AsyncInterfaces v5.0 will not have any impact with our ServiceStack v6.9 functionalities or if there will be any impacts what are they? Cause we have done our development changes with servciestack v6.9. We want to make sure there won’t be any issues on servicestack APIs on downgrading Microsoft.Bcl.AsyncInterfaces v5.0.

24

That’s the version the packages were built against, so that’s going to be the recommended version to use.

25

Thanks, that’s helpful. One last question, this is one of our last issue we are facing with the upgrade.

When running our project with ServiceStack, we will register the license using Licensing.RegisterLicense(“licenseKeyStringValue”). When registering the license, we are receiving the below error message,

Could not load file or assembly ‘System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).

StackTrace:
at System.MemoryExtensions.AsSpan(String text)
at ServiceStack.Text.Jsv.JsvReader`1.Parse(String value)
at ServiceStack.Text.TypeSerializer.DeserializeFromString[T](String value)
at ServiceStack.LicenseUtils.ToLicenseKeyFallback(String licenseKeyText)
at ServiceStack.LicenseUtils.RegisterLicense(String licenseKeyText)
at HP.HPTRIM.Service.TrimUtils.LoadLicense() in

Why ServiceStack is expecting this dependency? By default our compiler has the latest version of this DLL, but looks ServiceStack is expecting with the System.Runtime.CompilerServices.Unsafe v4.0.4.1.

26

This is typically due to a missing assembly binding redirects, have a look at Resolving Runtime Assembly Loading Issues docs for solutions and workarounds. Basically your assembly binding redirect needs to reference the version of System.Runtime.CompilerServices.Unsafe that’s loaded.

27

Thanks for the response. I have included binding redirects. The binding redirect works for Asp.net projects. For my Asp.net projects, i have pointed the binding redirects in web.config. For our VSTO projects i have included binding redirect on App.config file.

In our VSTO C# addin project developed, which calls ServiceStack. When running those addin projects even with the binding redirects, i am still facing the same issue. In this case what could be the case as it is not working only for Addin projects?

28

Don’t know what AddIn projects use, I’m assuming just App.config, so the only thing I’d check is to make sure you’re trying to the correct version the project is referencing in the redirect.

29

I have a .bat file which will copy the System.Runtime.CompilerServices.Unsafe.dll with version 4.0 in our /bin folders to resolve this problem.

I could see System.Runtime.CompilerServices.Unsafe v6.0 DLL is getting shipped/overwriting my existing copied file into /bin folders automatically once I have compiled my solution. I am not sure the reason why the version 6.0 DLL is getting shipped automatically if I compiled the solution.

Currently as the compiler shipping the version 6.0 DLL automatically.

image
image537×625 15.1 KB

i have added binding redirects like below:


      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>

This above binding redirect works for web projects. For my console projects it is not working, and i have changed the binding version to 6.0.21.52210 and 6.0.21.0. Still same issue “Could not load file or assembly ‘System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies.”

If i able to find the root cause of why the compiler generating the DLL with v6.0, and if i stop that it will be resolved i believe.

30

You’ll want to use the Assembly Version not the Assembly File Version which you can find by in an assembly inspector like JetBrains dotPeek, e.g:

image
image1554×1072 148 KB

Which is typically a major version like 6.0.0.0. This will need to match with the Assembly Version of System.Runtime.CompilerServices.Unsafe.dll in your projects bin/ directory.

Typically that’s all that’s needed to resolve Assembly version errors, I expect non Web Applications to use App.config in their host project to store their assembly binding configuration. You can get more information about assembly errors and can even specify which assembly .dll the App should use by overriding the AppDomain.CurrentDomain.AssemblyResolve event, see this answer for an example:

This sounds very fragile and I would always recommend against overriding the assemblies the build system uses to build your project against.

31

Missed to add attribute value xmlns=“urn:schemas-microsoft-com:asm.v1” in <assemblybinding> adding that fixes the problem.

Tested in my development environment after all the changes with ServiceStack v.6.9. In my development environment it’s working as expected.

Strange behavior is happening after the installation with the changes. In installation build, I am receiving the same issue “Could not load file or assembly ‘System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies.”. In installation folder(C:\Program Files\Micro Focus\Content Manager) all our binaries are shipped, even our app.config files.

My entire App.config for reference:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
  </startup>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

I am not sure the issue resolved in dev environment, but not after installation(compared both installation and dev files, every files and required DLLS are available). There could be any reasons for this?

32

The only way I’ve ever needed to resolve Assembly binding redirects is to add an assembly binding to the version that’s running in the App. If the binding isn’t working you’ll need to double-check the version that’s in the bin/ folder of the App that has the issue.

On the rare occasion where Assembly binding doesn’t work you can manually load and return the assembly in the AssemblyResolve event, here’s an example of this in StackOverflow: