I have the same problem. The publish targets remove a lot of stuff.
The System.Text.Encoding.CodePages.dll is copied into bin/runtime/netstandard2.0.
It seems like files under bin/runtime/** are not probed at all.
I've tried this with both V2 and V3 runtime, including pretty much all framework targets since netstandard2.0.

I managed to get the file copied to the bin folder locally with an extra target in my .csproj, but I couldn't figure which target / filegroup / property to use in order to include the file in the .zip that is published.
So for now I grudgingly copy the file into the function's bin folder using the kudu console.

Let me know if I can help by providing more details. Here's my targets:

  <Target Name="ForceCopyCodePages" AfterTargets="_FunctionsBuildCleanOutput">
    <Message Importance="High" Text="Copying messed up deps to $(OutputPath)" />
    <Copy SourceFiles="$(OutputPath)bin\runtimes\win\lib\netcoreapp2.0\System.Text.Encoding.CodePages.dll"
          DestinationFolder="$(OutputPath)bin"/>
  </Target>
  <Target Name="ForcePublishCodePages" AfterTargets="_FunctionsPostPublish">
    <Message Importance="High" Text="Copying messed up deps for publish to $(PublishDir)bin" />
    <Copy SourceFiles="$(OutputPath)bin\runtimes\win\lib\netcoreapp2.0\System.Text.Encoding.CodePages.dll"
          DestinationFolder="$(PublishDir)bin"/>
  </Target>

Hi @shibayan, Apologies for the delayed response, please let us know if you were able to find a solution to this, if not, we would like to reproduce your project to understand the error better, could you give us the repro steps or test Zip file if possible which can repro the error.

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@v-bbalaiagar The workaround is described in the first comment.
The root cause of this problem is that the Azure Functions SDK deletes any assembly with a matching name without considering the assembly version. It is necessary to delete the assembly only if it is the same or lower version than the assembly that Functions Runtime has, and not delete it if it is a larger version.

@shibayan, the workaround is not in the first comment, as per my understanding the author of those targets tried them out but it didn't work.

Note that I'm experiencing the same issue, and so far only workaround is to manually move the dll using kudo.

@SOFSPEEL I have confirmed that it works with the first workaround I wrote. It's not wrong.

Known workarounds
Adding _FunctionsSkipCleanOutput setting
Downgrade System.Text.Encoding.CodePages to v4.7.1

@shibayan thanks for the feedback as I was unclear as to which workaround you were referring to. Ultimately what fixed it for me was just doing this, which seems to prevent the deletion of the runtime dlls that now deploy to the wwwroot/bin folder
<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>

Wondering why the need to 'Downgrade System.Text.Encoding.CodePages to v4.7.1'?

I should add I'm targeting as follows:
<TargetFramework>netcoreapp3.1</TargetFramework>

Thanks

I have the same problem, except with System.IO.Pipelines, Version=5.0.0.0, while connecting to redis using the StackExchange.Redis 2.2.4 package.

Adding <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput> to the .csproj file resolves the issue of not being able to connect to Redis. BUT: it also causes the EventHubTrigger not to fire. When I remove it, the event hub trigger fires again, but connecting to redis throws the exception again.

And what I need unfortunatly is to react to an event hubtrigger and read some date from redis to decide what to do with the event.

Hope anybody can help mee, or at least that this scenario is considered while solving this issue.

Kind regards,
Rob.

ps. When I look at the verbose logging I notice that this part of the logging:
[2021-04-07T12:33:45.165Z] EventHubOptions
[2021-04-07T12:33:45.177Z] {
[2021-04-07T12:33:45.179Z] "BatchCheckpointFrequency": 3,
[2021-04-07T12:33:45.180Z] "EventProcessorOptions": {
[2021-04-07T12:33:45.184Z] "EnableReceiverRuntimeMetric": false,
[2021-04-07T12:33:45.186Z] "InvokeProcessorAfterReceiveTimeout": false,
[2021-04-07T12:33:45.191Z] "MaxBatchSize": 400,
[2021-04-07T12:33:45.193Z] "PrefetchCount": 512,
[2021-04-07T12:33:45.195Z] "ReceiveTimeout": "00:01:00"
[2021-04-07T12:33:45.196Z] },
[2021-04-07T12:33:45.200Z] "PartitionManagerOptions": {
[2021-04-07T12:33:45.207Z] "LeaseDuration": "00:00:30",
[2021-04-07T12:33:45.209Z] "RenewInterval": "00:00:10"
[2021-04-07T12:33:45.210Z] },
[2021-04-07T12:33:45.212Z] "InitialOffsetOptions": {
[2021-04-07T12:33:45.215Z] "Type": "",
[2021-04-07T12:33:45.221Z] "EnqueuedTimeUTC": ""
[2021-04-07T12:33:45.225Z] }
[2021-04-07T12:33:45.226Z] }
Is present only when skip clean output is true.

Hi @shibayan, We would like to know if you can close this issue or if you are still looking for a solution

@rob4bertus ,Can you create a new issue by explaining your scenario as it looks like a different scenario and not duplicate

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

Why is this about to be closed? I am seeing the issue myself running latest Functions SDK 3.0.12

Please don't close this issue. A fix is needed so that the perpetual use of a workaround is not required.

@kashimiz, @v-bbalaiagar can some one investigate the root cause and develop a fix?

@aaronhudon ,@bryanknox The bot has closed the issue due to in-activity. We shall keep the issue open.

FunctionsPreservedDependencies seems to be the documented way to deal with these issues, it can have fewer side-effects than _FunctionsSkipCleanOutput due to it being targeted at specific assemblies.

It requires Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator 1.2.1 or newer, version 1.2.2 is included by Microsoft.NET.Sdk.Functions 3.0.12 (which was released a few days ago).

@shibayan This worked for me:

<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.12" />
  <PackageReference Include="System.Text.Encoding.CodePages" Version="5.0.0" />
</ItemGroup>
<ItemGroup>
  <FunctionsPreservedDependencies Include="System.Text.Encoding.CodePages.dll" />
</ItemGroup>

@rob4bertus For Redis we were able to successfully replace our use of _FunctionsSkipCleanOutput with <FunctionsPreservedDependencies Include="System.IO.Pipelines.dll" />, although I haven't tested with an Event Hubs trigger.

Thanks for the update. Currently (with some help :)) we have got it running with _FunctionsSkipCleanOutput. (We had to downgrade some dependencies to do that, but that's ok for us). When I have some time I will test this new option.

Maybe version conflicts between dll's is one of the side effects you speak about?

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.