0

A way to unpack embedded resource has been already discussed on StackOverflow. Provided solution unfortunately doesn't work for libraries that might get executed from multiple processes simultaneously, which could result in corruption of the unpacked resource or some spurious exceptions.

I am looking for a method to unpack embedded resource in a safe way, by which I mean:

  1. No unnecessary copies of the file are created. If it's the same file, it should be in the same location.

  2. Multiple versions of the file can coexist in the filesystem.

  3. Once unpacked, the file will live at least as long as the process that unpacked it and all attempts to read the file will succeed.

  4. It doesn't matter how many processes execute the unpacking process concurrently. The result is always the same.

  5. If unpacking gets interrupted in one process, other processes (executing concurrently or sequentially) will be able to recover transparently.

Community
  • 1
  • 1
Robert Važan
  • 3,399
  • 2
  • 25
  • 31
  • What has embedded resource to do with multiple processes? It looks like your solution of a problem, what is the problem? – Sinatr Feb 17 '14 at 14:52
  • @Sinatr Of course, you could think of many other cases when single file has to be unpacked once, possibly concurrently, but .NET resources are a prime example. If you want to reference unmanaged DLL that's in resources, you have to unpack it first. See the linked SO question for further explanation. – Robert Važan Feb 17 '14 at 15:57
  • So, each process -> embedded dll, unpack, run, clean up.. what is the problem? – Sinatr Feb 17 '14 at 16:00
  • @Sinatr The problem is that your solution fails to fulfill my condition (1) above. Method for reliably capturing application exit (think ASP.NET, for example) is left unexplained. With a few tweaks, it might turn out to be the best solution after all, so don't hesitate to post it as an answer. – Robert Važan Feb 17 '14 at 16:09
  • If you have several processes (exe-files), then they all have to utilize something, lets call it *resource manager*. You need unified access to it (so all processes can extract what they need), but the rest is manageable: request to extract library, request to clean up. Simply count up for first and count down for each library, when counter reaches 0 - you can delete the library, because nobody is *using* it. Perhaps there are winapi functions for this. Also, idea with PInvoke is not my favourite. I'd stick with *loader* (another exe, what extract dll *and* exe from resources, run it, clean). – Sinatr Feb 17 '14 at 16:14
  • @Sinatr Unfortunately, none of that will work in a library. I cannot tell app developers to jump through loops for me. If transparent solution exists, the library should implement it. – Robert Važan Feb 17 '14 at 16:17

0 Answers0