I recently learned that AppDomain is not fully supported in .NET Core, and they have no plans so far of implementing full support.
What I am trying to do is to make a program that can run a plugin, but I don't want that plugin to be able to access certain assemblies or namespaces (for instance System.IO).
The way I used to solve this problem prior to .NET Core will no longer work due to the lack of support.
Is there any other way I can achieve the same in .NET Core?
More concrete example
Let's say I load an assembly using Assembly.LoadFrom from the file system, which contains a plugin method that I then invoke. But I don't want plugins to be able to erase files, etc. In fact, I only want the plugin to be able to call functions from a specific assembly.
Basically they want you to use the platform boundaries for the environment you are developing for.
Sandboxing
Why was it discontinued?
Sandboxing, i.e. relying on the runtime or the framework to constrain which resources a managed application can access, is considered a non-goal for .NET Core. Sandboxing applications and components is also really hard to get right, which is why generally recommend customers not to rely on it. It also makes the implementation more complicated and often negatively affects performance of applications that don’t use sandboxing. Hence, we do not offer sandboxing features in .NET Core.
What should I use instead?
Use operating system provided security boundaries, such as user accounts for running processes with the least set of privileges.
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/
Related
I am trying to follow this tutorial:
https://codingvision.net/security/c-inject-a-dll-into-a-process-w-createremotethread
but kernel32.dll and its functions can only be used on windows.
What can I use instead to inject dlls on mac?
If you are injecting kernel32 then it means that you are actually injecting a native library designed for Windows. There is no 1-to-1 alternative apart from possibly ones within libraries like WINE, but avoid such hacks.
Instead consider finding an alternative in the API of the actual system. You should find the respective method in the API of the system which you are currently running and conditionally execute different calls.
Yet be sure to know that the best approach would bo to AVOID using direct system calls and operate only within .NET, especially that if you find a way to execute required things only using .NET libraries then there is a high chance of migration to .NET Core which is designed to work on all three major systems without a problem (especially for web and console applications).
So to sum up:
there is no kernel32.dll for MacOS
you need to find a respective function in the API of MacOS which will do the same as the method which you have called from Kernel32
the best thing is to avoid usage of Kernel32 and try to find a respective call within .NET libraries
Once upon a time you could simply use the Mach call task_for_pid() but that stopped working years ago when Apple first started paying attention to security. Then for a few years you could still force the dynamic linker to load a .dylib into an executable when it launched by setting some environment variables, but then Apple put a stop to that too, as they continued to crack down on security holes.
For the most part you can't do this anymore, or at least not easily. Especially with things like System Integrity Protection enabled. (I mean you could still create a kernel extension and do it there, except Apple now requires that all kernel extensions be signed with a special entitlement and they're pretty much not giving out that entitlement anymore.)
Specifically, what I need to identify is the calling development platform (i.e. .NET Core vs. .NET Framework vs. Other) rather than the operating system information I can get through System.Environment.OperatingSystem.Platform. Is there a way to do this?
(To give more detail on my specific use case, I am referencing a library - log4net - which is configured by passing it an XML resource. Some of its configurable features which I want to use if available are supported under .NET Framework but not under .NET Core, and I want to be able therefore to pass it a different version of the resource depending on which I'm being used by.)
Solving from the runtime environment could prove to be uncertain as runtime change. I would force the issue up front before the application runs. As previously stated you could pass in the runtime or configure it.
Another option would be something similar to SL4J provides. Runtime determination dependent upon how you deploy the application.
You could create your own interface for exposing platform information. Then, at deploy time, just add the appropriate assembly to the installation. Load the assembly and call the methods you require.
Alternatively you see how Microsoft handled similar situations here: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
I had to do this once. There was a method I needed to call that varied across implementations. I just used reflection to try one name after another.
Trying to detect the runtime library is silly. Detect the differences directly. It's less likely to break.
Currently I'm working on a .NET hobby project that involves a complex system of objects which work in combination with eachother. However, I encountered a little problem, I am unable to find a mechanism in .NET to support replacing code at runtime, and be able to dispose of the old code, loaded previously. This means replacing a module/object dynamically and almost instantly displaying the changes to the user, for example, when he restarts a procedure, but not the whole program.
I have already taken into account the possibility of having separate AppDomain for each session and loading the necessary assemblies into it but this seems a little bit too expensive. I should also mention that every session benefits from a common base of assemblies, for instance, to connect to a database, so this means loading those classes into every single session. Marshalling data back and forth from the separate AppDomain also represents an additional overhead (could be used when data is sent to the client application through the network, code for this contained in the main AppDomain, which manages the sessions).
Is there a framework or way of replacing/unloading particular parts of code? How is it done in real-world applications? Can there be a workaround? Or have I picked the wrong set of tools?
You need some kind of plugin system with well defined interfaces. Then you load at runtime binaries (your plugin *.dll) and create objects from it and then execute methods on it.
When you create a system where objects from your plugins must be created through your IPluginManager you have no problem with replacing code at runtime. :)
Or
You have something like a folder with *.cs files which will on demand compiled (in memory) and create the objects you want to use from them and call the methods on them.
Which is basically the same like above, without compiling at run time.
From there you can make further improvements.
EDIT:
Like you wrote the only problem without using AppDomain is that once loaded assemblies can't be unloaded. But that's not really a problem.
I don't think you need separate AppDomains: you can dynamically load assemblies within the current AppDomain. And each assembly should probably implement some defined interfaces (depending on your usage). You could use the FileSystemWatcher class, for example, to load/unload assemblies as needed.
See http://msdn.microsoft.com/en-us/library/25y1ya39(v=vs.110).aspx
You can have a look at MEF. It stands for: Managed Extensibility Framework .
Here's another article about it MEF on codeproject.
It is used to load dll's in runtime by composing them. This is what is usually used for plugins or anything else you kinda drop into a folder and expect it to run .
Here's a link to some more tutorials as well: Where can I learn about MEF?
Yes, you're right, it is not possible to simply unload an assembly (only AppDomains). But I think one of the features of ASP.Net vNext is the ability to have just in-memory assemblies and when you simply alter the source code on the drive it gets automatically compiled and loaded. Therefor a mechanism must exist to unload the previous version.
I think they are doing that by simply creating a AppDomain where all assemblies are loaded into again to avoid any cross domain communication. But i don't really know and maybe if you would dig more into the mechanism on how they do this stuff in ASP.NET you maybe find a good solution. More informations about the hot topics from vNext you can maybe also find at Scotts Blog.
Well, I've found 2 solutions that work for me, which I would like to share. The first one is to use CollectibleAssembly and define the types. This is certainly a bit tricky, and a number of restrictions are imposed on this type of dynamic assembies.
The other option is to use a scripting language like IronPython or IronRuby. Also a great feature of the new Roslyn compiler is that it also provides scripting APIs, not previously available in the .NET framework. What's more, the Roslyn scripting languages tend to look very much like their full-blown equivalents (C# or VB). And I've also found a tiny example of its capabilites.
I have an application that I have designed and this app has a pretty decent core dll that contains an API that my main view's exe uses. I would like to allow other developers to access this core dll as well but I don't want them to have as much access as me since it would be a security risk. What is the standard way of exposing my core dll? Are there any particular design patterns I should be looking at?
I'm using C#
Edit: my question was a little vague so here is some clarification
My program is deployed as a windows exe which references the core.dll. I want other people to create extensions which dynamically get loaded into my program at start up by loading dlls in the /extensions directory. The 3rd party dlls will inherit/implement certain classes/interfaces in my core.dll. I only want to give 3rd parties limited access to my core but I want to give my exe additional access to the core.
I should mention that this is the first time I have written a program that imports DLLs. Perhaps this whole method of allowing users to add extensions is wrong.
How do I modify/expose my API for
other developers?
To deliberately allow other developers to work with an API you've built touches on many things, which can be broken into two areas:
Resources (documentation, samples, etc) that makes it easier for them to understand (yes - basically an SDK).
Architecting, constructing and deploying your solution so that it's easy to actually work with.
Examples include:
By packing it in a way that suits re-use.
By using naming conventions and member names that others can easily follow.
Documentation, samples.
Providing the source code (as open source) if you're happy for them to modify it.
I would like to allow other developers
to access this core dll as well but I
don't want them to have as much access
as me since it would be a security
risk.
Ok, so this gets us right into the second area - the actual solution.
The problem you have is not a trivial one - but it's also quite do-able; I'd suggest:
Looking into existing material on plugins (https://stackoverflow.com/questions/tagged/plugins+.net)
Personally, I've found using attributes and Dependency Inversion to be a great approach.
There's also stuff like the Managed Extensibility Framework which you should consider.
The big issue you face is that you're into serious architecture territory - the decisions you make now will have a profound impact on all aspects of the solution over time. So you might not be able to make an informed decision quickly. Still - you have to start somewhere :)
The "design patterns" in terms of an API are more related to things like REST.
I don't want them to have as much
access as me since it would be a
security risk
Then i would (for the sake of maintenance), layer on top of the core DLL extra logic to prevent this.
The thing is, the "clients" call the API, not the Core DLL.
"How" the API accesses the Core DLL is under your full control. Just only expose operation contracts that you wish.
Since you're using C#, I would look at Microsoft's Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries and use FxCop to in-force many of them (latest version here). This won't be all you'll likely need, but it would help put you in the right direction.
Also, take a look at the freely available distillation of Framework Design Guidelines by the same author.
I've inherited an enormous .NET solution of about 200 projects. There are now some developers who wish to start adding their own components into our application, which will require that we begin exposing functionality via an API.
The major problem with that, of course, is that the solution we've got on our hands contains such a spider web of dependencies that we have to be careful to avoid sabotaging the API every time there's a minor change somewhere in the app. We'd also like to be able to incrementally expose new functionality without destroying any previous third party apps.
I have a way to solve this problem, but i'm not sure it's the ideal way - i was looking for other ideas.
My plan would be to essentially have three dlls.
APIServer_1_0.dll - this would be the dll with all of the dependencies.
APIClient_1_0.dll - this would be the dll our developers would actual refer to. No references to any of the mess in our solution.
APISupport_1_0.dll - this would contain the interfaces which would allow the client piece to dynamically load the "server" component and perform whatever functions are required. Both of the above dlls would depend upon this. It would be the only dll that the "client" piece refers to.
I initially arrived at this design, because the way in which we do inter process communication between windows services is sort of similar (except that the client talks to the server via named pipes, rather than dynamically loading dlls).
While i'm fairly certain i can make this work, i'm curious to know if there are better ways to accomplish the same task.
You may wish to take a look at Microsoft Managed Add-in Framework [MAF] and Managed Extensibiility Framework [MEF] (links courtesy of Kent Boogaart). As Kent states, the former is concerned with isolation of components, and the latter is primarily concerned with extensibility.
In the end, even if you do not leverage either, some of the concepts regarding API versioning are very useful - ie versioning interfaces, and then providing inter-version support through adapters.
Perhaps a little overkill, but definitely worth a look!
Hope this helps! :)
Why not just use the Assembly versioning built into .NET?
When you add a reference to an assembly, just be sure to check the 'Require specific version' checkbox on the reference. That way you know exactly which version of the Assembly you are using at any given time.