CODEWITHSUNDEEP
c#azureazure-cosmosdbazure-functions
Chris B. Behrens
Chris B. Behrens

Reputation: 6295

Azure Function throws exception for Azure Document Client constructor (works in test harness)

I have an Azure function which ultimately executes this line of code:

cosmosClient = new DocumentClient(endpoint, key, mode, null);

This works perfectly in a large web app we use, and also within a test harness. When I call the code that calls this in an Azure function, it yields the following exception:

Exception while executing function: Functions.ColdStorageReset. mscorlib: Exception has been thrown by the target of an invocation. zzz.DataLayer: Method not found: 'Void Microsoft.Azure.Documents.Client.DocumentClient..ctor(System.Uri, System.String, Microsoft.Azure.Documents.Client.ConnectionPolicy, System.Nullable`1<Microsoft.Azure.Documents.ConsistencyLevel>, Newtonsoft.Json.JsonSerializerSettings)'.
2018-01-25T22:33:15.436

The version of Microsoft.Azure.Documents.Client.dll is 1.15.1.1 in all locations. I also tried this:

cosmosClient = new DocumentClient(endpoint, key, mode);

That gave me the same result.

Any thoughts?

Upvotes: 1

Views: 842

Answers (1)

Chris B. Behrens
Chris B. Behrens

Reputation: 6295

Sheesh...this was a real nightmare.

I eventually got past this initial conflict by just updating every dependency in sight. After that, it went away, without me ever understanding fundamentally what the problem was. Then, after another round of updates, it reappeared, this time with the Microsoft.IdentityModel.Clients.ActiveDirectory library, complaining that it couldn't load a version I wasn't referencing (and in the final tally, I truly wasn't referencing it).

After pulling my hair out trying to figure out where the reference came from, I got desperate and began decompiling the dependent dlls to look at the references. Incredibly, this worked, and I located a dependent dll that was referencing that old version of M.I.C.ActiveDirectory. The overall problem that was occurring here was this:

My library was referencing a dependent library that was, in turn, referencing the errant version of the problem library. This wasn't apparent when compiling locally because of binding redirects in the app.config.

Azure Functions don't (natively) support binding redirects, so the redirect has to be implemented manually. I found an implementation of this approach here: https://codopia.wordpress.com/2017/07/21/how-to-fix-the-assembly-binding-redirect-problem-in-azure-functions/.

Despite what the article indicates, it seems to be fine to call the redirect function every time the function executes. In short, you're adding a function app setting with the binding redirect info, deserializing that in code, and then calling some app domain jiggery-pokery to actually perform the redirect. It works beautifully.

Like the article notes, the only drawback is that you have to update the app setting every time you update the lib, but that's something I can live with for now.

Upvotes: 1

Related Questions