confusing: Users of the application have to separately install the .NET runtime.

[Rick-Anderson]

Type of issue

Other (describe below)

Description

Publishing your app as framework-dependent produces an application that includes only your application itself and its dependencies. Users of the application have to separately install the .NET runtime.

Most of our customers are publishing to Azure (or another cloud) that contains the .NET runtime. We need better wording and should mention when you pub Azur App Svc framework-dependent, Azure has the runtime installed.

@adegeo @IEvangelist please suggest better wording

After we agree on the wording I'll do a "you" ectomy. It reads much better to say

Publishing the app as self-contained
than
Publishing your app as self-contained

The doc is shorter and more accurate. The zillions of consultants that read this don't need to roll their eyes by all the "your"'s.

Page URL

https://learn.microsoft.com/en-us/dotnet/core/deploying/#framework-dependent-deployments-fdd

Content source URL

https://github.com/dotnet/docs/blob/main/docs/core/deploying/index.md

Document Version Independent Id

89967250-8c3b-1999-078f-94ad7518ed49

Article author

@adegeo

Metadata

• ID: 85eba478-0374-bb9b-8fa7-d5cf7d520603
• Service: dotnet-fundamentals

---

Associated WorkItem - 340827

[adegeo]

@Rick-Anderson So are you thinking something like

Publishing your app as framework-dependent produces an application that includes only your application itself and its dependencies. Users of the application have to separately install the .NET runtime. If you plan to run the app in the cloud, make sure that the target framework is already available on the host.

Internal CoPilot suggest this tweak which I don't like:

Publishing your app as framework-dependent produces an application that includes only your application itself and its dependencies. If you plan to run the app in Azure app services or similar environments and are using a released version of .NET, the .NET runtime is typically pre-installed.

That's false for AWS, I don't know about other clouds.

[Rick-Anderson]

@Rick-Anderson So are you thinking something like

Publishing your app as framework-dependent produces an application that includes only your application itself and its dependencies. Users of the application have to separately install the .NET runtime. If you plan to run the app in the cloud, make sure that the target framework is already available on the host.

That's too nebulous.
Publishing your app as framework-dependent produces an application that includes only your application itself and its dependencies. Users of the application have to separately install the .NET runtime. The bold might be technically right but it reads like on Azure with a released version of .NET, you have to separately install the .NET runtime.

We should feature Azure first as that's where are customers are going and where we want to encourage them to go. I wouldn't start out telling them you have to separately install the .NET runtime. I'd start out saying something like

Publishing your app as framework-dependent produces an application that includes only your application and its dependencies, excluding the .NET runtime. If you plan to run the app on Azure App Services and are using a released version of .NET, the .NET runtime is already installed on the service, so you don't need to install it separately.

AWS has eons of latency and they don't bundle the runtime for doggie years after the release. I'm not too worried about explaining AWS and other clouds.

[adegeo]

@Rick-Anderson I don't agree with that direction (but I'll welcome feedback from the product group). We have tons of customers doing desktop and console apps. This documentation is speaking to .NET in a generic sense from the product's point-of-view. If we want to improve the content with some sections talking about cloud stuff, I think that's fine, but I don't think re-tuning the entire doc to be cloud-first is the appropriate direction.

I would expect the user to actually research their cloud service and what it has prior to deploying something to.

Adding @richlander @KathleenDollard who helped drive this article.

[Rick-Anderson]

@Rick-Anderson but I don't think re-tuning the entire doc to be cloud-first is the appropriate direction.

I don't want to re-tune the entire doc, just this section, just the following minor change

Publishing your app as framework-dependent produces an application that includes only your application and its dependencies, excluding the .NET runtime. If you plan to run the app on Azure App Service and are using a released version of .NET, the .NET runtime is already installed on the service, so you don't need to install it separately.

I would expect the user to actually research their cloud service and what it has prior to deploying something to.

Why should they have to research and hunt around to find out you don't typically need to install .NET?

When you publish an ASP.NET Core app to Azure, a message is displayed "publishing framework-dependent" When the user googles "framework-dependent", this is what they get, the problematic text:

Publish framework-dependent

Apps published as framework-dependent are cross-platform and don't include the .NET runtime. The user of your app is required to install the .NET runtime.

The user of your app is required to install the .NET runtime.

That's so confusing to new users. Jane publishes a web app but the users of her app have to install the .NET runtime?

[richlander]

I would avoid mentioning cloud or Azure at all in this little section. Application publishing is very generic.

How about this:

Publishing an application project as a framework-dependent application produces a set of binaries that includes app code and dependencies but not the .NET runtime. The app can be run in any environment or machine where the correct version of the .NET runtime has been installed.

[adegeo]

I think that users would be better served with technology-specific publishing articles. This would help SEO much more than putting blurbs in the content that doesn't get picked up. For example things like:

• How to publish an ASP.NET Core app
• How to deploy an ASP.NET Core service on Azure
• Publish a Windows Forms app
• .NET Aspire deployments
• Tutorial: Publish a .NET console application using Visual Studio Code