-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Support Platform-independent single-file app DLLs #13677
Comments
@Logerfo I think what you need to do is to publish the app as a framework-dependent single-file. This will embed all dependencies of the app except the framework binaries. |
@swaroop-sridhar I didn't know about that possibility, but it still doesn't make sense to me. Why does it require a runtime identifier to be specified if it's not self contained? The default runtime environment is supposed to be framework dependent... |
@Logerfo the single-exe app includes the managed components and the native host. The result is a native binary that must be built per target OS/architecture. Therefore, The framework-dependent aspect just means that we don't package the framework binaries into the app -- thus making it smaller. That is, the resultant app is still a platform specific native binary containing all dependencies except for framework binaries (which need to be installed elsewhere). The current support for framework dependent single-file apps seems to fulfill your original objective -- embedding third-party dependencies and not including the framework. What you're probably also asking is to embed all dependencies into the (portable) managed app, which can then be launched via the |
Adjusted the title to refer to the issues discussed in the previous comment |
Another problem: I have a console application which has references to |
When I tried running your command I saw the following error:
|
@Logerfo editing the single-file app once built is not a good idea. The single-file app contains a directory of contents, with hard-coded offsets and sizes. So, there's a good chance your edit will break the knowledge encoded in this directory. The edit to change the framework seems like a hack to me. My advise would be:
|
@devedse You've added the But you can still publish a framework-dependent app as a single-file. |
The startup times of DotNet Core Single File WPF apps is a lot slower then the original ILMerge-ed WPF application build on .net 4.7. Is this to be expected or will this improve in the future? Builds come from my ImageOptimizer: https://github.com/devedse/DeveImageOptimizerWPF/releases
|
@devedse, to make sure, is the "second startup" the average of several runs (other than the first)? So, before investigating, I want to make sure the numbers in the "second startup" are stable numbers and that the difference in startup is reproducible, Also, this issue is about single-file plugins, can you please move the perf discussion to a new issue, or to https://github.com/dotnet/coreclr/issues/20287? Thanks. |
Tagging subscribers to this area: @swaroop-sridhar |
Would these DLLs be openable by double clicking them, similar to the old CIL EXEs or Java JARs, or would they still require the user to pass them to the |
Single-file platform-independent DLLs would be great, but from a UX perspective for a GUI user, they would still need some sort of shell script or LNK shortcut to launch them with the |
Short answer: no. In order to support double-click like action on anything but executables there would have to be one of two things:
Additionally for GUI applications (at least on Windows) - running I don't know enough about GUI systems on Linux/Mac to be able to tell if there's a more elegant solution on those platforms. |
On Linux (and I think it's the same on Mac), every executable is fundamentally a command-line one, and just has the option of opening a GUI window. If you double click on an executable which doesn't open a GUI, it will just run and close without anything visible happening. So I don't think associating a file with I think a good cross-platform solution could be to have a loader which is itself a .NET program, and which includes the native loader as usual (and is therefore platform-specific). Then, it could be associated with a file extension for single-file .NET applications, and when you open one of those applications, hopefully it would be able to call the entry point without having to create an entire new process. Such a tool could be made and distributed separately from .NET itself, but depending on it would probably be too risky at that point, since users would be very unlikely to have it, so the file would just be unrecognized. So I think for such a format to be useful it would have to be part of .NET itself. Ultimately though, I can see why this is not as large of a priority as it used to be. Opening loose executables off a disk is becoming a lot less common in a world of package management, so having a platform-specific wrapper script to run |
Currently, single executable applications (with or without trimming) packages both framework and third party libraries. Because of the former, the result is very large sized if compared to non-packaged builds.
There should be an option to only package third party libraries, still relying on the installed framework.
An alternative is Costura, but:
I don't think it would be hard to implement this, since the current feature is more complex than the requested alternative approach.
The text was updated successfully, but these errors were encountered: