Azure-functions-core-tools: Loading the incorrect DLL version

[jsiegmund]

Via http://stackoverflow.com/questions/41453100/azure-function-loading-the-wrong-assembly/41481607?noredirect=1#comment70192246_41481607, as per request.

I've had a few rough encounters with the CLI when it comes to loading DLL's / dependencies. Basically in some cases the CLI will complain a certain DLL cannot be loaded, or it loads the wrong version which seems to be coming from the npm folder (error says Appbase = file:///C:/Users/jaspe/AppData/Roaming/npm/node_modules/azure-functions-cli/bin).

I'm sorry but I cannot provide definitive repro steps as the issue doesn't always occur. In most cases I was able to fix it by restarting Visual Studio. The weird thing is that restarting just the Func.exe process (within VS task runner) did not fix it! See SO post for some more additional detail.

[ahmelsayed]

@fabiocav this sounds like this https://github.com/Azure/azure-webjobs-sdk-script/issues/681 to me. I might be wrong.
I am using Microsoft.IdentityModel.Clients.ActiveDirectory.dll in the Cli to authenticate with azure, but I'd think that it shouldn't be loaded when you are running the host as it shouldn't be referenced. Autofac also shouldn't be initializing the types that depend on that assembly in host scenarios, so I'm a bit baffled.

@fabiocav do you know if maybe I need to setup a special assembly resolver that favors WorkingDirectory over app base or something like that?

[fabiocav]

I wouldn't expect you to have to do anything special here. The runtime tries to make sure dependency reference locations are honored and only white listed (shared assemblies) from the host's bin should be made available.

I'll take a look at this to see what is going on.

@jsiegmund I see your project.json on the SO question, if you can share the C# code to ensures this reproes with what you're seeing, that might be helpful.

[jsiegmund]

I've got a repo setup here; https://github.com/mstack/bots-jennifer, but as said it's not always a problem. By the way now that you mentioned Autofac, I had some issues with that as well as I had referenced a newer version in the assembly I was using for my function.

So just to get things straight; the function is loaded within the host process and thus makes use of the assemblies loaded in there right? Any additional ones are added within a separate process? So that would mean that referencing another version of one of the assemblies that the host uses might get you into trouble. And how about referencing a package that has a dependency on one of the assemblies that the host uses, but with a different version; how will that play out?

[jsiegmund]

Additional info.. What also seems to fail is when assemblies are put in a different location. I have a custom assembly which uses Microsoft.Bot.Builder as a dependency. I had that package referenced and the assembly itself is in the bin fplder of the specific function.

Next I decided to share the assembly amongst other functions. So i created a "shared" folder and changed the references to:

r "../shared/MyAssembly.dll"

Now when the function loads, the CLI starts complaining that it cannot load Microsoft.Bot.Builder. So apparantly it's trying to load the references but due to moving the assembly (or so it seems) it cannot resolve that dependency any more.

I think the "loading references" part of the CLI might need some additional attention :)

[fabiocav]

The CLI uses the runtime, so the behavior there is the same as what you'd see when deployed.

Shared assemblies are loaded in a different context than the one used by private references (which are essentially scoped per function). Direct and indirect dependencies should be deployed in both cases. Do you have the same set of assemblies deployed to that folder?

Is the repo above updated to reflect your current state? I'll investigate this and share my findings.

[jsiegmund]

Ok. I haven't pushed this to online yet so didn't check that. Repo is still behind, work in progress. I do not have the dependent assemblies in the same folder, but also didn't have them in the bin folder before. The dependencies are loaded using a NuGet package.

So:

• Custom assembly depending on Microsoft.Bot.Builder in bin folder: working. Microsoft.Bot.Builder is not in the folder, loading through NuGet.
• Move custom assembly in ../shared folder (same dependency): stops working

[ahmelsayed]

Sorry I haven't been following this, so I'm curious about the status at the moment. @jsiegmund, @fabiocav any TL;DR for me here? :) I'm trying to round up 1.0.0.beta.10 for a release.

[jsiegmund]

Sure :) TL;DR => there needs to be better documentation on how assemblies + references are loaded. Specifically: bin folder, shared folder (for multiple functions) and NuGet assemblies. Appears as if NuGet packages loaded as part of project.json are not loaded (?) when referenced from an assembly located in a shared folder. Might be by design, don't know. If by design: how can we load NuGet packages referenced by shared assemblies? Also would love some additional documentation on app domain scopes: what can reference what and in which situations can you load multiple versions of the same assembly in different scopes (per function, per instance?)

[mariobrosch]

Have the same issue, want to know the solution, anyone?

I created a Windows Forms Application. The Azure AD logic is created in a separate class library which is loaded on runtime. The Windows Forms Application is working like a charm.

Now I build a WPF application. Loaded the assembly (in my opinion everything in the projects are the same) but gives me the error.

Manually loading (outside of nuget) will be the solution?

[tafs7]

This issue seems to be related to an issue I opened on the runtime repo (https://github.com/Azure/azure-webjobs-sdk-script/issues/1217).

I've a private assembly which references a nuget package (SharePoint CSOM). When I deploy the private assembly to my function's bin folder, and define a dependency to the nuget CSOM package in the function's packages.json file, the CSOM apis don't seem to have enough permissions to execute from that scope (see linked issue for details).

So I moved my private assembly to a higher level folder, wwwrootsharedbin, adjacent to my function folder. Now, the runtime cannot load the reference to the nuget package from the sharedbin\myprivateassembly.dll, as it cannot seem to find the csom DLLs from this scope.

To solve this, I downloaded the nuget package locally and copied the DLLs from the nuget package into my app's wwwroot\sharedbin" folder, along with my private assembly. Then, I removed the nuget dependency from the function's packages.json. Now, the function is able to load all the assemblies, since they all behave as private assemblies deployed on the sharedbin folder. Not ideal....

I would like to know these things:

1. why my private assembly, when in the function bin folder, did not have enough permissions to run the CSOM code correctly
2. why the nuget pkg, from from the function scope, could not be leveraged by the private assembly, when it was deployed to the sharedbin folder
3. what is the recommendation for this scenario?
4. Is there a way to reference nuget packages that can be leveraged by private assemblies in sharedbin folder?
5. I could not find any documentation or definitive guidance on how to share DLLs across functions within same app: some people say to use "wwwroot\shared" folder, some say to use "wwwroot\sharedbin", and some say "wwwroot\shared\bin". Does it matter? Will *.dll be scanned from any folder path within wwwroot??

thx

[fabiocav]

@tafs7 these are slightly different issues. I'll add some details that will hopefully answer some of your questions on the other issue, but just for clarification:

• Private references are deployed in the functions bin folder (i.e. wwwroot\myfunction\bin) and they are loaded into a different context (no load context) and side-by-side and multi version loading is supported, different copies are loaded per function. There are some other nuances we're working on documenting, but those are the key things.
• The approach we've discussed and you've mentioned above where assembly files are reference from a shared location (e.g. wwwroot\sharedbin) is the _shared assemblies_ model, where those assemblies are shared accross function and use the load-from context and shared across your functions. The folder name does not matter, so you could have any of the names you've mentioned above (sharedbin, shared, shared\bin or just wheremyassembliesgo) and the result would be the same. There's no scanning process, what matters is the reference path used by your function, which is what will be fed into the function assembly context and resolver when your function is compiled.

(removed an inaccurate remark about shared assemblies to avoid confusion)

As mentioned above, I'll keep all future updates as it relates to your issue on what you've opened in the script repo so we don't have this information scattered and to make sure to don't mix these issues up.

[fabiocav]

@mariobrosch I just want to clarify... are you having issues working with Azure Functions? Or is this just in the context of Winforms and WPF?

[fabiocav]

@jsiegmund sorry about the delay... have missed some on the discussions on this repo. We have been working on those details and have this issue open to track documentation progress https://github.com/Azure/Azure-Functions/issues/113

[jsiegmund]

I gave up eventually because I had other issues related to the bot framework bugging out when loading stuff from private assemblies. For the time being I'm back on Web API, will try Functions / Bot Service again later.

[fabiocav]

Sounds good. I'll close this so it isn't hanging as an open issue but please let us know if you run into problems and feel free to reference this so we can reopen if needed.

[mariobrosch]

@fabiocav Still having problem loading the assemblies in combination with WPF application. This is the error.

Could not load file or assembly 'Microsoft.IdentityModel.Clients.ActiveDirectory, Version=3.13.8.999, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Could not load file or assembly 'Microsoft.Azure.ActiveDirectory.GraphClient, Version=2.1.10.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

[fabiocav]

@mariobrosch this repo is not the best place for issues with WPF, Stack Overflow/MSDN Forums would be your best bet for that.

[mariobrosch]

oke, thought the question was based on the OP's question, but created a question on stackoverflow (put the link for people with same problem): Stackoverflow