robcaronUsed to work on Visual Studio, now on Azure.
Niner since 2004
US Navy nuke veteran (S1C/A4W/D2G). Visual Basic & ASP dev back in the day. Technical writer, developer marketing, etc. Now at Microsoft working on Azure, snowboarding Whistler or traveling when I'm not.
@Bazul - With an ASE there's no public endpoint. When using the hosted agent for Azure Pipelines, they're not placed in a VNet, so they can't communicate with a node inside ASE ("myappservice.scm.na.cloud.mycompany" won't resolve in the public internet).
Azure DevOps Portal can see the ASE only because Azure DevOps is communicating with the Azure Resource Manager APIs, which are confirming that the resource exists and are giving the endpoint. But the Azure Resource Manager APIs cannot allow deployments, which require a communication with Kudu running on the ASE nodes.
Hi Joel - I'm sorry you're not happy with the informality of Azure Friday. The format of the show is an engineer to engineer conversation, so we don't script the show and guest performance varies as people do. If you're having difficulty with sound level (not able to repro here) you can turn on captions, which also make the content accessible for many languages.
@Varghese Cherian: From the team: "For .NET back compatibility, there are 4 combinations for client-side SignalR applications to work with Azure SignalR Service (ASRS), which is ASP.NET core based. .NET web app + .NET SignalR SDK, requires a new version of .NET SDK to work with ASRS. The SDK is being worked right now with a high priority; .NET web app + .NET core SignalR SDK, as long as the SignalR related code can be separated from .NET based web app, this works right now; .NET core web app + .NET SignalR SDK, this won't be supported in near future; .NET core web app + .NET core SignalR SDK, this is recommended and is supported in production. For any customer that cannot migrate the web app to .NET core, the immediate solution is to separate the SignalR related logic and implement in .NET core, using .NET core SignalR SDK. If the user wants to wait a while, then there will be the new version of .NET SignalR SDK, to make it happen, but not 100% of APIs will be covered."
@alexmarshall132: From the team: "Yes, the use case scenario doesn't have to be customer-facing. The Azure SignalR Service implements REST APIs, so any backend service/application can post real-time messages to the service, then the service sends to receiving connections, either web browsers, or a backend ASP.NET apps. The SignalR client-side SDK currently provides JS (mainly for web) and C# (for .NET app). For other services or other languages, REST API or Azure Function binding can be used."