|
|
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?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
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!
|
|
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.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
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-assembliesThere 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!
|
|
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.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
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.
|
|