external DLL reference question

[Walter.Koller]

Hello,

I am posting here because the issue came up when working with MSAL that needs external DLL.

When we copy the Microsoft.Identity.Client.dll file to the folder where automate.exe is located it works.

When we copy the dll to another folder Blue Prism will bring up an error message because of compile error. This make sense as Blue Prism does not know where this dll is.

We can resolve the compile error by qualifying the full path to the dll. I would assume Blue Prism find the dll, can resolve dependencies and namespaces as there is no compile error.  

Although BP seems to be fine with the reference to the dll we get this error at runtime:

Internal : Could not execute code stage because exception thrown by code stage: Could not load file or assembly 'Microsoft.Identity.Client, Version=4.42.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae' or one of its dependencies. The system cannot find the file specified.

Internet provides me solutions for C# projects but not how to resolve this problem for compiled executables like Blue Prism. 

I just created similar situations with Microsoft.Office.Interop.Outlook.dll and it does not matter where this dll is located, next to automate.exe or some other folder as long as the location is fully qualified.

What are we missing to make Microsoft.Identity.Client.dll work when located in a folder separate to automate.exe?

Thanks a lot,

 Walter

[GeoffHirst]

Hi @Walter.Koller 

Thank you for being a SS&C Blue Prism customer, and for using Blue Prism.

This is a frustrating issue, especially as you think everything should be in order.

When I see this, the first thing I look for is the actual version of the file the (4.42.1.0 bit) on the file that you have referenced to Blue Prism. My thoughts are that the file you have is older or, more likely, more recent than the one being requested. It's a whole new kind of 'dll hell'. 

So, please, give this a look over and see if the versions are different, if not, we do have a referencing issue that isn't working out, if they are different, you should be able to find the exact version you need on nuget.org.

Please come back to me if you continue to have issues and we will see what else we can do.

regards

[Walter.Koller]

Hello @GeoffHirst 

Thanks for the reply.

The version number shown in the error message is always the version number of the DLL. If we switch to another version then the version number of this file is shown. This indicates the issue is not with the DLL but with something else like dependencies and assemblies. I have checked the dependencies of this version of the DLL and it says it does not have any dependencies. 

We use the same DLL file and version (copy & paste) in all locations for our tests. 

I try to condense our situation: (*MSAL = Microsoft.Identity.Client.dll; *Outlook = Microsoft.Office.Interop.Outlook)

DLL	Location	Reference	Result
MSAL	no dll		compile error
MSAL	c:\temp\		assembly error
MSAL	ProgFiles\BP\..		success
Outlook	ProgFiles\BP\...		success
Outlook	c:\temp\		success

So my questions is why does line 2 results in an dependency/assembly error when doing the same with Outlook dll it works fine. 

The reason why I am asking is to better understand if this may impact us in future when using other DLL and maybe resolve this issue before it hits us when we need it and avoid increased efforts due to manually copying DLL in program files folders, which needs several exceptions approved by our IT Security department. 

However, I am also happy with a confirmation of DLL can be references with full path and still work, in general and MSAL DLL is a special case for some reason.

Many thanks in advance,

 Walter 

[GeoffHirst]

Hi @Walter.Koller 

Firstly, yes, you can use full pathnames. I cannot explain why you are having issues with the file when its in the temp folder, other than it is a dependency issue.

I downloaded the dll you mentioned from nuget, and when I opened it in DotPeek, I could see the references shown above.

I hope this helps move your issue forward.

regards