ANCM In-Process Start Failure

Or, alternatively, Failed to launch debug adapter.

Blazor error

These were the two errors I was getting while playing with Blazor. They turn out to have the same cause, although the errors are not particularly indicative of the issue.

First, to get to the heart of the matter, the problem was that the server portion of the Blazor application had a runtime error. Turns out I had forgotten to include the reference to a class that was being injected into a server component. What slowed me down was that the messages were not overly precise about the source of the problem. 

But what might be more instructive is different ways the problem might be discovered. For my project, the server portion of the application was loaded into IIS Express. This was one of the reasons why I couldn't immediately see the problem. When the project is launched using the server application directly, a console window opens. In this window would be logging information, including, in this case, the runtime error saying that the server could not be started.

Armed with that information, I added logging to the server code. Now the actual problem was surfaced. I forgot to define the concrete object for one of my injected interfaces. My bad. And easy to fix, once you figure out the real problem.

Publishing TESTNG test results into Azure DevOps

At the moment, Azure DevOps supports the following results formats include CTest, JUnit (including PHPUnit), NUnit 2, NUnit 3, Visual Studio Test (TRX), and xUnit 2. Unfortunately, it does not support TESTNG test results format. The good news, however, is that TESTNG also produces JUnit test results in a separate junitreports folder. So, we can publish TESTNG test results in JUnit format instead.

To do that, just change Test results files field under JUnit Test Results section to **/junitreports/TEST-*.xml.

Show Team Profile

This week I am on the Microsoft Campus for the MVP Summit. Last night was Product Group Happy Hour, when we get to chat with the Product Teams and give feedback on the product. They are always so nice and eager to hear from us.

Last night I was talking to two people from the Azure Boards teams. I told them how much I like the new boards and I love the Show Team Profile feature. They were so excited about this, in their minds no one ever used this feature. This is a great navigational tool in Azure boards, and I promised to blog about it so others would know. 

When you are looking at anything to do with a team, Backlog, Board, Sprint there is an icon to the right of the team name. 

image


Clicking on this icon takes you to a pull out at the right of the browser with links to other areas of Azure Boards for this team. As you can see from the screen shot below I get quick navigation to Boards, Backlogs, the Current Sprint, Dashboards and even a list of team members.

image
























Also if you click on Team Settings it will take you to the Team configuration page under Project Settings.

image







Thanks Rebecca and Team!

How to Check Who are Global Admins in your Azure AD with PowerShell

You can use the following PowerShell snippet to quickly check who are the Global Administrators in your Azure AD:

$role = Get-AzureADDirectoryRole | Where-Object {$_.displayName -eq 'Company Administrator'}

Get-AzureADDirectoryRoleMember -ObjectId $role.ObjectId

That's it. It's that easy

Connect XAML Build Controller to Azure DevOps

Recently I've run into the situation where I needed to configure good old XAML build controller to connect to Azure DevOps, but my attempts kept failing. When I start the build service, first starts successfully and then stops with error TF300063. Every single time. Very annoying.

I have tried to troubleshoot the issue. Checked and double checked the permissions. Reset the client cache. Tried some other things, but nothing helped. Then, I've decided for the fun of it to try to connect XAML Build controller using old Azure DevOps/VSTS URL (orgname.visualstudio.com) instead of new Azure DevOps URL (dev.azure.com/orgname). And it worked! Hurray!

It appears that because XAML builds are soon to be deprecated feature, XAML build controller feature have not been updated to work with the new URL. They work just fine with the old URL though. So, until you migrate your XAML builds to new builds (and, you really should do that), you can keep using the old Azure DevOps/VSTS URL (orgname.visualstudio.com) to have your old XAML build controllers working with brand new Azure DevOps.

A supported task execution handler was not found

If you're getting "A supported task execution handler was not found. The task does not carry an implementation that is compatible with your current operating system 'Windows(X86)'. Contact the task author for more details." error in your build or release pipelines in Azure DevOps, then it's most likely because you have a 32 bit version of the agent installed on 64 bit operating system. When that happens Agent.OSArchitecture build variable is mistakenly set to 32 instead of 64. To fix this issue, just install 64 bit version of the agent instead. That should fix the issue.

Hope this helps.

Migrating from TFS to Azure DevOps from behind a corporate proxy

If you're behind a corporate proxy and trying to migrate TFS to Azure DevOps using tfsmigrator.exe command, then most likely your tfsmigrator prepare command might fail with "AAD Timeout Exception" exception. This error means that the requests to AAD to find the matching AAD identities for users in your collection timed out. TfsMIgrator troubleshooting guide has a number of solutions that you can try to mitigate the issue. Depending on your environment those solutions might not work. At the moment, another possible solution is missing from this troubleshooting guide. This is what this blog post is about.

Another reason for AAD Timeout Exception is that you're running behind a corporate proxy. If you are using an outbound proxy for connecting to the Internet, the following setting in the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config file must be added. This text must be entered at the bottom of the file. In this code, represents the actual proxy IP address or host name.

<system.net>

<defaultProxy>

<proxy

usesystemdefault="true"

proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"

bypassonlocal="true"

/>

</defaultProxy>

</system.net>

 

So, update your machine.config file, re-launch your command line and try tfsmigator prepare command one more time. It should work this time. Hope this helps.

Create Azure VM without a Public IP using Azure CLI

You really shouldn't create Azure virtual machines with public IP addresses unless you need it to communicate with outside world. Instead use VPN or ExpressRoute to connect to the virtual machine using private IP address. To create Azure VM without a public IP address using Azure CLI use the following command:

az vm create --resource-group TEST --name TESTVM --public-ip-address ""

Yes, just use empty quotes to create your VM without a public IP address. If you do not specify --public-ip-address option then Azure CLI will create a new public IP address and assign it to your VM.

Another gotcha is that the above-mentioned command only works if you run in in the command line or bash. If you're running your Azure CLI commands from within PowerShell, then you need to wrap empty quotes one more time. So the command will look as such:

az vm create --resource-group TEST --name TESTVM --public-ip-address '""'

Apparently, PowerShell swallows empty quotes and never passes them to Azure CLI command, so if you don't wrap the quotes again in PowerShell window, you will end up a virtual machine with a public IP address, which is frustrating.

Hope this helps.

P.S. : If you need your virtual machine to have a public IP address, please do not forget to secure that VM using network security group and such…

 

The Podcast

ObjectSharp started doing a podcast here is the first one.

The ObjectSharp Podcast: Episode 001

Cosmos DB: Everything you wanted to know about Microsoft Azure’s NoSQL Offering

Azure DevOps

VSTS gets a new look and name.

This morning Microsoft announced Azure DevOps, the next edition of VSTS. What’s different? It has a new look with better navigation. And you can pick and choose what parts you would like to use, getting the extra stuff you don’t use out of your way.

Select from

Azure PipelinesAzure pipelines – Previously Build & Release

Azure BoardsAzure Boards – Previously the Work hub (Backlogs and Boards)

Azure ArtifactsAzure Artifacts – Previously Packages (Nuget and NPM server)

Azure ReposAzure Repos – Git repos (TFVC is still supported too)

Azure Test PlansAzure Test Plans – Previously the Test hub (Test plans, Configurations etc)

Or use them all together for that wonderful integrated experience you only get from Azure DevOps.

Go hear for more explanation and a quick demo from Donovan Brown DevOps Manager