Welcome Guest Search | Active Topics | Sign In | Register

Optimize EO WebControl redistributable and make it easy for to consume Options
ruk
Posted: Thursday, July 13, 2017 3:19:13 PM
Rank: Advanced Member
Groups: Member

Joined: 5/15/2017
Posts: 48
We are consuming EO.Base, EO.WebBrowser, EO.WebBrowser.Wpf and EO.WebEngine in our code. We are facing couple of issues with how these are distributed.

1) Sub process memory utilization is misleading. We have hard time explaining this to our customers that each individual process is not taking the memory as shown in the Task Manager. We understand this is because how EO.WebEngine carries the unmanaged code as resource and at runtime unpacks and loads the unmanaged dll. Consider having an alternate redistribution where the unmanaged dll is delivered as a separate dll. This way, the OS will load the dll normally and there will not be any confusion about the sub process memory usage. Or any other approach to address this issue would be helpful. Related discussion: https://www.essentialobjects.com/forum/postst8270p2_RunDLL32-and-Memory-Footprint-of-EOWebBrowser.aspx.

2) We configured the sub process name using InitWorkerProcessExecutable() for two reasons - to leverage large address space and to name the sub process with our product naming conventions so that our customers can easily identify sub processes parented to our product. Our product is installed under Program Files folder which will not have write access to standard users at runtime. We are redistributing the subprocess exe with our install. The problem is that whenever we are upgrading to latest EO build, we need to run our application once to generate the named sub process exe and then add to that to the install. It would be lot easier if this exe is redistributed with your redistributable and we rename the exe to match what is passed to InitWorkerProcessExecutable().

Also, above two improvement will reduce the size of the Eo.WebEngine.dll, though we understand the overall size of all EO redistributables remain around same.
eo_support
Posted: Thursday, July 13, 2017 4:19:09 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

Thank you very much for your feedback.

As to the DLL issue, we chose to load it from memory primarily for easy of deployment. Because we pack the native code inside managed DLL, it has the following advantages:

1. It completely eliminated missing file/version mismatch issues between the native DLLs;
2. It also significantly reduced the number of DLLs that you need to redistribute;
3. It eliminated the possibility that the application may load a DLL indirectly from another path folder;

We think those benefits far out weight the memory footprint confusion that may caused among the end users.

As to the sub process name, we do redistribute the file (eowp.exe). So you can copy that and rename it to anything you prefer in your distribution.

Thanks!


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.