Publishing .NET Core Web App to Linux on Azure - azure

I'm trying to publish my .Net Core 2.2 Web app to a Linux environment.
I already created the Web App with a ServicePlan with Linux. I downloaded the publish profile and published it successfully.
I published it over FTP profile.
The problem is that when I access the web app address, it still shows the Azure Empty State web app:
Any ideas what I am missing?

I tried to repro your scenario and could see the same behavior.
There is a way one can configure Default documents for App Services, however, this is valid only for App Services on Windows and not Linux.
For Linux apps, the implementation would be based as per the runtime stack selected.
For .Net Core Razor pages specifically, the AddPageRoute() method can help in defining the route as described in this blog post:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc().AddRazorPagesOptions(options =>
{
//"/Home/welcome" is the page we want to land at
//The empty string signifies the root URL
options.Conventions.AddPageRoute("/Home/welcome", "");
});
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}
That said, this worked only when published locally but not when published to the Azure App Service for Linux, which is not what one would expect.
I will check this with our internal Teams and get back to you. Thanks for bringing this to our attention!
UPDATE:
You could configure the Startup Command for your App Service. For .Net Core, it would look something like dotnet <myapp>.dll. This should definitely work. You can configure this setting here:
Note that you might have to delete all existing files prior to publish (from your Publish profile > Settings > File Publish Options > enable "Delete all existing files prior to publish" > Save) to see your changes.
Hope this helps!

Related

First time Deployment of Blazor solution with many multiple projects

I am very new and have been exploring coding for quite a while, and I have finally completed a simple vs solution containing multiple projects.
Running the solution now in VS Studio (2019 community) will launch IIS and 4 localhost sites in the browser:
Data Controller (Asp.net api project with swagger)
File Controller (Asp.net api project with swagger)
Admin Portal (Blazor web assembly app project)
Public Portal (Blazor web assembly app project)
Note that the projects have no authentication yet...also I am using EF Core Code-First, and have no idea how to use the builder.HostEnvironment so I hardcoded the data and file Http base addresses in the program.cs Main() of the admin and public blazor projects (e.g. builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri("...") }); )
I'd like to try deploying this solution to the cloud (say for example azure) please help me learn how to deploy this! 🙏🙏🙏
You can use azure static web app , its free but you have to register your credit card anyway , you can follow this tutorial .
https://learn.microsoft.com/en-us/azure/static-web-apps/deploy-blazor
I deployed my first apps in azure by this way.

How does adding the Microsoft.ApplicationInsights NuGet for a .Net WebAPI project interfere with activating AI via the Azure Portal?

BASIC DESCRIPTION/CONFIGURATION:
We have a .Net Framework 4.6.1 (based upon ServiceStack) WebAPI hosted as Azure WebApp in the Cloud.
Each release-version of our API gets its own Application Insights telemetry endpoint, but we never activate Application Insights for our project in Visual Studio. Instead, after swapping a new releasable version from the staging to the production slot, we activate Application Insights via the Azure Portal, and by that we automatically receive all the request-telemetry that we need out of the box. In the configuration section of our WebApp I can see that some AI-specific Keys were added, most importantly the “APPINSIGHTS_INSTRUMENTATIONKEY”.
This used to work fine. Now I had to implement a feature to be able to send some custom information from our code to application insights.
Herefor I added the Microsoft.ApplicationInsights NuGet package (2.13.1) to our project. In our first scenario I send a custom exception via:
_telemetryClient.TrackException(…)
To test the new feature I created a Development Application Insights resource in the cloud and added the corresponding instrumentation key to our app.config. This works as expected and I can see the exception which I send here in the AI-Instance in the cloud.
NOW THE PROBLEM:
When I publish the app with the new feature to the staging slot in the cloud an then activate application insights via the portal, then I do not receive any standard request-telemetry data any more, only my custom exceptions.
1.) How is request data collected anyway when activating AI via the portal? I cannot find any dlls which would be added to our app hereby, so I suppose that the IIS-Server which hosts our web app collects and transmits the data?
2.) Does the server detect that there is a Microsoft.ApplicationInsights.dll in our code and by that stop collecting the request data because it expects that we handle this in our code ourselves?
The main reason why I do not want to simply activate the full-stack Application Insights feature for our project in Visual Studio is, that it installs a lot of dependencies which trigger DLL-Hell because we need some older versions for these dlls for other dependcies in our app (System.Net.Http for example)

Azure endpoint reached, but calls to API returning 404 error

We have set up an app service project in the Azure Portal and then went through deployment of the project using Visual Studio DevOps. When I go to http://MyAzureSite.azurewebsites.net (Made up URL here), I can confirm that the service is up and running.
But when I add "api/ControllerName/getStatus", I get a 404 error.
Call from my local machine is working perfectly fine.
http://localhost:52686/api/status/getStatus
But not:
http://MyAzureSite.azurewebsites.net/api/status/getstatus
Signature for the GetStatus looks good:
[HttpGet]
public List<Status> GetStatus()
We had the same exact problem with the most recent .NET Core 3.1 LTS release. We found multiple things that can cause this problem. Here are our findings:
API endpoints should extend ControllerBase instead of Controller:
ControllerBase creates a controller WITHOUT view support. Controller is for view support. We had an API endpoint that couldn't be reached when deployed in Azure if it was extending Controller and it didn't have a view. No errors or anything. Just couldn't reach it.
Make sure the App Service is configured for the correct stack. Our web API uses .NET Core 3.1. If you create it from Visual Studio, it may be configured for the incorrect stack. Our Visual Studio 2019 configured it for 3.0 EOL by default. When we changed it to 3.1, things worked again.
Creating from Azure Portal doesn't work with default configuration.
If you create the App Service / Web App through the Azure Portal, you won't be able to reach any of the endpoints at first. We are not sure why this is, but we figured out how to make it work again. Go to the configuration for the App Service and follow these steps:
Turn Off "Always On"
Save and wait for settings to apply
Turn On "Always On"
Save and wait for settings to apply
Now you should be able to hit your API endpoints again
These were a few problems that we had and the solutions to them. Hopefully, they help you guys out and save you from days of going "We fixed it!" just to have it stop working again for another unknown reason. I'll update this answer as I find more things that break APIs and App Services and as I find solutions to them.
We had to rebuild the project properly again, its the way project was created that was incorreect.

Mobile App backend does not show in existing Web Apps

I'm following the procedure to create a Xamarin app with a mobile app backend in Azure.
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-dotnet-backend-xamarin-android-get-started-preview/
I've create the mobile app in the portal and downloaded the backend runtime and xamarin solutions. When I try to publish the backend runtime, the instructions indicate that the one I just created should show up 'Existing Web Apps'. Mine shows nothing.
My questions are:
1) How can I troubleshoot what shows up in the 'Existing Web Apps'?
2) Is it reasonable to just create a new web app from the VS Publish dialog?
3) If not, where should I place the publish profile that I can download from the azure portal?
Regards,
Rajesh
1.a. Ensure you're using the right azure suscription from VS
1.b. Logout and add your subscription login again
Yes it's reasonable
You can put it wherever you want. From VS website project goto publish settings
4. Then select import
5.And Finally browse the publish settings file
I have had issues with Visual Studio finding the existing apps. I tend to download the publish settings and use that instead. This works fine.
Alternatively, create a git repository and check the code into the git repository. Check out this article for instructions: https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/
Personally, I post my code to a branch of my git repository on GitHub and link the continuous deployment option of the Azure App Service to that. You can find my blog about this topic here: http://shellmonger.com/2015/08/29/continuous-deployment-nodejs-and-microsoft-azure/ - it's for NodeJS but the concept and methodology is the same.

Moving Facebook C# SDK configuration settings to Azure ServiceConfiguration.cscfg

I'm using Facebook C# SDK for an ASP.NET MVC Facebook Canvas application that I'm hosting in Windows Azure.
I currently have the Facebook C# SDK specific configuration settings (appSecret, appId, etc.) in web.config, but I would like to move them to the service configuration file instead so that I can alter the settings when moving from Staging to Production in Azure.
(How) can this be done? Right now I'm using the CanvasAuthorize attribute that automatically reads from web.config.
[CanvasAuthorize(Permissions = FacebookPermissions.ReadStreamPermission)]
public ActionResult Login()
{
return RedirectToAction("Authenticate"); // Logged in, proceed with authentication
}
By default, Facebook C# SDK looks up at the configuration sections in web.config.
You will need to override the default Facebook application using code similar to this.
FacebookApplication.SetApplication(new DefaultFacebookApplication { AppId = "..", AppSecret = ".." });
The best place to set the application is at Application_Start.
You can checkout the sample at https://gist.github.com/820881
This means you are not tied to web.config. You can use database, azure service configuration or anything depending on your logic from where the settings can be retrieved.
I'm not sure about the reasoning of putting application specific configuration information in the Azure ServiceConfiguration.csfg file. Furthermore, I would say that this will be a problem rather than helpful to switch VIP's in the Azure control panel.
They way I do it is to have multiple web deployment configurations in my (ASP.NET MVC canvas page) Visual Studio project. One for Staging and one for Production.
I use the web.config transformation functionality in the Web Deployment to have different web.config settings for Staging/Production.
It works very well and smoothly, just right-click on the project, select Deploy and choose if you want to deploy to staging or production. You can also handle a specific testing AppID for Staging this way.
EDIT: I haven't looked in the source code for the Facebook C# SDK, but I would guess that the web.config read methods are, in fact, hard coded to use the web.config. That would also be a reason to keep it there.

Resources