I suggest you ...

Dynamic code generation, plugin loading in Metro/WinRT applications

It is my understanding, and forgive me if this assumption is incorrect, that code inside a metro application intended to be eventually submitted to the windows store is not capable of any form of dynamic code execution or generation. This means it is not possible, for example, to implement a dynamic language interpreter that generates native code dynamically and executes it (e.g. a JIT engine).

It also means that any applications that depend on a plugin model for fast and immediate delivery of time-critical updates are also excluded (tax software, for example, often needs to update plugin components on an extremely tight schedule as state legislatures often release updated specs mere days before a major tax deadline). There are also numerous other scenarios where dynamic code generation and execution is required for optimal code execution. For example - a dynamic language interpreter that uses a JIT engine to optimize the execution of dynamic scripting code.

The only dynamic code generation facility that I am aware of that is available for metro style apps is Expression<T>.Compile for C#/VB applications and eval for javascript. Neither of which are a sufficient solution to all requirements.

I understand that dynamic code execution (and to clarify, by this I mean two things: Dynamic code generation and execution, e.g. JIT engines, and dynamic code loading and execution, e.g. plugins downloaded from an external source) represents a security risk in an environment where apps are vetted by Microsoft for inclusion in the Windows Store.

However for one thing, the security risk is there even without these capabilities - for example a script interpreter could have a sophisticated enough implementation to expose the entire WinRT runtime to scripts downloaded and interpreted from the internet, without the ability to generate assembly code. In fact, we already have one: IE10's javascript engine for metro apps.

Also, I believe the scenarios that require this capability are valid (even for metro apps). I'm aware that these capabilities are still available in the desktop environment, but I don't believe this is good enough. The scenarios described are valid for metro applications as well as desktop applications.

Therefor, I recommend the following compromise:

Add dynamic code execution and DLL loading capabilities to the base WinRT platform as a brokered API (LoadLibrary, GetProcAddress, VirtualProtect, some new WinRT api, etc...), as well as the associated managed libraries (Assembly.Load, Reflection.Emit) and special support for these libraries to load and execute code from isolated storage or from memory as necessary. Of course any assembly code or CIL that is executed would run under the same app restrictions as the original app and must target the WinRT api (or one of the Win32 apis that are available to metro apps, i.e. DirectX).

Second, add a new permission that must be granted in order for an app to make use of these libraries. A warning dialog, similar to existing dialogs for things like permission to access location, should be presented the first time the application runs, with an appropriate warning stating something along the lines of "This application may download and run additional components that may not have been tested by Microsoft."

96 votes
Vote
Sign in
(thinking…)
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
SleepyDaddySoftware shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for taking the time to share this suggestion. This item has been around for a couple of versions of Visual Studio and we haven’t acted on it. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to close it. If the suggestion is still relevant, please either take a look to see if there’s another suggestion that’s similar that you can vote on, or open a new suggestion.

- The Visual Studio Team

1 comment

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Shawn Snyder commented  ·   ·  Flag as inappropriate

    .NET Native is just a bad idea - we lose all the benefits of a JITed language, and don't get the full control of native, for the purpose of making startup times faster? It's a mashup that makes it the worst of both native and managed worlds.

    I add my support for UWP JIT version because I know Microsoft can do better than hamstringing their developer's innovation.

Feedback and Knowledge Base