Provide the steps required to reproduce the problem:
System.Text.Encoding.CodePages nuget packageEncoding.RegisterProvider(CodePagesEncodingProvider.Instance); to functionFunction app is executed without error
The following error occurs and the function cannot be executed.
[2021-01-15T07:00:17.378Z] A host error has occurred during startup operation 'e356b46a-f0fb-44a1-8494-df0ad91f3d36'.
[2021-01-15T07:00:17.380Z] FunctionApp34: Could not load file or assembly 'System.Text.Encoding.CodePages, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. 指定されたファイルが見つかりません。.
Value cannot be null. (Parameter 'provider')
_FunctionsSkipCleanOutput settingSystem.Text.Encoding.CodePages to v4.7.1I 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 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.
Most helpful comment
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: