Developers can confidently generate single file apps that work for the supported target platforms
samsp-msft opened this issue · 16 comments
Single file apps are a journey, we progressed from a self-extract approach in 3.x to a superhost in 5.0, but there is more to be done to complete the story. Single file apps need to work for every .NET workload and app framework where the target platform allows for it (to reduce developer perceived complexity of seeing several output files vs one output file), including:
- Winforms
- WPF
- MAUI
- ASP.NET including MVC, Razor Pages, Server-side Blazor, WebAPI, gRPC etc.
Goals:
- Predictability: Developers should be aware of what will and won't work in a single file experience
- Ensuring that referenced libraries are also not going to produce issues
- Completeness for specific workloads
Work Items
- Flush out testing for each of the scenarios
- Extend superhost beyond Linux #43071
- Create superhost for Windows
- Create superhost for MacOS
- Enable debugging of superhost apps with Visual Studio #45382
- Tooling & Experience
- Add analyzers for common issues that occur with single file apps, such as file path resolution from the assembly
- Integrate the analyzers into Visual Studio
- Add attribute to decorate places which are incompatible with single file
- Some way to enable these analyzers when building apps (dotnet/sdk#14562) and libraries
- Improve single-file integration with linker #44488
- Improve single-file-publishing for ASP.NET dotnet/aspnetcore#27888
@agocke - we need to flush out the list of work items
@agocke do you want to create child stories eg for the proposed analyzer? We have a dependency on it presumably.
Analyzer already exists and shipped in .NET 5 :)
I'll create a tracking issue for the few improvements we would like to make, although many will not require changes to the libraries.
I'll create a tracking issue for the few improvements we would like to make, although many will not require changes to the libraries.
That sounds great - anything to see the work likely on us.
Tagging subscribers to this area: @agocke, @vitek-karas
See info in area-owners.md if you want to be subscribed.
Issue Details
Single file apps are a journey, we progressed from a self-extract approach in 3.x to a superhost in 5.0, but there is more to be done to complete the story. Single file apps need to work for every .NET workload and app framework where the target platform allows for it (to reduce developer perceived complexity of seeing several output files vs one output file), including:
- Winforms
- WPF
- MAUI
- ASP.NET including MVC, Razor Pages, Server-side Blazor, WebAPI, gRPC etc.
Goals:
- Predictability: Developers should be aware of what will and won't work in a single file experience
- Ensuring that referenced libraries are also not going to produce issues
- Completeness for specific workloads
Work Items
- Flush out testing for each of the scenarios
- Extend superhost beyond Linux #43071
- Create superhost for Windows
- Create superhost for MacOS
- Enable debugging of superhost apps with Visual Studio
- Tooling & Experience
- Add analyzers for common issues that occur with single file apps, such as file path resolution from the assembly
- Integrate the analyzers into Visual Studio
- Add attribute to decorate places which are incompatible with single file
- Improve single-file integration with linker #44488
| Author: | samsp-msft |
|---|---|
| Assignees: | agocke, samsp-msft |
| Labels: |
|
| Milestone: | - |
@agocke I think this should be marked Committed (in the .NET 6 project). It has committed children. Otherwise it will get reviewed..
Thanks Dan. I have done at least 3 scans of the epics/themes/user stories, but I seem to keep finding new ones
Do single file applications need to be code signed? What is the user experience for non-signed single file applications?
@greatoceansoftware From .NET's point of view they don't need to be signed. Specific target platforms might have additional requirements though (for example macOS). The apps behave the same whether they are signed or not. .NET itself doesn't look at the signature, it's typically the target OS which does that.
Thanks. I have a couple of machines I will test. Seems like there should be an article in the MS/.NET documentation somewhere that describes the user experience of single file installs (for comparison, there is adequate information on ClickOnce), but I haven't found one yet.
@greatoceansoftware Just so that I understand your request: what do you mean by "experience of single file installs"? Single-file is a publish option, it's not a deployment technology (unlike ClickOnce which is exactly that).
I'm asking what does a user see when they download and try to run a single file application for the first time? Especially in terms of security warnings with signed/unsigned code. I can test it here, just not quite ready yet. Sorry, it's been almost a decade since I published to anyone except myself and I'm sure things have changed a bit. Most of my apps are internal use only.
There's really no difference in that experience between single-file or non-single-file, so what you're asking about is a general experience of running a .NET app - which is probably very similar to running any "freshly" compiled app (ignoring dependency problems).
Well, I can make a long story long... ;-) I released my last commercial application circa 2013, and used the Lindersoft SetupBuilder (similar to InstallShield). I signed my code and the installer. As a small developer, this was a real pain to obtain the certificate, and compile .NET setup packages, and keep users current with different newer versions of the software. Despite that, the installer did a nice job of ensuring the user had a good first experience (no scary installation warnings).
Fast forward to now, it seems there's a possibility to make life simpler at least on the developer end with single file installs. But I can't find any documentation (similar to ClickOnce documentation) on what the user will experience if they try to run one of these single file applications. So my only recourse is to test it myself (not a big deal), but I only have so many machines where .NET 5 has never been installed (with various flavors of Windows 10) to see how it will/should react with different publish options (sign/unsigned, framework dependent/self-contained, etc.).
I have colleagues who will help me beta test, but I feel like there should be some further guidance in the documentation about the effects of our publish choices on end users. Thanks, and hope that made sense.
This is mostly done -- we have a single file analyzer now, which can be enabled with <EnableSingleFileAnalyzer>true</EnableSingleFileAnalyzer>. The analyzer is enabled in dotnet/runtime and winforms. Remaining work is mainly on enabling the analyzer in more places.
Closing as complete.