@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 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.

@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 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?

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.

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

Now that I look at the article, not just the text here, I think the page needs to be re-written. It was written for a different time, back with .NET Core 1.0 and before we had a good cloud story.

You can see that in this image. The TOC says "deployment models" and the articles says "publishing overview". Those are not the same thing and are the crux of this discussion.

Ideally, the article would lead with a discussion of common deployment targets and how it is straightforward to produce apps and other artifacts (like containers) for them. And then the rest would be links to other content, along the lines of what @adegeo suggested. This approach would also enable us to talk about cloud services sooner, per what @Rick-Anderson suggested. We'd then move all of the framework-dependent and friends content to a different topic.

I've always found this topic to be an abrupt intro into the general topic of deployment. I've never found a good way of describing that.

I'm happy to help on this if you want to share a branch.

@baronfel

Great points everyone. Each article in this area has kind of evolved independently and there hasn't been an overall story. Perhaps we should start with planning a high level overview of what we want the area to describe.

Tagging @IEvangelist who has done some work on this article recently.

Tagging @IEvangelist who has done some work on this article recently.

Just read through all of the issue comments, I agree that this seems a bit dated, and each area has evolved independently. It makes sense to refocus on this area all up and plan on updates.

I think to start, we can just move the current content to its own topic and write a new intro. That should help us determine what's actually needed. I can start that if folks want.

I'll take a look at redesigning and rewriting this content in Dec. Thanks everyone!

Pushed to Jan due to priority.

Due to quite a few high priority items, I'm moving this out to April and increasing priority.