_FunctionsSkipCleanOutput

[Warning: this is what I understood. Use at your own risk.]

There are cases in which an Azure function throws errors at runtime because of issues in finding a required dll. An sample here: https://github.com/fhtino/publicissues/tree/main/az-func-cannot-load-assembly The function uses Azure.Data.Tables 12.9.1 and Azure.Storage.Blobs 12.22.2. When the code starts using TableClient, the runtime throws an exception like:

System.IO.FileNotFoundException: 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. 
File name: 'System.Memory.Data, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

System.Memory.Data.dll is also referenced by Function Runtime, even locally by Azure Functions Core Tools. When Visual Studio compiles the project, it remove duplicated assemblies or assemblies already referenced by the runtime.

To solve the issue, it is necessary to instruct Visual Studio to not “clean up” the output folder, by adding _FunctionsSkipCleanOutput true to the project file:

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

This is the normal output folder:

After adding _FunctionsSkipCleanOutput true:

Now, the function application runs as expected and, inspecting the loaded modules with Visual Studio, we can see the two different System.Memory.Data loaded into memory.

Note: I really do not understand the reasons of the approach… perhaps to reduce the overall size of the deployed application… I would suggest to implement a less aggressive algorithm. In the example, it would be enough to just leave the System.Memory.Data. dll into the output folder to solve the issue. Tested by myself, manually copying the dll, and the app is running fine.