DeadLock icon indicating copy to clipboard operation
DeadLock copied to clipboard

Portable version

Open r15ch13 opened this issue 8 years ago • 6 comments

Hi, will the next release also include a portable version? I would like to add DeadLock to Scoop as an replacement for Unlocker (https://github.com/lukesampson/scoop-extras/issues/356). A simple *.zip or *.7z file would be easier to install than the current setup executable. :smile:

r15ch13 avatar Mar 23 '17 16:03 r15ch13

Definitely! We've discussed software portability in a blog post here: http://codedead.com/?p=1294

CodeDead avatar Mar 23 '17 16:03 CodeDead

Nice! Watching the repo to add it as soon it's released 👍

r15ch13 avatar Mar 23 '17 17:03 r15ch13

This will be made possible in the upcoming WPF remake!

CodeDead avatar Nov 07 '17 20:11 CodeDead

As far as I know, a .NET portable app can be made in two ways with a stable SDK release: A. Require the system already have .NET Framework and its dependencies. Framework 4.8 is pre-installed and continually updated on most Windows systems. It can run .NET Framework apps compiled for any previous 4.x runtime with minor differences where the API had a breaking change. I an imagine that some domain/organization-managed systems might not have the Framework installed for NUCs. B. The app is published its own copy of the .NET runtime via Self-Contained.

[One problem with the latter is trim-incompatibility] of WPF and WinForms](https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/incompatibilities). Without IL trimming, the entire .NET Runtime is included with the build artifacts and leads to a 100MiB+ deployment. This might change with ~~.NET 7~~ .NET 8(?) if these libraries are updated to use trim-compatible code.

  • WPF uses a lot of assembly Reflection and run-time code inspection. The member-level trimmer of .NET 5 and even 6 cannot walk certain uses of Reflection. See https://github.com/dotnet/wpf/issues/3811 for updates.
  • Similarly, WinForms uses a bit of Reflection in addition to lots of built-in COM marshalling. When all of its reflection and COM marshalling is switched out for COM wrappers, it will become significantly more trim-compatible. Not completely, though. See https://github.com/dotnet/winforms/issues/4649 for updates.

Note: .NET 7 appears to be introducing native-code Ahead Of Time compilation. I haven't looked into it enough to know if the resulting assemblies could be considered portable or if they would still have platform-specific runtime prerequisites.

BinToss avatar Apr 18 '22 00:04 BinToss

NET 7 appears to be introducing native-code Ahead Of Time compilation.

WPF does not support AOT and it's very unclear if it will be supported in the future at all. Winforms support AOT unofficial with some workarounds according to users. Avalonia (WPF-like cross platform UI) however supports AOT already. Unfortunately the portable AOT version of an Avalonia app is quite big in size.

Symbai avatar Apr 18 '22 05:04 Symbai

I'm thinking more of a radically different approach. In the sense that something like Tauri + Rust and a React frontend are perfectly capable of providing small binaries, which are portable, in addition to providing the same (or slightly different) user interface that our users are already used to. It would completely remove the requirement of .NET and be modern and maintainable.

A dotnet library for DeadLock could also be made available, and I'm working on one right now for developers as a NuGet package.

CodeDead avatar Apr 18 '22 14:04 CodeDead