Chromium Embedded Framework (http://code.google.com/p/delphichromiumembedded/) is good. I use it to display static HTML, JS and CSS generated from Delphi code only.
But I find it too big.
I need:
Don't need:
How I can achieve to have the needed features by having the minimum possible deployment package?
Currently CEF has 40 MB of dlls.
This enables developers to add web browsing functionality to their application, as well as the ability to use HTML, CSS, and JavaScript to create the application's user interface (or just portions of it). CEF runs on Linux, macOS, and Windows. It has many language bindings including C, C++, Go, Java, and Python.
Chromium Embedded Framework (CEF). A simple framework for embedding Chromium-based browsers in other applications.
CefSharp is an open source . NET wrapper around the fantastic Chromium Embedded Framework. And we provide full source code in C# and C++/CLI. You can use the code to hack, improve, fork or simply debug your applications better.
For the uninitiated, embedded browser frameworks enable developers to add basic web browsing functionality to their apps, and to use web languages like HTML, CSS, and JavaScript to create those apps' interface (or portions of it).
About reducing the CEF library size itself, it will need a full rebuilt, and some debugging phase. A lot of time spent, perhaps not worth it - 40 MB is small, according to today's computer power and network bandwidth. I would rather rely on the "official" release of CEF to stay tuned with the latest versions of the browser.
If your issue is about deployment package size and single executable/no install feature, you may consider embedd the dll
s inside the exe
.
The trick I've used is that the .dll
files are stored as zip inside the main .exe
, then uncompressed on a private temporary folder on the hard drive (you may want to use the same folder, but it won't work in C:\Program Files
due to the Vista/Seven UAC, and your user may wonder where all those files comes frome - that is the reason why I use a private folder).
From the user point of view, there is just one executable file to run. All .dll
files are compressed within, and you can also add some non-binary resources to the files (which is not possible with exe/dll compactors). An hidden folder is created and used to load the libraries (which must be loaded with LoadLibrary()
, not statically linked), and decompression will be done only once (therefore it will be faster than using an exe/dll compressor).
I've used it for instance to embedded the hunspell.dll library and the English dictionary to our SynProject tool. Code looks like the following:
constructor THunSpell.Create(DictionaryName: string='');
var Temp, HunSpell, Aff, Dic: TFileName;
i: integer;
begin
if DictionaryName='' then
DictionaryName := 'en_US';
Temp := GetSynopseCommonAppDataPath;
HunSpell := Temp+'hunspell.dll';
with TZipRead.Create(HInstance,'Zip','ZIP') do
try
Aff := DictionaryName+'.aff';
if not FileExists(Temp+Aff) then
StringToFile(Temp+Aff,UnZip(NameToIndex(Aff)));
Dic := DictionaryName+'.dic';
if not FileExists(Temp+Dic) then
StringToFile(Temp+Dic,UnZip(NameToIndex(Dic)));
if not FileExists(HunSpell) then
StringToFile(HunSpell,UnZip(NameToIndex('hunspell.dll')));
finally
Free;
end;
fHunLib := SafeLoadLibrary(HunSpell);
if fHunLib=0 then
exit;
if not LoadEntryPoints then begin
FreeLibrary(fHunLib);
fHunLib := 0;
exit;
end;
fDictionaryName := DictionaryName;
fHunHandle := Hunspell_create(pointer(Temp+Aff),pointer(Temp+Dic));
if fHunHandle=nil then
exit;
(....)
end;
See this link about details and source code.
You may consider using some low-level hack like BTMemoryModule, but you won't have any possible compression.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With