-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Change nuget packages projectUrl to point to doco or better landing page #12537
Comments
@ajcvickers sorry for the cheese moving. but i actually think this should be in https://github.com/MicrosoftDocs/feedback. since it is not specific to only EF. thoughts?? |
@SimonCropp We can change what we do for EF packages. For other packages, you'll need to file an issue in an appropriate place where the owners of those packages will see it. I suspect in all cases the issues should be in "code" repos not docs repos because the packages are generated by the build. The same thing applies to API docs. For other packages in ASP.NET, https://github.com/aspnet/Home would be the right place. |
I tried to do this. I was wrong.
|
@divega What URL should we use? |
For starers, I would point almost all our packages to https://docs.microsoft.com/ef/core/. But providers can point to their specific pages, e.g. https://docs.microsoft.com/ef/core/providers/sql-server/. We should also make sure we have pointers to GitHub visible in the documentation (the SQL Server provider already has it). Normally I would use a fwlink, but it just happens that NuGet gallery shows the actual URL in the UI, so perhaps aka.ms links with something meaningful would be better. Sounds good? |
Notes for Muggles: - `build` only compiles by default. Add `-test` to run tests and `-pack` to get nupkgs - Dependency versions are now in `eng/Versions.props` - No more API Check, *.baselines.json, or *.breakingchanges.json - No more NuGet package verifier - Nightly builds are now published to https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json Fixes #12537, resolves #14025, resolves dotnet/arcade#1051, resolves dotnet/arcade#1052, resolves dotnet/arcade#1053, resolves dotnet/arcade#1054
Notes for Muggles: - `build` only compiles by default. Add `-test` to run tests and `-pack` to get nupkgs - Dependency versions are now in `eng/Versions.props` - No more API Check, *.baselines.json, or *.breakingchanges.json - No more NuGet package verifier - Nightly builds are now published to https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json Fixes #12537, resolves #14025, resolves dotnet/arcade#1051, resolves dotnet/arcade#1052, resolves dotnet/arcade#1053, resolves dotnet/arcade#1054
Notes for Muggles: - `build` only compiles by default. Add `-test` to run tests and `-pack` to get nupkgs - Dependency versions are now in `eng/Versions.props` - No more API Check, *.baselines.json, or *.breakingchanges.json - No more NuGet package verifier - Nightly builds are now published to https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json Fixes #12537, resolves #14025, resolves dotnet/arcade#1051, resolves dotnet/arcade#1052, resolves dotnet/arcade#1053, resolves dotnet/arcade#1054
Notes for Muggles: - `build` only compiles by default. Add `-test` to run tests and `-pack` to get nupkgs - Dependency versions are now in `eng/Versions.props` - No more API Check, *.baselines.json, or *.breakingchanges.json - No more NuGet package verifier - Nightly builds are now published to https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json Fixes #12537, resolves #14025, resolves dotnet/arcade#1051, resolves dotnet/arcade#1052, resolves dotnet/arcade#1053, resolves dotnet/arcade#1054
Notes for Muggles: - `build` only compiles by default. Add `-test` to run tests and `-pack` to get nupkgs - Dependency versions are now in `eng/Versions.props` - No more API Check, *.baselines.json, or *.breakingchanges.json - No more NuGet package verifier - Nightly builds are now published to https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json Fixes #12537, resolves #14025, resolves dotnet/arcade#1051, resolves dotnet/arcade#1052, resolves dotnet/arcade#1053, resolves dotnet/arcade#1054
Moved from dotnet/EntityFramework.Docs#803 filed by @SimonCropp since NuGet packages and their metadata are generated as part of the build.
Often searches will resolve to a nuget package. or people will know the nuget they are using and want to find the doco for it.
However most MS nuget
At the moment nugets point to generic getting stated pages. For example
All point to https://www.asp.net/
This experience looses all context of the users navigation history, and is unlikely to be the desired page for most people. I would expect the better locations would be
I realise that the history of nuget versions is static, but doco is a changing structure. but you could manage the redirects dynamically with all nuget pointing to a redirector
https://docs.microsoft.com/nugets?Microsoft.EntityFrameworkCore.SqlServer&version=1.2.3
another option would be ad to nuget the ability to store more urls. eg "project hosting url", "docs url" etc
The text was updated successfully, but these errors were encountered: