search

Azure / Azure-Functions

1.12k stars 199 forks source link

Powershell function app -- System.IO.FileLoadException: Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 #1747

Closed seanmbills closed 3 years ago

seanmbills commented 4 years ago

I've tried asking this similar question in a few places, but so far I've come across nothing that adequately addresses my problem/answers the question. We currently have a powershell function app running on function version v3, using Powershell Core v6.2.7. As part of our function, we have a need to reference a 3rd party nuget package which has a dependency on the System.Configuration.ConfigurationManager nuget (specifically v 4.7.0 of this nuget). It's important to note that this 3rd party nuget only compiles against .netstandard2.0, net452, net462 and only against a x64 architecture. Our powershell function app is running on a x64 architecture so I'm not concerned on that part. But the issue that we're seeing is when trying to use/reference this nuget, we repeatedly get an exception similar to the below: System.IO.FileLoadException: Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

The issue here is that azure function seems to be repeatedly referencing another assembly of this nuget, specifically the 4.0.1.0 version. If I use this line of code in my powershell function: [System.Configuration.ConfigurationManager] then I get output similar to the below: `2020-10-07T20:41:24.100 [Information] OUTPUT: DeclaredProperties : {Boolean SetConfigurationSystemInProgress, Boolean SupportsUserConfig, System.Collections.Specialized.NameValueCollection AppSettings, System.Configuration.ConnectionStringSettingsCollection ConnectionStrings}

2020-10-07T20:41:24.101 [Information] OUTPUT: ImplementedInterfaces : {} 2020-10-07T20:41:24.101 [Information] OUTPUT: IsInterface : False 2020-10-07T20:41:24.101 [Information] OUTPUT: MemberType : TypeInfo 2020-10-07T20:41:24.101 [Information] OUTPUT: Namespace : System.Configuration 2020-10-07T20:41:24.101 [Information] OUTPUT: AssemblyQualifiedName : System.Configuration.ConfigurationManager, System.Configuration.ConfigurationManager, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 2020-10-07T20:41:24.102 [Information] OUTPUT: FullName : System.Configuration.ConfigurationManager 2020-10-07T20:41:24.102 [Information] OUTPUT: Assembly : System.Configuration.ConfigurationManager, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 2020-10-07T20:41:24.102 [Information] OUTPUT: Module : System.Configuration.ConfigurationManager.dll 2020-10-07T20:41:24.108 [Information] OUTPUT: IsNested : False`

I'm honeslty just confused at this point. We're running on function runtime 3.0.14492.0 and if I navigate to the Kudu location at "D:\Program Files (x86)\SiteExtensions\Functions\3.0.14492.0\" I can see that the System.Configuration.ConfigurationManager dll there is assembly version 4.0.3.0 (the one i'm looking for). But the system still seems to be referencing 4.0.1.0

Why? What can i do to circumvent this in powershell? Can I circumvent this? Is there a way to redirect the binding of this assembly for my powershell functions so that I can get around this issue?

StingyJack commented 4 years ago

Have you tried using Add-Type at the beginning of your script/program to specifically load the assembly you want to use?

Also, assembly resolution can be managed in powershell apparently (I've only tried this in .net applications, but see no reason why it wouldnt work)..

v-anvari commented 3 years ago

Hi @seanmbills , Apologies for the delayed response, can we know if you were able to find a solution.

ghost commented 3 years ago

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.

StingyJack commented 3 years ago

@v-anvari you took 238 days to respond to the author. Your bot needs to wait at least as long for the author to respond before closing this issue.

That's what would be fair.

v-anvari commented 3 years ago

We apologize for the delay, the issue was somehow lost in the trace, we are happy to help you. Can you provide a repro for the error

ghost commented 3 years ago

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.