Bundles can be loaded from anywhere, but "built-in" we offer loading from:
Metro (typically only in debug)
An asset in an appx (via ms-appx://, default for UWP)
A string resource in an assembly (via resource://mylib.dll/)
A file on disk (via file://, default for Win32)
While obviously apps are on their own for code-push scenarios (our template won't hook you up with any of that), we really should make it both clearer what the default is in our template, but also easier for app developers to switch to meet their needs
Motivation
After getting the #12569 alerts for dynamically loading libraries for their resources, I wanted to see where (if anywhere) we were actually using this in our templates or examples. I think we should be lot clearer about the options and their trade-offs.
Basic Example
I can imagine scenarios where developers want to store their JS bundle in their dll, mildly obfuscating some of their code or reducing the number of files they ship.
I can also imagine scenarios where developers don't want their JS bundle in their dll because that means you have to re-build and re-deploy the native code to get JS updates.
I can imagine scenarios where you want the benefits of both at different times for different reasons.
Summary
Bundles can be loaded from anywhere, but "built-in" we offer loading from:
ms-appx://
, default for UWP)resource://mylib.dll/
)file://
, default for Win32)While obviously apps are on their own for code-push scenarios (our template won't hook you up with any of that), we really should make it both clearer what the default is in our template, but also easier for app developers to switch to meet their needs
Motivation
After getting the #12569 alerts for dynamically loading libraries for their resources, I wanted to see where (if anywhere) we were actually using this in our templates or examples. I think we should be lot clearer about the options and their trade-offs.
Basic Example
I can imagine scenarios where developers want to store their JS bundle in their dll, mildly obfuscating some of their code or reducing the number of files they ship.
I can also imagine scenarios where developers don't want their JS bundle in their dll because that means you have to re-build and re-deploy the native code to get JS updates.
I can imagine scenarios where you want the benefits of both at different times for different reasons.
Open Questions
No response