Deploying to Azure Web Service with Azure SQL db connection

Radzen Studio Angular
1

I would appreciate some help with my deployment to Azure Web Service.

I created a simple Radzen application that connects to my Azure SQL Database. It runs correctly in Radzen. But after I deploy to Azure web services I receive a 404 when the application attempts to retreive data.

I’m thinking I may be doing something wrong when I specify the Connection String in Azure Web Services.
Following the instructions for manual deploy and using the azure portal’s Application Settings, I created the following connection string.
Name: ConnectionStrings:TechneauxDbConnection
value: Server=XXXXXXXXX.database.windows.net;
Initial Catalog=TechneauxDb;Persist Security Info=False;
User ID=XXXXXXXXX;Password=XXXXXXXXX;MultipleActiveResultSets=False
;Encrypt=true;TrustServerCertificate=true;Connection Timeout=30

Your help is greatly appreciated.
michael

2

Hi @michael,

Getting 404 usually means that the Angular application is trying to get data from a URL which does not exist. You can check your browser’s developer tools and see what URL gives 404.

When deploying manually you will have to set the production service URLs. Did you perform that step? If not the application will try to get data from http://localhost:5000 by default which will return 404 when hosted on Azure.

By the way if you use FTP or ZIP deploy Radzen would do this automatically.

3

korchev,
thanks for the quick response.

the url seems correct

Request URL: https://xxxxxxxxx.azurewebsites.net/odata/TechneauxDb/BusinessUnits?$top=10&$skip=0&$count=true&$expand=Employee

I did use zip deploy.

I could not get ftp deploy to work.(times out when trying to upload. radzen: Error: Passive socket timeout)

I referenced the manual deploy documentation that indicated IIS requires a connection string to be created. So I assumed the same requirement for Azure web service.

any other ideas?

michael

4

Hi @michael,

The connection string should be stored in appsettings.json when you use deploy to zip. You can check if this is the case by unzipping the deploy.zip file.

Are all requests to https://xxxxxxxxx.azurewebsites.net/odata/TechneauxDb/ failing or just in one page? Can you provide the actual application URL over email at info@radzen.com so we can investigate further?

5

Hello @korchev ,

again, thanks for your help. I emailed the application URL as requested.

  • all pages fail to load data. same 404 error
  • the connection string in appsettings.json appears to be correct.

"ConnectionStrings":{"TechneauxDbConnection":"Server=xxxxxxxxxx.database.windows.net;Initial Catalog=TechneauxDb;Persist Security Info=False;User ID=xxxxxxxxxx;Password=xxxxxxxxxx;MultipleActiveResultSets=False;Encrypt=true;TrustServerCertificate=true;Connection Timeout=30"}}

please let me know if there is any other information required.

michael

6

@michael we haven’t got your email yet. Did you send it to info@radzen.com? Please try sending it again. It should take that long.

You can also provide it as a private message in the forum - click my avatar and then the Message button.

7

@korchev,

my mistake. I resent. let me know if you receive it.

thanks,
michael

8

I was able to successfully deploy to Azure Web Service.

I'm not certain I understand the reason for my issue. I will have to do more investigation.

  • I rebuilt the application on a new vm in the Azure cloud with dotnet version 2.1.403 (previously built on a workstation with dotnet version 2.1.2)
  • I used zip deploy and copied the contents to the folder /site/wwwroot of my Azure Web Service App

@korchev thanks for the help
michael

9

The issue was caused because you have deployed the application to /site. Azure requires the public site to be in /site/wwwroot. Radzen applications have a wwwroot directory that contain the client-side SPA application. Those two caused only the SPA application to be deployed - the server-side wasn't deployed hence the 404 errors.

When you deployed to /site/wwwroot both the server and client-side applications were running as expected.