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.