Issue

IIS Express will occasionally not be able to start on a particular port with this error.

Unable to connect to Web Server IIS Express

In some cases, it's because another app is using that port. But often the reason is that Hyper-V has reserved one or more of the ports. To see which ports are currently excluded/reserved, run this command.

Note: all commands are in PowerShell 7 and should be run as Administrator

netsh int ipv4 show excludedportrange protocol=tcp

The result may look something like this.

Start Port    End Port
----------    --------
     50000       50059     *
     54675       54774
     54840       54939
     54940       55039
     55040       55139
     55140       55239
     55329       55428
     55429       55528

As far as I can tell, Hyper-V doesn't have a known port range it will attempt to use and work around. So, the solution is to exclude the individual ports your projects require.

You can check which ports the apps use by looking at the launchSettings.json files (assuming .NET Core). Be sure to include both the HTTP and SSL ports. Let's say, across all your projects, IIS Express will need to run on ports 44431,44435,54700,54701.

1. Disable Hyper-V

   dism.exe /Online /Disable-Feature:Microsoft-Hyper-V
   

2. Restart when prompted
3. Run this script, substituting your ports

   $ports = 44431,44435,54700,54701
   
   foreach ($port in $ports) { 
       netsh int ipv4 add excludedportrange protocol=tcp startport=$port numberofports=1 
   }
   

4. Reenable Hyper-V

   dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
   

5. Restart when prompted

Troubleshooting

Error: The process cannot access the file because it is being used by another process.

If you get this error when running netsh to exclude the port, the port is already excluded. It's a confusing error message.

Windows could not start the Hyper-V Virtual Machine Management service on Local Computer. Error 0x8007000e: Not enough memory resources are available to complete this operation.

If you attempt to start the Hyper-V Virtual Machine Management service and get this error, it can be caused if the Hyper-V Host Compute Service is Disabled. Open Services and set that service as Manual.

References

• Administered Port Exclusions blocking high ports – The 'almost not worth having' blog
• Unable to bind ports: Docker-for-Windows & Hyper-V excluding but not using important port ranges · Issue #3171 · docker/for-win
• What to Do When Hyper-V Won’t Start - vembu
• windows - Cannot bind to some ports due to permission denied - Stack Overflow
• How to use reserved port in netTcpBinding and basicHttpBinding in a WCF Application | Microsoft Docs
• windows 10, port reserved for HyperV
• The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008 - Windows Server | Microsoft Docs
• windows 10 - How to remove a Hyper-V virtual Ethernet switch - Super User
• Hyper-V Manager unable to connect to server "Local computer"
• Error: 0x8007000e Not enough memory resources are available to complete this operation. · Issue #5240 · microsoft/WSL
• Windows 10 Hyper-V System Requirements | Microsoft Docs
• windows - How do I find out why certain ports are excluded and delete the exclusion? - Server Fault
• hyper v - What is Administered port exclusions in windows 10? - Stack Overflow

I don't know how much guidance Microsoft gives on creating Iterations. This is my approach.

The Basics

Here's the Azure DevOps structure, regardless of usage:

|_Process [Work items defined]
  |_Project(s) [Iterations defined]
    |_Team(s) [Board defined, Iterations selected]
      |_Area(s) 
        |_Work Item(s) [assigned to Area and Iteration]

There's always a top-level "iteration" with the name of the project, which can't be changed. This is confusing because everything in the iteration tree is called an iteration, but in fact you should think of the tree as folders of iterations.

You configure iterations at the project level (Project Settings > Boards > Project configuration). However, a Team chooses which iterations it uses. In other words, adding iterations to the project does not add them to all teams.

While initially confusing, this gives a lot of flexiblity in the project. Everyone can be on the same sprint cycle, or individual teams can be on their own cycle.

The Most Common Configuration I Recommend

Here's how I'd set up a project that has one or two teams, which should be all that are on an Agile-based project anyway.

Notice I do not use the root level for the product backlog. Unfortunately, Microsoft doesn't help enough in setting this up.

Baskets-R-Us Website
|_Product Backlog
  |_Sprint 2021-04-16
  |_Sprint 2021-04-30

Why "product backlog"? In Team configuration > Iterations, there are two settings: Default iteration, Backlog Iteration.

Default Iteration means "when I create a new work item, which iteration is it assigned to?" The default is @CurrentIteration. This is wrong! New work items should not be automatically added to the current sprint: that's contrary to Scrum thinking. Instead, I set Default iteration to the team's product backlog iteration.

Likewise, Backlog iteration means "When we look at our backlog, which iteration is at the root?" That should be, of course, the product backlog iteration. That's why I keep the naming clean.

Both teams on this project would use the same product backlog and iterations. The teams would have independent boards and work items because by default a team has its own area.

The result is that, in sprint planning, everyone would work from the same product backlog. Assuming Scrum, the project (product) should have a single Product Owner and Scrum Master shared by the two teams. When work items are assigned to iterations, they're also assigned to the team's area, allowing each team to filter for its work items in its boards.

Naming Iterations

Where organizations often go astray is naming.

Here's one way iterations might be organized for multiple teams. Again, notice my naming.

Baskets-R-Us Website <== root level folder
|_ eCommerce Product Backlog
  |_2021-04-07
  |_2021-04-30
|_Social Media Product Backlog
  |_2021-04 05-16
  |_2021-04 19-30

In this case, the teams within the project are working very independently. They don't share a backlog, instead each team maintains its own.

Yet Another Approach

Here's another--arguably better--way to organize multiple teams on a single Scrum-based project where the teams want to use their own sprint cycles. On a single project with just a couple of team. That's probably not a good idea. Keep the teams working as closely together as possible on the same project.

This rule of thumb doesn't apply on teams across projects, who shouldn't be constrained in how they independently work. They not only should have separate DevOps projects, but should be allowed to have their own process template.

Baskets-R-Us Website <== root level folder
|_Product Backlog
  |_ eCommerce Sprints
    |_2021-04-07
    |_2021-04-30
|_Social Media Sprints
    |_2021-04 05-16
    |_2021-04 19-30

Given this organization, both teams would set their default and backlog iterations to "Product Backlog." The clear naming will help them find their iterations.

The fact that it's harder to work with the sprints might be a clue that the teams should share an iteration cycle.

The Wrong Way

Some organizations (believe) they want all employees and teams to use the same process, and even share the same backlog and board. This can be done in Azure DevOps, but frankly I think it's anti-Agile, anti-productive, and there's plenty of evidence to back me up.

Really, don't do this. It encourages a top-down, tightly-coupled, bureaucratic culture.

If you're determined, here's how you might do it by taking advantage of the little-used (for good reason) Areas feature.

Using multiple Areas should be reserved for really complex projects

Remember, work items are assigned to an Area and Iteration. What we're doing here is inverting (and subverting) the Azure DevOps structure by turning Areas into Projects.

|_MRU Process [THE Monsters-R-Us Process]
  |_Monsters-R-Us Project [The ONLY project in the entire company]
    |_MRU Team [EVERYONE including vendors. Iterations defined here. Backlog/Board defined here]
      |_Area - MRU Website
        |_Work Item(s) [assigned to Area and Iteration]
      |_Area - MRU Mobile Applications
        |_Work Item(s)
      |_Area - MRU Developer Experience
        |_Work Item(s)
      |_Area - Internal DevOps Improvements
        |_Work Item(s)

What this allows:

• Any employee can be assigned work in any area
• All work items are in a single, monolithic backlog that can be filtered by area
• Single, monolithic board that can be filtered by area or person

I'm sure someone will say Tags can be used for categorization and filtering. That's true, but adds complication.

Wrap Up

Azure DevOps is a quite capable suite of features that will work for many types of organizations. Because of that, it can be challenging to understand how to configure well.

Hopefully, this helps you along toward your own success.

These are the commands I use on a daily basis. Hopefully this helps explain and put to rest the fear of rebase.

I have aliases for these that mostly came from Phil Haack.

The below commands assume your mainline branch is named 'main'. Adjust accordingly if it's called 'master,' 'trunk', etc.

# Start day getting latest
git checkout main
# Create a new branch
git checkout -b features/my-feature
# work for a half hour
git add -A
git commit -m "Did some work"
# push branch to remote in case I die
git push --set-upstream origin features/my-feature
# work another couple of hours, occasionally syncing to remote
# (one liner)
git add -A && git commit -m "Did some other work"
git push
# ready to submit PR. I want my code to be *after* the latest, so . . .
git checkout main
git pull [gets latest changes]
git checkout feature/my-feature
git rebase main
# deal with any merge conflicts, then squash and force push
git rebase main --interactive [I squash all commits into one]
git push --force
# I'm done. Create the pull request.

Q&A

Isn't rebase bad and you should never ever do it because everyone says so?

No. Rebase is good and you're listening to the wrong people. It's what significantly reduces merge conflicts in your pull requests. What's bad is not understanding what rebase does and what problems it could cause.

When rebasing onto main, you're saying, "If I merge my changes into main now, they'll be in the middle of what's already committed. I want them at the end. So take my changes and apply them to the end of main as if I just made them."

From Git's point of view, these are new commits, so they get new file hashes. That's why you have to force-push them, overwriting the remote branch.

This is OK as long as:

1. You do not ever rebase main onto a branch and then push main.
2. If someone else is working on your branch with you, you tell them to git pull --force.

The first one you should never, ever even think of doing. The second one is rare because developers tend to work indepedently on short-lived branches.

When it comes to merge vs rebase, the directions of change are always:

Merge from branch into main. Rebase branch onto main.

When you "merge from", you start in main. When you "rebase onto" you start in the branch.

What about merge conflicts?

That's a whole other topic. What matters is using a good diff/merge tool. The one I use, KDiff3, is really old but I like it best.