Function startup fails when using System.Memory.Data 6.0.0

[EvanMulawski]

When attempting to start a v4 function app that uses System.Memory.Data 6.0.0, startup fails due to the following error:

[2021-12-14T19:33:56.629Z] A host error has occurred during startup operation 'd5f7db36-8721-4169-9c45-6fc51fc33530'.
[2021-12-14T19:33:56.638Z] App: Could not load file or assembly 'System.Memory.Data, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
Value cannot be null. (Parameter 'provider')

The version of System.Memory.Data delivered in Core Tools 4.10.1 is 1.0.2. Replacing this DLL with a 6.0.0 version in the Core Tools CLI directory resolves this startup error.

(Replaced %USERPROFILE%\AppData\Local\AzureFunctionsTools\Releases\4.10.1\cli_x64\System.Memory.Data.dll)

[EvanMulawski]

This is also preventing startup when deployed to Azure.

[EvanMulawski]

Workaround: adding <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput> to the project file.

[bartsokol]

Is there any update on this? We are experiencing the same issue when trying to make a call to blob storage on functions 4 / .NET 6. The workaround with _FunctionsSkipCleanOutput works, but it would be great to not be forced to use some workaround flags.

[bhehe]

Just ran into this myself; Is there a more broadly applicable fix to issues of this nature?
Seems like it would be a problem any time there's a version mismatch regardless of which dependency it is.

[aperez-litfibre]

Any update on this? I'm having the same problem

[LeszekKalibrate]

Hi @apawast
Is this fixed yet?

[ravindrank]

I ran into this issue as well after upgrading some of the packages to newest. Workaround seems to work for now..

[Sergey-Nosov-CloudFit]

Also run into this issue. The workaround worked. How dangerous is the workaround?

[bishwaranjans]

I am facing the same issue even after adding <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>

[Sergey-Nosov-CloudFit]

I am facing the same issue even after adding <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>

Try making sure that you are not referencing the System.Memory.Data 6.0.0 package directly in any of the projects. I believe this version has been marked as vulnerable, so perhaps something is blocking access to it.

[Spartan-Hex-Shadow]

I can verify that the FunctionsSkipCleanOutput fix works. Make sure to add it in the PropertyGroup

 <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
	<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
  </PropertyGroup>

[mattixittam]

I'm running into this problem running a NodeJS v4 function on the command line using the Core Tools cli func start (I have core tools 4.0.6280 and function runtime 4.834.3.22875, system is MacOS, core tools were installed using brew, if that matters).

This is the error produced:

Azure.Core: Could not load file or assembly 'System.Memory.Data, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.

The trigger seems to be the blobStorage trigger I'm using as an http/servicebus trigger works fine.

Is there a workaround in this situation? And if not, does this warrant a separate issue?

Edit: I've replaced the System.Memory.Data dll in the core tools install directory with the 6.0 version, and it now works, but this seems like something which should be solved in an update?

Edit2: This error also occurs when I deploy the app to Azure.

[LearnVinod]

Is there any solution for above issue. I am also facing same issue with System.Memory.Data 6.0.0.0 which not directly referenced but from Azure.Storage.Blobs
None of above workaround works for me.

[mattixittam]

I have worked around the issue by introducing a Service Bus Queue and having our API put a message on there after it has uploaded the blob. The Function App then responds to this message instead.

This overcomplicates what should be a very basic scenario, though. I can't believe that this bug has existed for 2,5 years (with the fix seemingly being to just ship a different DLL, but I admittedly do not have the full picture) and nothing has been done.

[LearnVinod]

Hi @mattixittam,
Can you elaborate the work around with steps which you have used, As I am stuck for last 2 weeks due to this issue

[mattixittam]

Sure:

I have an API backend which uploads a blob into the storage container. A function app should then react to this upload.

For the workaround, this API now also sends a message to a (new) Service Bus message queue, the message body containing the blob url. My original function app now has a service bus trigger instead of a blob trigger, reads the url from the message and retrieves the blob (using node-fetch in my case). From there the process works as if you had a working blob trigger.

[VelvetAndrea]

I also have this issue and need a fix asap.

We are using an Azure Function App: using net8.0 In-Proc. So far the workaround is only needed for 1 of our converted apps. Others work fine without the workaround. I haven't found a discernable pattern different between the 2 that are running fine and this problem app. I'll keep my eyes open.

Here are the packages we have included:

	<PackageReference Include="Azure.Security.KeyVault.Secrets" Version="4.7.0" />
	<PackageReference Include="Azure.Storage.Blobs" Version="12.22.2" />
	<PackageReference Include="Azure.Storage.Blobs.Batch" Version="12.19.1" />
	<PackageReference Include="Azure.Storage.Queues" Version="12.20.1" />
	<PackageReference Include="Microsoft.ApplicationInsights" Version="2.22.0" />
	<PackageReference Include="Microsoft.Azure.AppConfiguration.AspNetCore" Version="8.0.0" />
	<PackageReference Include="Microsoft.Azure.DurableTask.AzureStorage" Version="1.17.5" />
	<PackageReference Include="Microsoft.Azure.DurableTask.Core" Version="2.17.1" />
	<PackageReference Include="Microsoft.Azure.DurableTask.Emulator" Version="2.6.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.1.0" />
	<PackageReference Include="Microsoft.Azure.WebJobs" Version="3.0.41" />
	<PackageReference Include="Microsoft.Azure.WebJobs.Extensions" Version="5.0.0" />
	<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.DurableTask" Version="2.13.7" />
	<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Http" Version="3.2.0" />
	<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.ServiceBus" Version="5.16.4" />
	<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="5.3.3" />
	<PackageReference Include="Microsoft.Data.SqlClient" Version="5.2.2" />
	<PackageReference Include="Microsoft.Extensions.Configuration" Version="8.0.0" />
	<PackageReference Include="Microsoft.Extensions.Configuration.Abstractions" Version="8.0.0" />
	<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="8.0.1" />
	<PackageReference Include="Microsoft.Extensions.Logging" Version="8.0.1" />
	<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.5.0" />
	<PackageReference Include="Snowflake.Data" Version="4.1.0" />

[Arash-Sabet]

Who is the program owner or project manager to have him/her escalate the priority of this issue. The workaround does not work at all.
@fabiocav : Would you please have someone suggest or come up with a solution for this problem? This issue is a roadblock as it's happening across the board for e.g. when having an azure function's output binding write to an azure storage account's queue, or send a signalr message using the output binding, etc. A worth of months of programming no longer works!

[mattixittam]

I am about to put pressure from a different direction through a Support Request in the portal. Maybe that will help get things moving.

[Arash-Sabet]

@mattixittam Please share the URL so I can submit a similar request. This is not acceptable! I am wondering now many people have been stopped progressing by this issue!

[surgupta-msft]

This is a duplicate of issue - Azure/azure-functions-host#10575. We can use that issue to capture discussion and progress.