Logo
My Account |  Site Map | Contact Us  
Welcome Guest Search | Active Topics | Sign In | Register

External Dependency with EO.WebBrowser.Winform Options
GMoney
Posted: Friday, September 11, 2020 3:18:15 PM
Rank: Newbie
Groups: Member

Joined: 9/11/2020
Posts: 3
I have a need to run several versions of EO.WebBrowser for backward compatibility. I am trying to isolate the EO WebBrowser 2020 DLLs in their own folder. I am referencing the DLLs in my Visual Studio WinForms project. When the project starts up I get a "System.IO.FileNotFoundException error on EO.WebBrowser.WinForm or one of its dependencies" exception. I have EO.Base, EO.WebBrowser, Eo.WebBrowser.WinForm and EO.WebEngine (all version 20.2.63) in the same folder. Any ideas?
eo_support
Posted: Friday, September 11, 2020 4:16:30 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 22,429
Hi,

Make sure you reference all four DLLs in your project. There is no hidden version issues between these DLLs rather than the standard .NET reference. So if you reference all DLLs, rebuild, then it should run properly.

Thanks!
GMoney
Posted: Friday, September 11, 2020 4:30:34 PM
Rank: Newbie
Groups: Member

Joined: 9/11/2020
Posts: 3
I do have all 4 DLLs referenced in my project. If I set the "Copy Local" property to True and the DLLs are next to the project executable, then everything works okay. I need to have these DLLs in their own folder. When I do that I get the FileNotFoundException error.
eo_support
Posted: Friday, September 11, 2020 5:00:15 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 22,429
Of course that won't work. :)

Exactly how .NET runtime locate and load DLL is a rather complicated process. You can find more details here:

https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies

There are numerous options/settings that can affect this process and it doesn't have anything particular to do with us at all. You can look into the options and see which option might work for you.

Thanks!
GMoney
Posted: Monday, September 14, 2020 9:09:36 AM
Rank: Newbie
Groups: Member

Joined: 9/11/2020
Posts: 3
The funny thing is this DOES work with version 16 (2016) of the DLLs. Also, isn't there supposed to be zero external dependencies? This is why we chose this product back in 2016 because it gave us the cleanest solution.
eo_support
Posted: Monday, September 14, 2020 9:28:05 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 22,429
GMoney wrote:
The funny thing is this DOES work with version 16 (2016) of the DLLs. Also, isn't there supposed to be zero external dependencies? This is why we chose this product back in 2016 because it gave us the cleanest solution.


What you claimed is not true and you are mixing up on different things. Our product is in deed zero external dependency. But that doesn't mean .NET will find our DLLs regardless where you put it. What you must understand is we are class library, not the runtime. We do NOT load ourselves. The runtime (.NET) loads the library. So if a library can not be found/loaded, you go after the runtime, not the library. This is as clear as black and white and nothing particular or funny about it.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.