I am working in project which uses Bot Framework, and We are implementing DirectLine with websockets connection. For this, we are using Direct Line App Service extension. We are following these steps: https://learn.microsoft.com/en-us/azure/bot-service/bot-service-channel-directline-extension-net-bot?view=azure-bot-service-4.0.
When We publish the project from VS2022 on an Azure Windows App Service, it works correctly, but when we publish it on Linux, the route that finishes with "/.bot" returns 404 not found response.
We don't find anything about this problem on internet.
Do we need to configure anything else for it works on Linux App Service?
Linux App Services do not currently support extensions of any kind, so the Direct Line Extension is not currently supported on a Linux App Service. You can run the bot and use standard Direct Line on Linux, but if you require the network isolation offered by the extension, you will need to use the Windows App Service.
Related
We have set up an Azure Linux app service (API) and want to deploy two API projects (.Net Core) in the same app service. Is it possible in Linux based app service?
It's impossible.
You can refer to the answer in the post below.
Hosting Two Website Under one Web App - Azure Services
IIS can handler mappings and virtual applications and directories, you can't use virtual applications and directories in linux.
If you have more questions about azure web app, you can raise a support ticket on portal. You can also put forward your ideas and suggestions in the feedback, and optimize the product together with Microsoft official.
I'm trying to use jsreports.net (following this answer) to generate a pdf in an aspnet core application. Locally it runs fine but when I push it to an azure web app the app fails on start up. Does anyone know if this scenario is possible?
I reproduce your problem and it seems that jsreport uses headless chrome to print pdf. Unfortunately Azure Web Apps running on windows are very restrictive and doesn't allow running headless chrome process. In the other words jsreport.Local won't be able to print pdf in Azure Web Apps running on windows.
Fortunately, Azure Web Apps running in docker with Linux host are using different sandboxing strategy and headless chrome works there. If this is an option for you, enable Linux docker support in your Azure Web App and add to your Dockerfile lines from the docker chapter. Additionally you need to explicitly specify jsreport internal port, because of collision in the environment variables.
For more details, you could refer to this article.
App 1: I have a React app (based on create-react-app) which I've added as a Web App in Azure - that was pretty straight-forward to setup. This is using the JS SignalR client to communicate with the server, mentioned next.
App 2: This app is the ASP.NET Core SignalR Server application created with dotnet new console. This app exposes a SignalR endpoint and is "self hosted".
App 3: A 2nd ASP.NET Core console app is setup as a SignalR client. This is responsible to fetching some data, and sends those data to the SignalR server. This takes the SignalR endpoint (url) as a commandline argument.
Running all this locally is pretty straightforward:
App 1: npm start / serve -s build
App 2: dotnet run -commandline args (runs on localhost taking a hubpath and port from the args supplied. The port is so that multiple instances SignalR servers can run on localhost - not sure if this is the way to do it in Azure or if they're differentiated with separate urls and hosted seperately there)
App 3: dotnet run "http://localhost:5000/somenotificationhubname"
I've added a bat file in each of the console apps, so I can open multiple instances of those, with different args.
So locally it runs as easily as clicking 3 bat files.
But I'm kinda lost on how to host all this in Azure. The web app seemed pretty straightforward. I just created a web app in Azure, connected to it through an FTP client and copied over the contents of the build folder from the React app.
But what to do with the ASP.NET Core console applications so that the SignalR console app will be hosted in Azure and has its endpoint exposed for the other 2 apps to consume?
I tried adding both both App 2 and 3 as webjobs under App 1, but that didn't seem to work.
I've also heard that SignalR should not be running on IIS, so would it make sense to make it self-contained (exe) and run it inside a docker container? Any help is much appreciated.
I will suggest to change your app to use AppSettings file for configuration values instead of the commandline args.
You can easily change the value of appsettings without redeploying or changing anything.
You can have multiple appsettings file based on environments.
Allows you to easily duplicate the app with same code but different appsettings for your multiple signalr server.
This will make it easier to deploy using the standard publishing wizard in Visual Studio or via command line.
You could try the publish Profile in Azure App Service with the help of Visual Studio,
Reference 1
Reference 2
Once you successfully publish your webApp. You can double check the deployment using kudu service (or) App service editor
Advanced Tool-KUDU
AppService editor
I had a working Windows Azure Web Site running my node.js app and everything was working fine. I ended up needing to run a native node.js module (fibers), which necessitated that I move to a Windows Azure Cloud Service. I used the Convert to Azure Cloud Service wizard, which created a web role that allowed me to deploy my app as a cloud service and run fibers under node. So far so good.
My app requires WebSockets, which are supported under Azure Web Sites (more or less automagically when you turn it on from the config UX). I've been fighting to get WebSockets working with the Cloud Service for a few days now, and I have determined that my problem is that the version of iisnode that runs by default in a Cloud Service is too old to support node.js WebSockets in the normal way. The Cloud Service installs iisnode version 1.21 and the WebSockets support in iisnode didn't show up until version 2.0 (I have no idea why the Cloud Service image uses that crusty old version of iisnode).
Note that I don't want to use a worker role and listen on a different port (which I gather is how a lot of people address this).
Unfortunately, I cannot figure out how to install a more up to date version of iisnode in my Cloud Service (I gather that it's possible to run an installer at the startup of the Cloud Service (possibly via setup_web.cmd), but that's as far as I've gotten.
Any pointers on what I need to do to get my Azure Cloud Service running a newer version of iisnode?
To update the version of iisnode installed on Azure Hosted Service you need to:
Download the newest x64 installer for iisnode from http://go.microsoft.com/?linkid=9784331
Include that *.msi file in the package you are deploying to the Hosted Service.
In your setup_web.cmd, install the new iisnode with msiexec /i iisnode-full-iis7-v0.2.7-x64.msi /passive. This must be run as admin, but then I believe setup_web.cmd already runs as admin.
Alternativelty, for a one-off installation, you can just TS to the machine and install it manually.
By the way, what is preventing you from using the native module in Windows Azure Web Sites?
We are developing an application that we are deploying to Azure. It needs to work with a specific machine configuraiton. We we have this configured as a VM which developers can run locally.
However to test the VM configuration we need to publish to Azure and access it on a live Azure instance. Is there anyway to allow a local VM to get access to the Azure environment IIS on the developers machine? It doesn't seem to show up in IIS Express so I guess it isn't the same as a normal site?
Also is it possible to configure an Azure environment locally for testing. We want to host test applications for internal use and don't want them run on developers machines. We would like to run them on a server in the office.
Any ideas?
Thanks
I think that the answer to this question will outline the general guidelines you could follow to enable your environment.
Windows Azure Emulator has its own load balancer simulator which bind to socket 127.0.0.1:81 (most of the cases, if port 81 is free). If the Azure project is developed with Azure SDK 1.3 or later with Full IIS enabled, then the Azure Emulator (for versions 1.3 ~ 1.6) will use local IIS to host the sites. IIS Express is not involved in any way with the Azure project. If you happen to run IIS Express, then most probably you have set up your web application project as a StartUp project in the solution. The correct way to locally debug Windows Azure applications is to use the Cloud Project as a startup project.
Please kindly update your question, if there is some doubt or confusion after checking the mentioned related question.