What a journey!  I am going to document this for the sole reason that I am aware that I will once again need this information only just a few days from now.  Problem: I have a nuget package that I want to push to an Azure Artifact directory.  I figured easy enough there is some documentation and I tried with the following:

nuget push -source "MyFeed_feed" -apikey az "C:\tfs\Git\MLayout\MLayout\MLayout\bin\Debug\Layout.1.0.0.nupkg"

I did have to download Nuget and ensure it was found when using the above command via command prompt.  Once setup, and re-ran I was prompted for username and password. As many times as I tried it would just continue to fail and eventually would timeout.  I am sure this worked just a few weeks ago.

Regardless on to plan B, documentation..

1) I downloaded the latest Nuget.exe

2) Download and install the credential provider (this one was a bit more challenging)

I figured I would use the Automatic approach. 

a) I downloaded installcredprovider.ps1 from this github location https://github.com/microsoft/artifacts-credprovider/tree/master/helpers (more information can be found here)

b) Now that I have a file on disk, I have to run it.  I started Powershell  then proceeded to run this ps1 by typing .\installcredprovider.ps1 at the PS >

d) Now with this installed I retried to push my nuget package with nuget push -source "MyFeed_feed" -apikey az "C:\tfs\Git\MLayout\MLayout\MLayout\bin\Debug\Layout.1.0.0.nupkg"

     No go, so I tried with using the vs.net command prompt.

    I opened up a command prompt from Windows-Start ensuring to pick the “Developer Command Prompt for VS 2019”
   

       
Now, I ensured that nuget.exe was available and it was! So I retried my nuget push.  You can see finally, that it used the Credential Provider

 

The entire process probably 1 hour of effort, but essentially using the VS.NET 2019 command prompt, download the ps1 for the credprovider, execute using powershell then retry.  Finally.

Running locally via Visual Studio and JetBrains Rider and managing the ASPNETCORE_ENVIRONMENT variable has been challenging.  Changing and setting ASPNETCORE_ENVIRONMENT within launchSettings.json and/or within Project Properties impacts the web.{envrionment}.config files.  Without the appropriate configuration within the publish steps the site was being deployed with incorrect settings and it was time consuming to track it back to the best approach.  So for now I have a pipeline build process setup for each AppService ‘slot’ setting different BuildConfiguration within each to ensure the most appropriate web.config is deployed.

This is a .net core asp.net web application so why the web.config? It appears that locally during IIS Express/IIS there is still a dependency on this web.config to identify the hosting model (inprocess) and reference to the exe that would be run.  This is of course when deploying to Windows infrastructure.

Project Properties – Environment variables

My launchSettings.json – you can see I can modify before running how IIS or IIS Express identifies the environment variable

The resultant/related web.configs looks like the following for Development and Staging environments.

web.config

web.Staging.config (you can see the addition of the xdt:Transform=”Replace” attribute which informs publish that when building for Staging to replace this variable within web.config with this value)

By default the build process on Azure DevOps – Pipelines was ignoring any file transformation requirements.  In order to establish File Transformation on publish notice the –configuration $(BuildConfiguration)

and the respective variable that is used during publish to identify the appropriate configuration to use (development/staging etc.)

After the build and using App Service Editor my web.config was successfully transformed