Command Line Interface Tools and Techniques
View All Tags
Microsoft's page on ASP.NET Core environments says dotnet run -e Staging sets the environment. I ran it, and my API started in Development anyway, with no error and no warning. -e sets an environment variable, so it needs a name and a value: -e ASPNETCORE_ENVIRONMENT=Staging does what the short form promises.
dotnet build normally ends with a compact Build succeeded in 0.9s. In one terminal it printed the old format instead — Build succeeded., 0 Warning(s), 0 Error(s), Time Elapsed. The build was fine. The display wasn't what I expected, because on macOS and Linux .NET decides how to draw its output from the TERM environment variable, and mine was empty.
Part 12 produced the release files. This part installs the two managed ones the way a buyer would: in a new environment, on a new SharePoint site, with nothing carried over from where the app was built. Then a manager and an employee use it.
Environment variables keep a solution's settings apart from what uses them: which SharePoint site and lists an app reads, for example. When a solution's variables arrive without a value, the import asks you for them, so the same solution can point at a different site in every environment. This guide fills them in during the import, and in a settings file for the CLI.
Importing is how a solution gets into an environment: you upload the zip, Power Apps shows what's in it, asks for anything it needs from this environment, and installs it. This guide imports a managed solution in Power Apps, then does the same with the Power Platform CLI.
The app and its setup flow both work. This part turns them into four files anyone can install: both solutions, checked, at version 1.0.0.0, as managed and unmanaged zips, and without this tenant's SharePoint site and lists inside them.
When you export a solution, its environment variables' current values go into the zip, so everyone who installs it gets your values. This guide takes them out with the Power Platform CLI: unpack the managed and unmanaged exports together, delete the value files, and pack both zips again.
Exporting turns a solution into a zip file that another environment can import: managed to install it, unmanaged to keep developing it. This guide exports the same solution both ways, with the same version number, and then does it with the Power Platform CLI.
The solution checker reads everything in a solution against Microsoft's best-practice rules and lists what it finds, each with a severity and a link to guidance. This guide runs it in Power Apps, reads the results, and runs the same check from the Power Platform CLI, whose result file also says which control each issue is on.
An exported solution is an ordinary zip file. Listing what's inside shows what you're about to share: its version, whether it's managed, and anything that shouldn't travel with it, such as your environment variables' values. This guide does it in a terminal on macOS, Linux and Windows.
