The company I work for developed an application that uses WebView2 to display a Edge browser within the app. The IDE we use (Delphi) provides a dll called "WebView2Loader.dll" to distribute along side the exe.
When looking at how the WebView2 runtime operates, there are a lot of mentions of something called "Evergreen" which seems to be the WebView2 runtime that auto updates itself to the latest and greatest.
https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#understand-the-webview2-runtime-and-installer-preview
This is where the confusion came in. My question is how does this Evergreen relate to the WebView2Loader.dll? The way I think it works is that the loader dll is only there to find the installed WebView2 runtime and the Evergreen is actually doing the downloading of the runtime. I get this indication from this quote "WebView2Loader.dll is a small component that helps apps locate the WebView2 Runtime, or non-stable channels of Microsoft Edge, on the device." from this link https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/static.
And then my follow up question would be, would customers have to download Evergreen manually or would that runtime exist if they have edge installed already?
WebView2Loader.dll is a dynamic library wraps around WebView2 Runtime and allows Delphi applications to make use of its functionality.
WebView2 Runtime is a standalone runtime package that allows applications to use WebView2 environment without Microsoft Edge being installed on the target computer.
WebView2 Runtime can be distributed in two modes.
Evergreen mode installs the WebView2 package as a system component similar to C++ Runtime packages. It is installed once and can then be used from any application. It is also capable of updating itself.
In Fixed version mode you distribute the needed binaries with your application. Such binaries are generally available just to your application. And if multiple applications are installed each ship with their own binaries so it uses more disk space.
Related
The road map seems rather intransparent to me. Is this planned? Is there any info on a potential release date? We require to use WebView2 on machines that aren't necessarily connected to the internet. The full browser would not be needed, which is why the idea of WebView2 Runtime seems like the way to go. As of right now however the installer needs to connect to the internet.
I work on the WebView2 project. The installer you linked to is actually the standalone evergreen installer that can be used entirely offline :). If the device is online, the installed runtime will try to update itself, but offline it works fine too just not getting any updates. If you run a later version of the installer when a older version is already installed, the installer will update the version of WebView2 Runtime on the device (this is basically how you can update the evergreen runtime offline). Right now the Runtime and installer are under preview and we strongly advise against redistributing it outside your org/company. We are targeting Q4 this year for GA.
Fixed version is not out for preview yet. You can find our roadmap with dates on https://learn.microsoft.com/en-us/microsoft-edge/webview2/roadmap.
I've noticed that there is a possibility in Xamarin to connect Visual Studio to an iOS build host.
What is this build host, is there any documentation about its architecture? What code does Xamarin.iOS send to this build host?
[Edit]
I want, as a personal project, make an iOS build host in Windows. I know that this can be achieved, and I'm sure that technically, I have all the needed tools to re-create one. My concerns is about the architecture of an original iOS build host. I want to know what is the communication between Xamarin and a iOS build host, and what is the build flow. And this is not documented.
A great explanation from here.
Xamarin.iOS compiles c# source code against a special subset of the
mono framework. This cut down version of the mono framework includes
additional libraries which allow access to iOS platform specific
features. The Xamarin.iOS compiler, smsc, takes source code and
compiles it into an intermediate language, ECMA CIL (common
intermediate language), however it does not produce ECMA ABI
compatible binaries unlike the normal mono compiler, gmcs or dmsc.
This means any 3rd party .Net libraries you want to include in your
application will need to be recompiled against the Xamarin.iOS subset
of the mono framework using smsc.
Once a Xamarin.iOS application has been compiled into CIL it needs to
be compiled again into native machine code that can run on an iOS
device. This process is carried out by the SDK tool ‘mtouch’, the
result of which is an application bundle that can be deployed to
either the iOS simulator or an actual iOS device, such as an iPhone or
iPad.
Due to restrictions placed by Apple, the iOS kernel will not allow
programs to generate code at runtime. This restriction has severe
implications for software systems that run inside a virtual machine
using just-in-time compilation. Just-in-time compilation takes the
intermediate code, for example mono CIL and compiles it at runtime
into machine code. This machine code is compatible for the device it
is running on at the time of execution.
To work around this restriction the mtouch tool compiles the CIL ahead
of time. A process that the mono team describe as AOT, ahead of time
compilation.
Some quotes from Xamarin docs:
Xamarin iOS for Visual Studio accomplishes an amazing feat: it lets
you create, build and debug iOS applications on a Windows computer
using the Visual Studio IDE. It cannot do this alone, however - iOS
applications cannot be created without Apple’s compiler, and they
cannot be deployed without Apple’s certificates and code-signing
tools. This means that your Xamarin iOS for Visual Studio installation
requires a connection to a networked Mac OS-X computer to perform
these tasks for you. Once configured, Xamarin’s tools will make the
process as seamless as possible.
Starting with Xamarin.iOS 4.0, there are two code generation backends
to Xamarin.iOS. The regular Mono code generation engine and one based
on the LLVM Optimizing Compiler. Each engine has its pros and cons.
Typically, during the development process, you will likely use the
Mono code generation engine as it will let you iterate quickly. For
release builds and AppStore deployment, you will want to switch to the
LLVM code generation engine.
Conclusion
So there is no way to make an iOS build host in Windows, as you said.
I guess Xamarin send to the build host the .Net assembly file (Orange part of the picture), to be compile into native ARM code using Apple llvm, and others tools like xcode-build to signed, link and build your application.
I want to use a language that does not need any runtime library like .NET. Do Delphi 2009 or Delphi 2010 executables require any runtime library to start?
If you build without using runtime packages then the executable will have the runtime library built in to it. You can therefore distribute a single executable module that will run on a plain vanilla Windows system.
For what it is worth, .net is supplied as a Windows component and you can rely on its presence, albeit sometimes a rather lower version than you would like.
I am embarking on a cross platform app, but not mobile. It will be win/osx/linux. Would love to use Delphi + firemonkey, but it appears linux is not a possible target?
The GUI will not be extensive. Most of the code is non visual.
What are my options here? (Do I end up using lazerous for the linux side.... and then I have to have a special UI there?)
Please let me know my options here, how to solve this cross platform dev project (and hopefully avoid c++).
Linux is not currently one of the supported operating systems, as can clearly be seen from the product description on the Embarcadero web site. If you need Linux/Unix support, XE4 and FireMonkey aren't an option. (XE4 supports Win32, Win64, OSX, and iOS.)
There's support for Linux planned at some point in the future (after Android, which is currently being developed and slated for release later this year).
Just read some posts about how wonderful Silverlight 3.0 is, including that it uses some variant of WPF. That set off a warning flag.
If I'm installing Silverlight on the client and I've got, say Win XP SP2 (which is the minimum supported), how large would the runtime download be, including all dependencies?
(In the past I've had a MS .net product manager tell me a .net 2.0 app was just an xcopy. He forgot to mention that this was assuming that you'd already installed the 22 MB runtime).
The total download size 4.69MB for Windows, 8.7MB for Mac. No other dependencies. I believe they may expand once they're downloaded.
Note that the developer runtimes are (of course) larger.