Update first-web-api.md #28103
Update first-web-api.md #28103
Conversation
Without exporting the path, it cannot recognize the aspnet-codegenerator.
|
Hello @masudme09 ... This really shouldn't ... in theory 😄 ... be necessary. The path should be there based on the first run of the SDK installer. Cross-ref: https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-global-tool I'm not fully aware tho of all of the juicy details for when devs opened issues on the SDK repo for when global tools weren't found and a 💥 occurred, issues such as dotnet/sdk#9415 and dotnet/sdk#23165. @peterhuene ... Are you able to remark on this, or should William Li perhaps be pinged for assistance? btw @masudme09 ... Just for future reference, we ask that an issue be opened for anything that isn't a trivial change (e.g., spelling error, small code example error). These types of fundamental changes to the coverage almost always need a little discussion before proceeding to a PR. No worries here tho ... I'm just saying for future reference. |
|
@guardrex I understood that I had made the PR too soon. Anyways, I am using ubuntu 22.04 and I have tried to prepare the environment on vscode. Following: https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-7.0&tabs=visual-studio-code And everything was smooth until dotnet-aspnet-codegenerator. After lots of navigation to documents and checking older versions of the documentation - exporting path works. And another piece of information- I have installed dotnet 7.0.102 I hope this helps, or I will create a docker container to reproduce the issue. |
|
Let's see if Peter (or William) can advise. They may want to move this over to the SDK repo for further investigation ... i.e., why is this happening and can it be solved in a fundamental way on the SDK installer side? If so, we prefer not to document workarounds in tutorials. We usually point to the SDK installer docs, such as the one that I mentioned. If there's a need to note this type of PATH setting for specific platforms, they'll call it out there for everyone. This isn't the only spot that a workaround callout like this would need to be made around here and in other MS doc sets where it applies. The central location for such remarks would be where the .NET tooling docs are located. Let's see what they think about the next step. btw wrt Docker ... IIRC, that was a whole additional can of 🪱 worms 😄 ... IIRC, there were separate SDK repo issues pertaining to that because there were other PATH-related problems finding tools in Docker setups. I think they worked on those problems separately, and I'm not aware if/when they solved the problems that were reported. Stand-by ... We're on a holiday today. Peter will probably be along in a bit. |
|
Hi @guardrex. I actually left Microsoft back in 2019 and haven't been involved with .NET since then in any capacity. @marcpopMSFT do you know who best to comment and route this issue to? |
|
Thanks @peterhuene ... I should've checked your profile. I was going off of one of the issues related to this. |
|
Let's just go ahead and triage this on the correct repo ... @masudme09 ... Open an issue for the SDK team at ... https://github.com/dotnet/sdk/issues/ Explain how the path wasn't set and you didn't have tools access for Ubuntu 22.04 for an ASP.NET Core tutorial. Please add ... ... to the bottom of your opening comment so that I can follow the discussion. I'll get up with Rick on this repo if it turns out that something needs to be done here. For example, we might add a cross-link and remark for scenarios where the reader must take an extra step based on their platform. Oh, I and should add: Search those issues first for "ubuntu" and maybe with "tools" to see if the issue has been reported already. Search open and closed issues there. There's no sense in opening a new issue if they're already investigating or working on something for it ... or they figured out the reason for it ... an edge case that's up to the dev to resolve, for example. |
|
Filing an issue on the SDK repo is the correct action though I'm not sure why the path wouldn't be set during the first run of dotnet. The only reasons would be if there was an environment variable set not to configure the path or because we'd already done it: https://github.com/dotnet/sdk/blob/main/src/Cli/Microsoft.DotNet.Configurer/DotnetFirstTimeUseConfigurer.cs#L106 |
|
That's what they'll investigate ... or perhaps they already know the answer and can just remark directly on it without further investigation. |
Without exporting the path, it cannot recognize the aspnet-codegenerator.