WindowsAppSDK
WindowsAppSDK copied to clipboard
microsoft
UWP load code that was generated at runtime to enable use of Roslyn scripting APIs
Proposal: UWP load code that was generated at runtime
Summary
Roslyn provides powerful scripting APIs, but none of it is usable in a UWP application according to this: https://github.com/dotnet/roslyn/wiki/Scripting-API-Samples#supported-platforms. I propose adding a capability for UWP apps to load code generated at runtime in order for Roslyn APIs to be usable.
Rationale
- This feature would enable the creation of powerful uwp-based developer tools that take advantage of Roslyn
Scope
| Capability | Priority |
|---|---|
| This proposal will allow developers to use the Roslyn scripting APIs in a UWP app | Must |
Important Notes
One usage scenario is in Nightingale REST client. Nightingale customers are asking for the ability to create small c# expressions that are executed automatically after an HTTP response is received. These expressions evaluate the response to determine if the request passes a particularly test. Roslyn would enable tis scenario.
Other usage scenarios could be similar to LinqPad.
Open Questions
Is this feature out of UWP's scope?
Many UWPs are JITted using JavaScript and the CLR. Loading generated DLLs is harder due to signature and runtime validation checks that keep UWPs safe(r).
For instance, a JITter could allocate a page with VirtualAllocFromApp, fill it with generated code, use VirtualProtectFromApp to flip it to executable/read-only, and jump to it. Note that the JITter would have to handle all linking, loading, call-outs, etc. This is non-trivial.
Note that using this requires the codeGeneration capability.
It's probably out of scope for Project Reunion to write a little linker/loader/JITter, however. (Note that there's very little difference between LoadLibrary and VirtualAlloc+ReadFile+VirtualProtect, at least in theory...)
Note that you don't even need the FromApp APIs or the capability anymore; any plain vanilla JIT should work just fine for UWP on any version of Windows 10. It is only persisted binaries that will fail due to signature checks. I will try to follow up with the Roslyn folks.
I've recently tried and while VirtualProtect does work and is exposed in the headers, the codeGeneration capability was still needed to use any executable page protection.
Was VirtualProtect aliased to the FromApp version? Because you shouldn't need the capability if you use the older API.
Original Poster has not responded to the last question, closing issue. Please comment to re-open
