-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Load library from embedded resource #5
Comments
Hmm, I'm not familiar with how you'd accomplish this. From a cursory search, it doesn't look like there's just a "LoadFromMemory" function -- probably with good reason. Obviously, you could split out the embedded data into a file and then load that, but I'm guessing that's not what you mean. Is there actually functionality in most OS's that make this possible, portably? |
I know that there is a file in Eto.Forms that can accomplish this in some way, but it returns an Assembly instance rather than an IntPtr. |
Here's a link to the file: EmbeddedAssemblyLoader.cs |
@tom-corwin That linked code loads a managed assembly that is embedded as a resource. Doing that is pretty straightforward, because there's an explicit API for it ( |
@mellinoe It's still an idea. You might be able to use |
Yes, you have to load it from the file system. What I have done in the past was ready the byte[] from an embedded resource, save it to a temp location under as (for example) MyAssemblyName.v1.0.0.2.[UniqueGuid].NativeLibraryName.dll I wanted it unique so that it would not clash with other instances of the same app. Then use the standard LoadLibrary/DelegatePointer/FreeLibrary methods using that file. And in the dispose for the app, I would (after I unloaded the library), delete the file to clean up. Sometimes if the app crashed it would get left behind, and I would usually solve that by using a TEMP directory that usually gets emptied at some point anyway. Or even using a RAM drive that got destroyed every time I rebooted. There are countless ways to handle the saving and cleanup (perhaps your own app cleans it up the next tie it starts .. who knows). But, it allows for the native library to just be distributed with the managed library. Wont work for EVERY case (perhaps the library needs to be kernel specific for linux), but its going to work for 98% of apps. I have even done it for .EXE's that I needed to shell out to (ffdshow on windows). And I know Microsoft does it for some things as well. |
If it's alright with @mellinoe, I'd be happy to try to implement this feature. This would definitely come in handy for various uses. |
Not trying to shut down the discussion or anything, but I think it would be best to implement this outside of the library. You can already load a library from an arbitrary path, so all that you would need to do to accomplish this is:
The implementation is not all that interesting (it's just copying bytes around), but it involves making a policy decision about where to put the file, what to name it, how long that file is retained, etc. which I'd rather not be in the business of. If there were some OS-level API that actually let you load a dynamic library from raw bytes, then perhaps it would make more sense to include in this library directly. |
That's a fair point, thank you for clarifying the scope of the project. 🙂 |
@RoySalisbury This PR add an Note that the origional NativeLibraryLoader code is slimmed down, but the logic and member names are the same. |
I've done this in the past so I know its possible (on windows anyway). It would be nice to be able to load the library from an embedded resource so all libraries can be distributed with a single assembly.
Something along the lines of exporting the library to a specific app/version name into a temporary location, and then load the library from there. As part of the app domain unloading you can remove the library (or leave it).
The text was updated successfully, but these errors were encountered: