After my upgrade to Windows 11 Enterprise (from Windows 10 Enterprise) I couldn't login with my business account in the Windows 11 store to access the private store from my company (Microsoft Store for Business and Microsoft Store for Education).
To fix this, navigate to your business store and select an app there.

Then try to install it, Edge browser will then open your Windows 11 Store and will ask you for your business credentials.

After you did this, your private store is available again.

Attention: When closing the app, the private store is gone again :(

Please read this article about the future of the private stores: https://techcommunity.microsoft.com/t5/windows-it-pro-blog/evolving-the-microsoft-store-for-business-and-education/ba-p/2569423

We are building a project containing of several MicroServices from scratch and thought of how to organize it.

For each microservice we set up an own repository. Which results in the following repo structure:

• MicroService1
• MicroService2
• MicroServiceN
• Global (for shared componenents)
• Documentation (where wiki markdown files and images are stored)

Repositories

Documentation

The documentation is done in the azure devops wiki. Files created and images uploaded are stored automatically in the Documentation repository.

Global

The global repository is the repo where we implement componenents which are used by all MicroServices.

MicroServices

For each MicroService there is an own repository. All MicroServices have the same project structure, because they are created from an custom Visual Studio Project Template.

• Service.Web
• Service.Dal
• Service.Entities
• Service.Client (for calling this microservice)
• Service.UnitTests
• Service.IntegrationTests

Builds and Packages

For every repository we have a build pipeline which builds the solution and runs the UnitTests. The pipeline creates package(s), too.

Global

The global repository has build pipeline, too. Packages from global repository are:

• Global.Entities (shared entities)
• Global.System
• Global.Client.System (Base classes for Service.Client project)

MicroService

Then the pipeline creates 2 nuget packages, Service.Entities and Service.Client. Those will be published to the azure devops nuget feed.

Using the packages

We thought about how to use packages in development and on devops build.
We wanted to make sure, that you can work an your MicroService without bothering with code from for example the global packages. But still have the possibility to develop directly on the global projects directly in the MicroService solution.

How we did this?

To accomplish this we added the global repository as a submodule to the MicroService repository.
We have two solutions, one which uses the packages and one which can switch between packages and directly building against the global projects via the submodule.

Solution with global Submodule

As I described above we have a solution for working with the global code and building directly against it. This is done by adding a new build configuration to the WithGlobal solution.

Here is an example of the project xml with:

<ItemGroup Condition="'$(Configuration)' == 'Debug_Global'">
    <ProjectReference Include="..\..\Global_System\src\Service.Entities\Service.Entities.csproj" />
    <ProjectReference Include="..\..\Global_System\src\Service.Services.System\Service.Services.System.csproj" />
    <ProjectReference Include="..\..\Global_System\src\Service.Client.System\Service.Client.System.csproj" />
  </ItemGroup>

<ItemGroup Condition="'$(Configuration)' != 'Debug_Global'">
    <PackageReference Include="Service.Entities" Version="1.0.*" />
    <PackageReference Include="Service.Services.System" Version="1.0.*" />
    <PackageReference Include="Service.Client.System" Version="1.0.*" />
  </ItemGroup>

You can see the switch between project reference and nuget package. If you are using the normal solution, there is no such build cfg and the Global_System projects aren't in the solution at all.
The WithGlobal solution has the Global_System projects referenced and has the related build config. You can easily switch between the build/debug with the packages or the projects.

Hint: Maybe you recognized the * in the version number. This has the benefit, that the project uses the newest package. You don't need to update the packages every time a new package was build.

Recap

The things described above makes working with packages easy possible. The benefit here is, you can directly work with the global projects. For example editing files, debugging and so on. Edited files can be checked in to the submodule, which then directly triggers an azure devops pipeline and creates a new package.

I worked on a git repository hosted in Azure DevOps. Everything worked fine, until the DevOps was moved to another tenant.
Now my git repository was broken (Authentication failed).

I deleted the whole local repository and tried to get it again.
But every time I tried to clone it, git opened the wrong tenant login view (the old one). Instead of showing the login view for the new tenant.

Here is the log produced by the git clone command.

PS C:\Temp> git clone --recurse-submodules https://CUSTOMER@dev.azure.com/CUSTOMER/PROJECTNAME/_git/REPOSITORYNAME
12:54:57.548715 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
12:54:57.549714 git.c:444               trace: built-in: git clone --recurse-submodules https://CUSTOMER@dev.azure.com/CUSTOMER/PROJECTNAME/_git/REPOSITORYNAME
Cloning into 'REPOSITORYNAME'...
12:54:57.564726 run-command.c:663       trace: run_command: git remote-https origin https://CUSTOMER@dev.azure.com/CUSTOMER/PROJECTNAME/_git/REPOSITORYNAME
12:54:57.573735 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
12:54:57.574735 git.c:704               trace: exec: git-remote-https origin https://CUSTOMER@dev.azure.com/CUSTOMER/PROJECTNAME/_git/REPOSITORYNAME
12:54:57.574735 run-command.c:663       trace: run_command: git-remote-https origin https://CUSTOMER@dev.azure.com/CUSTOMER/PROJECTNAME/_git/REPOSITORYNAME
12:54:57.586245 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
12:54:57.713691 run-command.c:663       trace: run_command: 'git credential-manager get'
12:54:57.747220 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
12:54:57.748222 git.c:704               trace: exec: git-credential-manager get
12:54:57.748222 run-command.c:663       trace: run_command: git-credential-manager get
12:54:57.800265 ...\Common.cs:744       trace: [Main] git-credential-manager (v1.20.0) 'get'
12:54:57.844803 ...\Git\Where.cs:348    trace: [FindGitInstallations] found 1 Git installation(s).
12:54:57.848307 ...Configuration.cs:222 trace: [LoadGitConfiguration] git All config read, 12 entries.
12:54:57.894846 ...\Common.cs:85        trace: [CreateAuthentication] detecting authority type for 'https://CUSTOMER@dev.azure.com/'.
12:54:58.024191 ...uthentication.cs:223 trace: [DetectAuthority] detected 'https://dev.azure.com/CUSTOMER/' as Azure DevOps from GET response.
12:54:58.028695 ...uthentication.cs:291 trace: [DetectAuthority] tenant resource for 'https://dev.azure.com/CUSTOMER/' is {TENANTID}.
12:54:58.029195 ...uthentication.cs:359 trace: [GetAuthentication] AAD authority for tenant 'TENANTID' detected.
12:54:58.059221 ...\Common.cs:140       trace: [CreateAuthentication] authority for 'https://CUSTOMER@dev.azure.com/' is Azure Directory.
12:54:58.059221 ...\Common.cs:765       trace: [QueryCredentials] querying 'AzureDirectory' for credentials.
12:54:58.064225 ...uthentication.cs:384 trace: [GetCredentials] credentials for 'https://CUSTOMER@dev.azure.com/' found.
12:54:58.425183 ...\Common.cs:817       trace: [QueryCredentials] credentials for 'https://CUSTOMER@dev.azure.com/' found.
12:54:58.425682 ...\Common.cs:709       trace: [LogEvent] Azure Directory credentials  for 'https://CUSTOMER@dev.azure.com/' successfully retrieved.
12:54:58.685692 run-command.c:663       trace: run_command: 'git credential-manager erase'
12:54:58.714217 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
12:54:58.715218 git.c:704               trace: exec: git-credential-manager erase
12:54:58.715218 run-command.c:663       trace: run_command: git-credential-manager erase
12:54:58.763760 ...\Common.cs:744       trace: [Main] git-credential-manager (v1.20.0) 'erase'
12:54:58.807796 ...\Git\Where.cs:348    trace: [FindGitInstallations] found 1 Git installation(s).
12:54:58.811800 ...Configuration.cs:222 trace: [LoadGitConfiguration] git All config read, 12 entries.
12:54:58.848831 ...\Common.cs:85        trace: [CreateAuthentication] detecting authority type for 'https://PersonalAccessToken@dev.azure.com/'.
12:54:58.861843 ...uthentication.cs:199 trace: [DetectAuthority] 'https://dev.azure.com/CUSTOMER/' is Azure DevOps, tenant resource is {TENANTID}.
12:54:58.863844 ...uthentication.cs:359 trace: [GetAuthentication] AAD authority for tenant 'TENANTID' detected.
12:54:58.895372 ...\Common.cs:140       trace: [CreateAuthentication] authority for 'https://PersonalAccessToken@dev.azure.com/' is Azure Directory.
12:54:58.896373 ...\Common.cs:259       trace: [DeleteCredentials] deleting Azure DevOps credentials for 'https://PersonalAccessToken@dev.azure.com/'.
12:54:58.900876 ...aseSecureStore.cs:59 trace: [Delete] credentials not found for 'git:https://PersonalAccessToken@dev.azure.com/CUSTOMER'.
12:54:58.917890 run-command.c:663       trace: run_command: 'git credential-manager erase'
12:54:58.947918 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
12:54:58.949418 git.c:704               trace: exec: git-credential-manager erase
12:54:58.949418 run-command.c:663       trace: run_command: git-credential-manager erase
12:54:58.998460 ...\Common.cs:744       trace: [Main] git-credential-manager (v1.20.0) 'erase'
12:54:59.042498 ...\Git\Where.cs:348    trace: [FindGitInstallations] found 1 Git installation(s).
12:54:59.046501 ...Configuration.cs:222 trace: [LoadGitConfiguration] git All config read, 12 entries.
12:54:59.082534 ...\Common.cs:85        trace: [CreateAuthentication] detecting authority type for 'https://PersonalAccessToken@dev.azure.com/'.
12:54:59.221201 ...uthentication.cs:223 trace: [DetectAuthority] detected 'https://dev.azure.com/CUSTOMER/' as Azure DevOps from GET response.
12:54:59.226706 ...uthentication.cs:291 trace: [DetectAuthority] tenant resource for 'https://dev.azure.com/CUSTOMER/' is {TENANTID}.
12:54:59.227707 ...uthentication.cs:359 trace: [GetAuthentication] AAD authority for tenant 'TENANTID' detected.
12:54:59.258733 ...\Common.cs:140       trace: [CreateAuthentication] authority for 'https://PersonalAccessToken@dev.azure.com/' is Azure Directory.
12:54:59.259735 ...\Common.cs:259       trace: [DeleteCredentials] deleting Azure DevOps credentials for 'https://PersonalAccessToken@dev.azure.com/'.
12:54:59.265240 ...aseSecureStore.cs:59 trace: [Delete] credentials not found for 'git:https://PersonalAccessToken@dev.azure.com/CUSTOMER'.
fatal: Authentication failed for 'https://dev.azure.com/CUSTOMER/PROJECTNAME/_git/REPOSITORYNAME/'

I tried to delete the Cache, erase the CredentialManager from git, logout in VisualStudio and so on...but nothing worked.

Solution

The solution was to delete the Credentials for this DevOps from the Windows Credential Manager. Then I cloned the project again and the correct tenant login view appeared.

I've created several branches in azure devops these were:

• main
• dev
• dev/Task-73-GetAllPendingStorageJobs
• Dev/Task-74-DatabaseSessionState

The dev/feature-2 branch was created to work on a specific feature in it, before merging it to dev (and then later to main).

You can use / to create a folder like structure for your branches. Actually folders doesn't exists in git, but many UI clients treat the slash as directory seperator. In most console git clients you will just see the whole branch name without any folder like view.

Now when I tried to pull the dev branch in Visual Studio it didn't work and the git log window in VS showed this error:

From https://dev.azure.com/XX/YY/_git/ZZ
 = [up to date]      master     -> origin/master
 = [up to date]      Dev/Task-73-GetAllPendingStorageJobs -> origin/Dev/Task-73-GetAllPendingStorageJobs
 = [up to date]      Dev/Task-74-DatabaseSessionState -> origin/Dev/Task-74-DatabaseSessionState
cannot lock ref 'refs/remotes/origin/dev': there is a non-empty directory '.git/refs/remotes/origin/dev' blocking reference 'refs/remotes/origin/dev'
 ! [new branch]      dev        -> origin/dev  (unable to update local ref)
Pull operation failed.

This is because all branches with dev/ conflicted with the dev branch on the VS git client. Maybe other clients handle this differently, because for the azure devopps UI the branch naming wasn't an issue.

To fix this, I just renamed dev branch to develop in devops.

Before starting you need to install the Azure CLI for windows.

Deploy AKS & ACR

You can deploy the ACR (Azure Container Registry) before deploying the AKS (Azure Kubernetes Service):

az acr create --resource-group RESOURCEGROUP  --name myContainerRegistry007 --sku Basic

To deploy the aks simple run the following script. The deployment may take 10-15 minutes.

az aks create -n myAKSCluster -g RESOURCEGROUP --generate-ssh-keys --attach-acr myContainerRegistry007

The attach-acr command creates a connection between the aks and the acr, this makes deployment of docker images from the registry possible.

If you want to connect the aks to the acr later or use a different acr, you can use this command:

az aks update -n myAKSCluster  -g RESOURCEGROUP --attach-acr myContainerRegistry007

Deploy ACR image to aks

I've already created an docker image and pushed it to the acr. Read more about this here.

Make sure you have the Kubernetes CLI installed, otherwise the kubectl command is not available.

az aks install-cli

The image is basically a new ASP.NET Core Web App with the Weatherforecast sample API.

To deploy an web app image to aks, you basically need to create 2 things in kubernetes:

1. the web app
2. a load balancer which handles the requests and redirect them to an aks pod.

This is the yaml for the webapp:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: containerweb-deployment
  labels:
    app: containerweb-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: containerweb
  template:
    metadata:
      labels:
        app: containerweb
    spec:
      containers:
      - name: containerweb
        image: myContainerRegistry007.azurecr.io/YOURIMAGENAME:47
        ports:
        - containerPort: 80

and this is for the loadbalancer:

# service.yml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: containerweb-aks
  name: containerweb-aks
spec:
  ports:
    - port: 8080
      protocol: TCP
      targetPort: 80
  selector:
    app: containerweb-deployment
  type: LoadBalancer

Let's start with getting the credentials from our aks:

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Now we need to apply the webapp.yaml file:

kubectl apply -f webapp.yaml

and afterswards the loadbalancer.yaml:

kubectl apply -f loadbalancer.yaml

This will deploy the container and the loadbalancer.

Read more here: https://docs.microsoft.com/en-us/azure/aks/tutorial-kubernetes-deploy-application

I've opened a solution and one project failed to load because of missing depency target.
The targets was MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.2 and the message in the output windows was this:

C:\Users\xx\Source\Repos\XXVS2\XX.UI\XX.UI.csproj : error  : The imported project "C:\Users\xx\Source\Repos\XXVS2\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.2\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the expression in the Import declaration "C:\Users\xx\Source\Repos\XXVS2\\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.2\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" is correct, and that the file exists on disk.  C:\Users\xx\Source\Repos\XXVS2\XX.UI\XX.UI.csproj

In the project the build target file was imported via the <Import> statement.

<Import Project="$(SolutionDir)\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.2\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" />

The issue here is, that if Visual Studio can't find the target file VS can't load the project. But we need VS to load the project, because it's a nuget package where the target file is in. VS will only download the nuget packages for this project, if the project was loaded.
To enable this, we need to add a Condition to the project, then VS can open it and on build it willl download the nuget packages and everything is fine.

Your import should look like this to successfuly load the project in VS.

Import Project="$(SolutionDir)\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.2\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="Exists('$(SolutionDir)\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.2\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets')" />

Source and more about this issue: https://devblogs.microsoft.com/dotnet/nuget-package-restore-issues/

It is important to monitor your disk utilization as your application grows. If the disk quota is reached, it can have adverse effects to your application. To understand what happens you should know about the different types of files and what happens when you scale out.

Types of files

There are 3 main types of files.

Persisted files

They are rooted in D:\home or %HOME% and at /home on linux.
You can rely on these files staying there until you change them. They follow a structure which is described here.
The available space is related to your App Service Plan, see pricing.

Temporary files

A number of common Windows locations are using temporary storage on the local machine. For instance

%APPDATA% points to something like D:\local\AppData.
%TMP% goes to D:\local\Temp.

For Free, Shared and Consumption (Functions) sites, there is a 500MB limit for all these locations together (i.e. not per-folder).
For Standard and higher plans the limit depends on the selected SKU.

Machine level files

The Web App accesses many standard windows locations like %ProgramFiles% and %windir%. These files are read only.

Scaling out

home directory

The home directory is shared through all instances and if you write content in here, all instances will get the change.
Quote from source 2:

The home directory contains an app's content, and application code can write to it. If an app runs on multiple instances, the home directory is shared among all instances so that all instances see the same directory. So, for example, if an app saves uploaded files to the home directory, those files are immediately available to all instances.
Internally, the way this works is that they are stored in Azure Storage instead of living on the local file system.

Temporary files

The temporary files are different, files from instance A aren't available on instance B.

Machine level read-only files

These files can't be changed by users (read-only hehe). That's why we can ignore those files in a scale out scenario.

Sources

1. https://github.com/projectkudu/kudu/wiki/Understanding-the-Azure-App-Service-file-system
2. https://docs.microsoft.com/en-us/azure/app-service/operating-system-functionality#file-access

Like in my earlier post I described that, when you copy the connectionstring from the azure portal into your application and connect with the MongoDB.Driver.MongoClient it will fail due to retryWrites issue.

Microsoft now changed their ConnectionStrings template for azure and now it includes the &retrywrites=false.

So now you can copy the ConnectionString from azure and use it directly with the MongoClient.

I will show you two ways to deploy azure CosmosDb artefacts.

Cosmos SDKs for SQL API

Documentation: https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sdk-dotnet-standard
GitHub: https://github.com/Azure/azure-cosmos-dotnet-v3
Nuget: https://www.nuget.org/packages/Microsoft.Azure.Cosmos/
Samples: https://github.com/Azure/azure-cosmos-dotnet-v3/tree/master/Microsoft.Azure.Cosmos.Samples/Usage
The SDK name maybe confuses people, but you can use this SDK for all CosmosDB APIs (Cassandra API has issues with throughput). I think they will change this soon, because the prerelease Nuget Package already is named Microsoft Azure Cosmos.
It can do 2 things:

1. Create CosmosDb artefacts (Db/collection/documents) - not a CosmosDb account
2. Query CosmosDb documents

Samples

Source: https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-provision-container-throughput

//create the database with throughput
string databaseName = "MyDatabaseName";
await this.cosmosClient.CreateDatabaseIfNotExistsAsync(
        id: databaseName,
        throughput: 400);

// Create a container with a partition key and provision throughput of 1000 RU/s
string containerName = "myContainerName";
string partitionKeyPath = "/myPartitionKey";

await this.cosmosClient.GetDatabase("myDatabase").CreateContainerAsync(
    id: containerName,
    partitionKeyPath: partitionKeyPath,
    throughput: 1000);

Azure libraries for .Net

GitHub: https://github.com/Azure/azure-libraries-for-net
Samples: https://github.com/Azure/azure-libraries-for-net/tree/master/Samples
This is the general library for deploying Azure resources and can't query any documents from CosmosDb. It's can only create azure resources.
Following CosmosDB artefacts can be created (+ nearly all azure artefacts):

• CosmosDB account
• CosmosDB database
• CosmosDB collection

Samples

Here you can find some samples for creating these artefacts with configured throughput: https://developers.de/2020/03/12/mongo-cosmosdb-deploy-with-throughput/

Lets start with a quote from microsoft what throughput actually is:

The cost of all database operations is normalized by Azure Cosmos DB and is expressed by Request Units (or RUs, for short). You can think of RUs per second as the currency for throughput. RUs per second is a rate-based currency. It abstracts the system resources such as CPU, IOPS, and memory that are required to perform the database operations supported by Azure Cosmos DB.
You can start with a minimum throughput of 400 RU/sec and scale up to tens of millions of requests per second or even more. Each request you issue against your Azure Cosmos container or database, such as a read request, write request, query request, stored procedures have a corresponding cost that is deducted from your provisioned throughput. If you provision 400 RU/s and issue a query that costs 40 RUs, you will be able to issue 10 such queries per second.

Throughput can be set on several resources

• database
• container (shared/dedicated)

In this example I am using MongoDB. I've created a database and 2 collections (containers). The database itself doesn't produce any costs.

The database was created with 500 RU, these will be shared through all collections added to the database.
As you can see all databases belong to one db. The difference is that shared and shared2 share the same 400RU.
You can change this behaviour by creating collection with dedicated throughput.

This is how dedicated was created.

Relevant to read:
https://docs.microsoft.com/en-us/azure/cosmos-db/request-units
https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-provision-database-throughput
https://docs.microsoft.com/en-us/azure/cosmos-db/optimize-cost-throughput

We created an application for deploying Azure Cosmos DB Accounts with Mongo-API on demand by using Azure libraries for .Net https://github.com/Azure/azure-libraries-for-net.
For this usecase it's required to create the databases and the collections using this API, too. Otherwise the MongoClient will create those resources automatically if they don't exists. If MongoClient creates those resources, you can't select the throughput and this will cost you much money.

Here is an example how to set the trhoughput on MongoDBCollection.

MongoDBCollectionResource mongoDBCollectionResource = new MongoDBCollectionResource(collectionName);

                var mongoCollectionParams = new MongoDBCollectionCreateUpdateParameters()
                {
                    Options = new Dictionary<string, string>()
                    {
                    },
                    Location = region.Name,
                    Resource = mongoDBCollectionResource
                };

                    mongoCollectionParams.Options.Add("throughput", collectionThroughput.ToString());

                await azure.CosmosDBAccounts.Manager.Inner.MongoDBResources.CreateUpdateMongoDBCollectionWithHttpMessagesAsync(
                    resourceGroup,
                    accountName,
                    databaseName,
                    collectionName,
                    mongoCollectionParams);

The interesting part here is mongoCollectionParams.Options.Add("throughput", collectionThroughput.ToString());.
You can use the same logic for deploying MongoDB databases through adding the throughput parameter.

When creating an Azure Cosmos DB with Azure Cosmos DB for MongoDB API V3.6 and copy the ConnectionString to your application using MongoDB.Driver (in my case 2.10) it's possible that you will see this Exception:

MongoDB.Driver.MongoCommandException: 'Command insert failed: Retryable writes are not supported. Please disable retryable writes by specifying "retrywrites=false" in the connection string or an equivalent driver specific config..'

If you use Azure Cosmos DB for MongoDB API V3.2 this error won't appear.
To avoid this Exception, you have to append &retrywrites=false to your ConnectionString.

Quote from https://docs.mongodb.com/manual/core/retryable-writes/ :
The official MongoDB 4.2-compatible drivers enable Retryable Writes by default. Applications upgrading to the 4.2-compatible drivers that require retryable writes may omit the retryWrites=true option. Applications upgrading to the 4.2-compatible drivers that require disabling retryable writes must include retryWrites=false in the connection string."

Sources:
https://docs.mongodb.com/manual/core/retryable-writes/
https://www.mongodb.com/blog/post/transactions-background-part-6-retryable-writes