[rafaelvasco]

At some point I wrote a barebones scripting system using roslyn for a project of mine. At runtime I got a piece of code compiled to a DLL in memory and then executed this DLL; Worked well; But at that time there was no support for destroying AppDomains or something, don't remember the exact name. Still pretty fun; But yeah, there's no real complete documentation anywhere; And the DLL hell was real. Dozens of DLL's just to support this; But now with .NET Core 3+ things must have improved a lot;

[thrower123]

Roslyn is very powerful, but it is still pretty cumbersome. At one point I spent quite a while trying to get a game scripting system akin to the way that Lua is commonly used working, and I just couldn't get it working fast enough to be viable. I essentially wanted to have a core C# engine that provided services, and then have it call an initialization function and a gameloop function that were defined in designated script files, and then all of my game code would also be written in other scripts; this way I could run things, edit the code on the fly, and hot-reload.

It's entirely possible that I just don't know what I'm doing well enough to do this correctly, but I just couldn't get it to do the kinds of things that I wanted from it. My sense is that it is really great for injecting custom code that is used rather infrequently. I've had good results using it for building out reporting systems that are pluggable.

[fultonfaknem42]

I think ignorance is a pretty powerful argument to be made by any developer wanting to use Roslyn. The last few times I messed with it there was literally no documentation and everything I knew/know comes from reading headers, trial and error, and experimentation.

I feel defensive about calling it cumbersome though, and I can't imagine why something like your LUA vision isn't possible (though, I've never tried I just assumed someone would inevitably do this). For example, if World of Warcraft were to switch out their UI LUA extension system with C# I could totally imagine this being possible (though it'd be suicidal for their mod community). Likewise, if Unity were to begin using it for this kind of thing (if they don't already) I'd imagine it is possible.

[jmarolf]

We have some documentation now: https://docs.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/

would really appreciate bugs/comments on these docs pages of what else you would like to see.

[rafaelvasco]

Well, it's not cumbersome at all. The problem is really lack of real documentation and most importantly real world examples; About the performance, if you use the real scripting support for Roslyn , yeah, I think you'll have bad performance. But if you compile the code to memory at runtime and execute it like I did, it's pretty fast;

[eropple]

FWIW, I wrote effectively what you describe pre-Roslyn, using the old CSharpCompiler, and it was plenty fast enough for my own developer tolerances. I ended up going to a compile-on-startup mode instead, though.

[moron4hire]

DLL Hell doesn't refer to "lots of DLLs", it refers to conflicting versions of DLLs not being easily manageable across multiple applications. Outside of putting assemblies in the GAC (which was always a hack of last resort anyway), .NET has never had "DLL Hell".

[WorldMaker]

Yeah, the closest .NET equivalent is Binding Redirection hell, and NuGet and Visual Studio and .NET Core have spent years of work making that better than it was at its worst in the early NuGet days. There's a couple of low level APIs that are still annoying problems to redirect if you need to support particular sets of .NET Framework and .NET Core, but beyond that a lot of it is managed for developers automatically these days.

[moron4hire]

Yeah, the VS interface for managing it is not great, but the new project file format is a lot easier to understand and manage, so I've had good luck just making manual changes.

[qes]

> .NET has never had "DLL Hell"

I take it you've never worked on a .Net solution with projects targeting both full framework and Core framework.

Core v1.x stuff was a nightmare - haven't had so many issues with versioning in 20 years. Core v2.0 was still pretty bad but each v2 point release made decent strides - and specific packages would get updated out of band at times to fix issues.

But to say .Net has never had DLL Hell is just wrong. Even pre-Core you could run into difficult situations with conflicting downstream dependencies of directly used packages.

[moron4hire]

DLL Hell had nothing to do with project development. It was a problem of application deployment and running applications with DLLs in shared locations.

https://en.wikipedia.org/wiki/DLL_Hell

  The problem arises when the version of the DLL on the computer is different than the version that was used when the program was being created. 

Other than the GAC, which was never recommended for use anyway, .NET has never had DLL Hell

[pjmlp]

GAC was surely the recommended way until .NET 4.0, when the location changed.

[moron4hire]

No, the recommended way was to install your application with all dependency DLLs in the application install location.

And I've misspoken about GAC causing DLL Hell for .NET. It fixed DLL Hell, but introduced a new Strong Naming Hell.

[pjmlp]

Initially that recommendation only applied to native code DLLs, not managed ones, as far as I can remember.

[rafaelvasco]

Yeah, lots of assemblies is kinda like .NET dll hell ;) .NET Core had this problem in earlier versions. Not anymore;

[fultonfaknem42]

Maybe Assembly unloading, in which case if you wanted to swap out new dlls in memory you'd have to tear down the process and restart it. Definitely not sexy. That being said: I think Assembly Unloading is a thing now (and AppDomains don't exist in .NET Core last I heard).

[teh_klev]

In .NET standard (i.e. not .NET Core) you can load and unload assemblies without tearing down whole processes by creating AppDomains within a process. You then load your desired assemblies into these app domain(s), consume and when you need to load say a newer DLL version you just tear down the AppDomain and create a new one for the new DLL's.

It's a feature that's been around since .NET 1.1 and I used to use heavily 10+ years ago.

https://docs.microsoft.com/en-us/dotnet/api/system.appdomain...

[rafaelvasco]

Yeah, if I remember correctly it's indeed a thing in latest versions of .NET Core;

[fultonfaknem42]

This looks like a pretty cool demonstration of what we're talking about: https://www.strathweb.com/2019/01/collectible-assemblies-in-...

See the section titled: Collecting a dynamically emitted assembly

[rafaelvasco]

Yeah that's exactly it. Thanks!