Repository navigation
Introduce non-locking implementation for handler #13
Description
Activity
Implementation would require:
- new assembly to hold current - 'UI' & logic
- current assembly repurposed as a thin 'bootstrapper'
Bootstrapper would need to
- create a new AppDomain with shadowCopyFiles enabled
- pass all WinApi calls through the AppDomain to the implementation
- monitor changes to the files in the install directory. Reloading the AppDomain upon any changes
- need to ensure the AppDomain knows about the install directory so the resources (dot.exe) can be accessed correctly
- monitor UnhandledExceptions and present them in some fashion, MessageBox?
This implementation works correctly in a test-bed environment, but fails for some reason when launched within
prevhost.exe.
An alternative is to:- Have a UI component that displays the image, and handles the UI interactions (zoom, print, etc)
- Have a back-end component that renders the image from the stream
This is effectively the implementation of this library, albeit dot.exe directly. A 'better' implementation would be to have a layer of abstraction here, to manage the file more appropriately, this could then manage the encoding - and issues that arise as a result - e.g. #15
Use a new AppDomain to load the assembly so it isn't locked by the is.
This will permit updates to the assembly whilst in use, e.g. rebuilds, automatic updates, uninstall, etc.