Command Line Interface Tools and Techniques
View All Tags
dotnet restore said Restore succeeded, with one warning: Unable to find a project to restore!. Nothing had been restored. I had run it in a folder whose solution file didn't list any projects yet, so that's what it restored: nothing. Pointing it at the project, or adding the project to the solution first, fixes it.
I created an ASP.NET Core Web API project inside a .NET 10 solution that manages package versions centrally, and the template's own restore failed with error NU1008. The template writes a package version into the project file, which central package management doesn't allow. Moving that one version to Directory.Packages.props fixes it.
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.
