Can confirm. Also facing this issue.

Workaround I have seems to be having System.Memory.Data 6.0.0 installed as a separate NuGet package, building the solution, and copying the System.Memory.Data.dll file to the bin subdirectory in the bin folder, at least in Debug. (I assume Release would be the same way).

Which leads to a folder structure like bin\Debug\net8.0\bin, where I had to copy the dll from bin\Debug\net8.0

For whatever reason, this dependency isn't getting copied to that bin subfolder.

Side effect: Any time I make a change to the Azure Function project and rebuild, the copied System.Memory.Data.dll file disappears, and the error pops up again.

@fhtino - FYI.

Facing the same issue recently while trying to use Azure.Storage.Blobs

Having same issue with Microsoft.Azure.WebJobs.Extensions.Storage.Queues.

System.Private.CoreLib: Exception has been thrown by the target of an invocation. Microsoft.Azure.WebJobs.Extensions.Storage.Queues: Could not load file or assembly 'System.Memory.Data, Version=6.0.0.0, Culture=neutral. The system cannot find the file specified.

I am also facing the same issue

The prescribed workaround (see above: "<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>") worked.
I guess I need to update to an isolated process, as recommended by Microsoft, sooner than I thought.

Same issue with using Azure.Security.KeyVault.Secrets and callingSecretClient.GetSecretAsync. @nodeomega's workaround worked for me. Good looking out. Hopefully this gets fixed soon.

Wer are using nodejs and as such can not use @nodeomega 's workaround.
Is there any way to maybe downgrade, so it can work again?

Alternative workaround

  <ItemGroup>
    <FunctionsPreservedDependencies Include="System.Memory.Data.dll" />
  </ItemGroup>

Having the same issue for the latest Microsoft.Azure.Functions.Worker.Extensions.SignalRService 1.15.0 version. It blocks users from using managed identity to connect to SignalR Service.

We have the same issue with Microsoft.Azure.Functions.Worker.Extensions.SignalRService 1.15.0. Downgrade to 1.14.1 resolves the issue and we can use the System-assigned managed identity again.

Alternative workaround

<ItemGroup>
 <FunctionsPreservedDependencies Include="System.Memory.Data.dll" />
</ItemGroup>

I can confirm that this alone as the single change, made it work as expected.

We have the same issue with Microsoft.Azure.Functions.Worker.Extensions.SignalRService 1.15.0. Downgrade to 1.14.1 resolves the issue and we can use the System-assigned managed identity again.

Had the same issue, this is the only thing that solved it. Unfortunately version 1.15.0 kept giving me: Microsoft.Azure.WebJobs.Extensions.EventHubs: Could not load file or assembly 'System.Memory.Data, Version=6.0.0.0, Culture=neutral'. The system cannot find the file specified.

Hi @jsquire , the workarounds that add some properties in the project file still don't work for Microsoft.Azure.Functions.Worker.Extensions.SignalRService 1.15.0.

The not working workarounds include:

• <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
• <FunctionsPreservedDependencies Include="System.Memory.Data.dll" />

If you need any other information from me, please let me know.

<ItemGroup>
 <FunctionsPreservedDependencies Include="System.Memory.Data.dll" />
</ItemGroup>

This workaround did not work. We need a permanent solution. This issue must be addressed ASAP as it's a roadblock.

I spent a significant amount of time resolving an issue involving dependencies on System.Memory.Data 6.0.0. Locally, I managed to get things working by manually replacing the DLL with version 6.0.0 in the AzureFunctionsTools folder at:

C:\Users\User\AppData\Local\AzureFunctionsTools\Releases\4.100.0\cli_x64

However, on Azure, this isn't possible due to the lack of access for patching DLLs directly. After extensive troubleshooting, I discovered that the recent upgrade to Microsoft.Azure.Functions.Worker.Extensions.SignalRService 1.15.0 was the root cause. Downgrading to 1.14.1 resolved the issue.

This complex dependency setup clearly needs addressing. Ideally, we should also have more control over configuration in Azure to facilitate such troubleshooting. If there are any ways to achieve this, please let me know.

Having used Azure Functions since v1, I’ve found it to be a convenient but often frustrating service. The migration paths (e.g., isolated functions, v1 to v2) have been rocky, and these issues make maintaining reliable services challenging. I encourage proactive measures to improve stability in the Azure Functions ecosystem. 🙏

I've got the same issue here regarding the SignalRService package. None of the workarounds fix anything in this instance, other than reverting to 1.14.1, including things I had tried from other places (for example using assembly binding redirects)

Would love to see a resolution for this.

The current mitigation is to apply update the project configuration mentioned in the issue if using the .NET in-proc model:

<ItemGroup>
    <FunctionsPreservedDependencies Include="System.Memory.Data.dll" />
</ItemGroup>

For the .NET Isolated model, the impacted package (SignalR) must be downgraded. We will work with the appropriate team to delist in the meantime, as this was an invalid update. We'll also be working with them to ensure this issue is prevented in the future.

A fix for this will be rolling out with the next host deployment. Thank you all for the report and patience.