Comments (11)
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.
from docs.
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.
from docs.
@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.
from docs.
@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.
from docs.
@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.
from docs.
@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:
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?
from docs.
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
from docs.
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.
from docs.
Tagging @IEvangelist who has done some work on this article recently.
from docs.
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.
from docs.
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.
from docs.
Related Issues (20)
- Link does not have folder mentioned, but PR does
- Repo Status HOT 4
- error CS1674: 'Options': type used in a using statement mu st be implicitly convertible to 'System.IDisposable'. HOT 1
- 本地化文件下载不了
- Install script site is down HOT 1
- Add defaults to HTTP resiliency content
- On .NET Live — Planning and Execution
- On .NET Live planning/execution for week of 7/1
- .NET Data for Beginners - Intro video
- .NET Data for Beginners - SQL/ADO.NET
- .NET Data for Beginners - ORMs
- CS0809 should mention that the ObsoleteAttribute will not work if applied to an overidden member only HOT 1
- Dead link to ILLink documentation
- Provide some guidelines for observable instruments.
- Typo in "Method Parameters" Documentation, at section "Combinations of parameter type and argument mode" HOT 4
- The documentation of the order of static constructors is wrong. HOT 2
- شرقيه
- Undefined acronym
- Bad example of SocketsHttpHandler.PooledConnectionLifetime usage for "typed client" HOT 3
- Missing link
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docs.