I was to small-brained the first time I saw this to understand it's implications but revisiting again the consequences seem incredible. It's effectively an arbitrary scripting runtime for dotnet, solving a longstanding "issue" where you couldn't easily eval arbitrary C# at runtime without that code having access to the full context of the host application. Being able to leverage this for things like game scripting are huge, and as others pointed out here the ability to tie this into a better hot reloading experience would be incredible.
This is awesome. The first usecase that comes to mind is giving website users the ability to provide their own scripts to transform data, for example to define the shape of an event webhook to suit their own API endpoints.
Yeah, this scenario is something I'd like to implement in my own application as well. It will open up a wide range of customization capabilities to my users. I am looking forward to experimenting with this!
Agreed - if you see Steve's previous demo where he runs SQLite in a WASM instance to pull data from a source and then mash through 100K+ rows of data (because it's effectively cached in the WASM sandbox) it's really mind-bending. I look at this demo and think "so *that's* how he did it..." ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-RevmsFXVJ5Q.html
I have been very interested in sandboxing for C#, and seeing recent dotnet versions not having any options was a bit of a let down. This is very promising and I am definitely gonna play around with it.
This looks like a lot of fun to experiment with for a plugin system! I do wonder how it works technically so I guess it’s time for some code spelunking :D
Steve Sanderson continues to drop huge.... CASUAL... Industry TRANSFORMATIVE Genius++ Level of God's grace... 🕴️James Bond swag... 😎😍🫠😍😮💨💪. Dude you are a GOD Bro!!💪
Nice Steve. I can almost imagine Blazor Web assembly in a mode where it starts instantly as an isolated WASM process running on the server (so not starting as server side blazor), then is instantly transitioned to the browser once the assemblies are loaded (I assume you could serialize the whole WASM dotnet state for that user). Might not be practical of course given the various web APIs wouldn't be available until after the transition to the browser.
I wonder if something like this could improve the usefulness of Hot Reload; Being able to fully recompile a controller or service and then it seamlessly being transferred to a subprocess
Very neat! I'd def like to hear more on the scope and limitations of passing data to and from the isolated runtime. On the api project, u did show how u could isolate the counter variable on a per request level, but its unclear if the counter variable is being serialized into the isolation env (i.e. what happens with bigger objects with various levels of nestings). And also the example on passing the results of directory.GetFiles, what happens if I pass back a FileInfo object and in the main env calls a method on the returned object? I would assume there would be errors since those paths don't exist in the main env. And also, what about network isolation control? Either way, awesome stuff that adds tons of flexibility and potential security to the platform. Well done! 👏
Is it generating wasm on the fly? Is it possible to do AOT or cache generated WASM? And is the WASM code JIT-ed or it's using WebAssembly version of Mono as an CIL interpreter ?
Very interesting! Is it possible to pass down an interface/object to the sandboxed code or have the sandboxed code able to interact with that objects functions on the outside? I may not be explaining this well, but being able to sandbox a customers code while still allowing it to pull data as part of the sandboxed code in a controlled way could be useful.
Great to hear from Steve as always, he is full of cool ideas. Anyone know which library he used for the spreadsheet component? It's not part of the github project he shared.
I wonder if this can be used as a basis for a plugin system that allows third party devs to create their own plugin and run isolated from everyone else. Or a way to distribute plugins in a distributed system.
5:15 You mentioned that the runtime can't log to console without the WithInheritedStandardOutput but you just demoed that at 3:55 without this being enabled. Its that already setup as default?
Does anybody know how it works internally? Does it create a separate process for each runtime or are those created runtimes are managed inside the current process? Thanks!
Very cool but viewers should know this is really well traveled territory outside of dotnet, and MS probably will not grow this to be as feature rich as the Linux tooling (seccomp, chroot, etc), rust and crypto use this tech a lot
