BP cannot find DLL even though the path is included

[jefuytterhoeven]

Hi all, 

I was wondering if anyone knew what the solution to my problem is.

I have added the microsoft.identify.client to my object but it seems that it cannot find it.

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

I don't get any compiling errors. And I have checked that the file is indeed located there.

Kind regards.
Jef Uytterhoeven.

PS. this is to be able to send emails with BP. I am also starting to look into different ways of sending mails. I currently use a vbo provided to my by the consultants that set BP up for us. As a plan B I am also trying the outlook vbo in the digital exchange. This one doesn't work that well for me since we don't have outlook on the machines where BP runs.

[ewilson]

Hello @jefuytterhoeven,

From the screenshots, I see you've added the reference for the namespace, but I don't see an entry for the path to the actual DLL in the External References list. Have you tried adding it?

Cheers,
Eric​

[jefuytterhoeven]

Hi @ewilson You are right it was not in the screenshot 🙂
However it is there. and still does the same thing. ​

[zdenek.kabatek]

Hi, 

For some dlls (I was not able to find out any rule for that) I had to put them in Blue Prism directory which resolved the issue. Did you try that?

Regards

Zdenek

[jefuytterhoeven]

Hi
@Zdeněk Kabátek.
I have not tried putting it there. It has crossed my mind. But am currently unable to that due to system rights. I had put it next to another dll I used hoping that would sufice.​

[ewilson]

@jefuytterhoeven,

@Zdeněk Kabátek makes a good point. My rule-of-thumb is to always place any additional 3rd party DLLs in the Automate installation folder. However, there are two things to be aware of:

1. On occasion, there may already be a version of the DLL you're looking for in the Automate install folder, but it's not the version you require. Be careful with replacing DLLs in this case, and be sure to test, test, test if you do. Also, make sure to archive a copy of the DLL you're replacing, if it comes to that, so you can revert if necessary.
2. Sometime you will receive the error you're seeing, but the underlying issue isn't really the DLL mentioned in the error message. Instead, it's a DLL which the error message DLL depends on. Those situations are a little more of a pain as you then have to start doing some deeper digging to determine the appropriate dependency versions, etc.

​
Cheers,
Eric​

[jefuytterhoeven]

Thanks all of the answers.

I got it to work by moving the file to the blue prism installation directory.

Kind regards

[Denis__Dennehy]

If my memory serves the correct way to sort this would be to add the dll path into the Windows PATH environment variable - the references in there are where applications should look for dlls.  If that does not work then I agree copying the dll to the Blue Prism Automate folder would also work if you are allowed to copy dlls around in production environments.

And the titbit for today is that Automate was the original name of the Blue Prism product,  hence the Automate.exe and the Automate folder.  At some point the product started to be called the same name as the company... which I always found a trifle confusing...

[ELI.BORWICK]

I am having this same issue, there are several reports across the forum and stack exchange where Blue Prism does not recognize dlls outside of the automate folder, even if the fully qualified path is listed in the object and the folder is listed under the Windows PATH environmental variable. The scenario where this is necessary is when there is an existing version of the dll in the automate folder, but the object requires a different version and testing all automations to verify that the new version will not break other processes is not possible.