Assembly conflict in Azure in process function v4

@xztmp1 commented on [Wed Mar 01 2023](https://github.com/Azure/azure-sdk-for-net/issues/34637)

### Library name and version

Azure.Data.AppConfiguration

### Describe the bug

Azure.Data.AppConfiguration: Method 'AsPages' in type 'FuncAsyncPageable`1' from assembly 'Azure.Data.AppConfiguration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8' does not have an implementation.

### Expected behavior

We are converting a .net3.1 inprocess function to .net6 function v4.
The assembly is getting resolved properly on the localhost, but when it is deployed to Azure fails with the following error
Azure.Data.AppConfiguration: Method 'AsPages' in type 'FuncAsyncPageable`1' from assembly 'Azure.Data.AppConfiguration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8' does not have an implementation.

### Actual behavior

Azure.Data.AppConfiguration: Method 'AsPages' in type 'FuncAsyncPageable`1' from assembly 'Azure.Data.AppConfiguration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8' does not have an implementation.

### Reproduction Steps

These are the libraries referenced in the project file:
"Azure.Identity" Version="1.4.1"
"AzureExtensions.Swashbuckle" Version="3.3.2"
"AspNetCore.HealthChecks.CosmosDb" Version="3.1.2"
"Elevate.CacheServices.Client" Version="1.1.1"
"FluentValidation" Version="10.3.3"
"Microsoft.ApplicationInsights" Version="2.20.0"
"Microsoft.Azure.Cosmos" Version="3.22.1"
"Microsoft.Azure.WebJobs.Extensions.CosmosDB" Version="3.0.9"
"Microsoft.Extensions.Configuration.AzureAppConfiguration" Version="5.2.0"
"Microsoft.Extensions.Logging" Version="6.0.0"
"Microsoft.Extensions.Options.DataAnnotations" Version="6.0.0"
"Microsoft.NET.Sdk.Functions" Version="4.1.1"
"Newtonsoft.Json" Version="13.0.1"
### Environment

_No response_

---

@jsquire commented on [Wed Mar 01 2023](https://github.com/Azure/azure-sdk-for-net/issues/34637#issuecomment-1450953022)

Thank you for your feedback. Tagging and routing to the team member best able to assist.

---

@JoshLove-msft commented on [Wed Mar 01 2023](https://github.com/Azure/azure-sdk-for-net/issues/34637#issuecomment-1451011384)

I found a [StackOverflow post](https://stackoverflow.com/questions/74744117/azure-function-v4-migration-could-not-load-file-or-assembly-microsoft-extensio) that describes this exact scenario and recommends adding an explicit dependency for Microsoft.Extensions.Configuration.Abstractions to 6.0.0, as the issue appears to be due to an incompatibilty with 7.x which is pulled in transitively via your Microsoft.Extensions.Configuration.AzureAppConfiguration reference. Would you be able to try this workaround?

@fabiocav Is there any other docs we can point customers to for this issue? Is the above workaround accurate to your knowledge? I can also move this issue over to the functions host repo.

---

@xztmp1 commented on [Wed Mar 01 2023](https://github.com/Azure/azure-sdk-for-net/issues/34637#issuecomment-1451156167)

I tried as per your suggestion, but I am getting the same error:
Azure.Data.AppConfiguration: Method 'AsPages' in type 'FuncAsyncPageable`1' from assembly 'Azure.Data.AppConfiguration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8' does not have an implementation.

Also this happens only on Azure run time. It works fine on my localhost all the time

---

@JoshLove-msft commented on [Wed Mar 01 2023](https://github.com/Azure/azure-sdk-for-net/issues/34637#issuecomment-1451321534)

@xztmp1 could you share a zip containing a minimal repo?

---

@xztmp1 commented on [Thu Mar 02 2023](https://github.com/Azure/azure-sdk-for-net/issues/34637#issuecomment-1451955753)

Sorry I won't be able to share the code as it has proprietary information. This is a simple Http trigger function

---

@JoshLove-msft commented on [Thu Mar 02 2023](https://github.com/Azure/azure-sdk-for-net/issues/34637#issuecomment-1452237888)

Given that this appears to be an issue with the dependency resolution happening on the function host, and not locally, I will go ahead and transfer this issue to the functions host repo. The functions team should be able to debug further including having access to any server logs that may help them track down the issue.