Migrating 'Classic' worker role to .net 5 - have I painted myself into a corner?

Neil MacMullen 26 Reputation points
2021-03-29T14:09:35.433+00:00

A few years ago we deployed a "Classic" worker role to service requests from a fleet of IoT devices. The worker runs a TCP server and clients connect to the Azure-assigned domain name (ourservice.cloudapp.net) on a specified port.

We're now trying to migrate the codebase to .Net5 and I've realised we may be bit stuck....

Cloud Services (both "classic" and "extended support") don't appear to support .Net5 - it's not clear whether they ever will (maybe someone here knows?). Similarly for Azure Service Fabric.

The temptation is therefore to move to a VM or some other Azure service (TBD) that can host a .Net5 TCP listener.

However, since we have several tens of K of deployed devices using the domain name*, there's an obvious question of whether it's possible to reassign the name (owned by Microsoft) to a new service. I'm guessing we might be able to reuse it for another "Cloud Service" (perhaps even an "extended support" one), but less likely that we can point it to a service of a different Azure type.

The best outcome for us is probably to find a way to upgrade the existing worker to .Net5 'in place' (when .Net Core 3.1 came out we were able to do this with an extra deployment step IIRC) but I'm open to suggestions!

  • we can fix this with a firmware upgrade but clearly a last resort with this many devices.
Azure Cloud Services
Azure Cloud Services
An Azure platform as a service offer that is used to deploy web and cloud applications.
637 questions
0 comments No comments
{count} votes

Accepted answer
  1. vipullag-MSFT 24,111 Reputation points Microsoft Employee
    2021-03-30T11:35:48.227+00:00

    @Neil MacMullen

    Thank you for reaching out to us. Happy to help. I reached to internal team to check and confirm on your ask. Here are the details:

    possible to reassign the name (owned by Microsoft) to a new service
    This isn’t possible unless you migrate your existing cloud services (classic) to extended support using In-Place migration path. Only then we enable users to retain their DNS FQDNs assigned to the IP endpoint on the cloud service.

    For your question on .net5 support, we are not enabling any new capabilities with extended support. Given this isn’t supported on classic today, and as of now this is not on the extended support roadmap either.

    Hope this helps.

    Please 'Accept as answer' if the provided information is helpful, so that it can help others in the community looking for help on similar topics.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful