question

NeilMacMullen-1798 avatar image
0 Votes"
NeilMacMullen-1798 asked NeilMacMullen-1798 commented

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


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
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

vipullag-MSFT avatar image
1 Vote"
vipullag-MSFT answered NeilMacMullen-1798 commented

@NeilMacMullen-1798

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.

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@vipullag-MSFT Thanks for the answer - I really appreciate the information even if it's not what I wanted to hear!

I do hope the Azure team will reconsider the roadmap. From a user's perspective it appears that Microsoft just haven't thought through the .Net5 rollout with different teams adopting different policies on support and timelines. It's all very well to say that users should stick with 3.1 for existing services but that doesn't really work in a world where the service depends on code that has to use .Net5 to support features required by other clients.

0 Votes 0 ·

@NeilMacMullen-1798
I shared the feedback to the product team.
However, I would suggest to share the feedback here.


1 Vote 1 ·

That's a good suggestion - thanks !

0 Votes 0 ·