I'm trying to publish my ASP.NET Core application on Azure service. This works, but when I try to use the application functionality, I get the message
Your App Service app is up and running.
Moreover, in my wwwroot folder I don't have any .html files. I only have an Index.cshtml file, which is located in the Views/Home-folder in my application, all another files are .css, .js, etc.
When I run the application in Visual Studio in Debug mode, immediately opens the page in browser that was generated from Index.cshtml. But after the application is published in Azure, this does not happen.
What can I do to make Azure see Index.cshtml?
AFAIK, a default route would be added to Configure method of your Startup.cs file as follows:
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
I also created my .Net Core 2.0 MVC application to check this issue, it could work as expected on local side and my azure web app.
Moreover, in my wwwroot folder I don't have any .html files.
Views under Web Application and Web Apllication MVC would be compiled into {your-webapplication-assemblyname}.PrecompiledViews.dll, you could leverage ILSpy to check your DLLs.
For your issue, I would recommend you clear the web content in your web app via KUDU, or modify the publish settings and choose Remove additional files at destination under File Publish Options, then redeploy your application to Azure Web App to narrow this issue.
Are you finding index.cshtml in your web package? In case if you get index.cshtml in your final web package, you may need to add index.cshtml file type to the following in..
..YourAzureWebApp --> Application Settings --> Default Documents
I found out what the problem was. There are two types of applications, as presented below in the picture: Web Application and Web Apllication MVC. I worked with the second type of application. When I selected the first type and published the application, Azure immediately found the required index.html. I just had to choose Web Application.
But why does not it work with the second type of application (Web Apllication MVC)? I still do not know the answer to this question.
2 cents from my side as I just stuck for a while with this.
The problem was that yesterday I'd been playing around with deploying to Ubunut / Ngnix and today I decided to try Azure.
BUT I forgot to comment (disable) the following lines in my Startup:
//for nginx server
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
and that costed me almost half of the day to find the issue.
I also put the routing in the following way
app.UseStatusCodePages();
app.UseAuthentication();
app.UseMvc(routes => {
routes.MapRoute(
name: "default",
template: "{controller=Pages}/{action=Index}");
});
Now looks like it works on Azure :)
Related
It seems every time I try and deploy a plugin to Umbraco 9 on Azure App Service I seem to end up with an Angular error where the plugin's controllers don't get registered something like this
Error: [$controller:ctrlreg] http://errors.angularjs.org/1.8.0/$controller/ctrlreg?p0=Our.Iconic.Prevalues.Packages
at umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:32:168
at umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:123:19
at ea (umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:105:20)
at p (umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:96:476)
at g (umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:90:292)
at umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:89:422
at Object.link (umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:326:432)
at umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:42:134
at Ca (umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:114:361)
at p (umbraco-backoffice-js.js.vd671f7279661e0e87e3549a36c6c11bb1054da05:98:340) '<div ng-include="propertyEditorView">'
When you click on that angular link it just says
The controller with the name 'Our.Iconic.Prevalues.Packages' is not registered.
Everything works perfectly fine on my local environment and when I connect to the Azure App Service all the files are there in the App_Plugins... folder. It even loads some of the other files in the manifest but for some reason the controllers don't get registered. This is not the first plugin where this has happened either. Last time I manually deleted / copied files / redeployed / restarted / stood on one foot and eventually it started working. No idea what fixed it. Now next package added same thing happens again. What am I missing?
Had the same issue and got it to work with the solution provided here:
https://our.umbraco.com/forum/umbraco-9/107740-umbraco-9-cant-register-controller-for-a-custom-dashboard-that-works-locally-but-fails-when-deploy
Just want to add that this section should be added in Umbraco > CMS section of appsettings like so:
"Umbraco": {
"CMS": {
"RuntimeMinification": {
"useInMemoryCache": true,
"cacheBuster": "Timestamp"
}
}
}
I created a simple Blazor WASM webapp using C# .NET5. It connects to some Functions which in turn get some data from a SQL Server database.
I followed the tutorial of BlazorTrain: https://www.youtube.com/watch?v=5QctDo9MWps
Locally using Azurite to emulate the Azure stuff it all works fine.
But after deployment using GitHub Action the webapp starts but then it needs to get some data using the Functions and that fails. Running the Function in Postman results in a 503: Function host is not running.
I'm not sure what I need to configure more. I can't find the logging from Functions. I use the injected ILog, but can find the log messages in Azure Portal.
In Azure portal I see my 3 GET functions, but no option to test or see the logging.
With the help of #Aravid I found my problem.
Because I locally needed to tell my client the URL of the API I added a configuration in Client\wwwroot\appsettings.Development.json.
Of course this file doesn't get deployed.
After changing my code in Program.cs to:
var apiAddress = builder.Configuration["ApiAddress"] ?? $"{builder.HostEnvironment.BaseAddress}/api/";
builder.Services.AddHttpClient("Api",(options) => {
options.BaseAddress = new Uri(apiAddress);
});
My client works again.
I also added my SqlServer connection string in the Application Settings of my Static Web App and the functions are working as well.
I hope somebody else will benefit from this. Took me several hours to figure it out ;)
I have a Core WebJob deployed into an Azure Web App. I'm using WebJobs version 3.0.6.
I've noticed that changes to Connection Strings and App Settings (added via the Azure web UI) are not being picked up immediately by the WebJob code.
This seems to correlate with the same Connection Strings and App Settings not being displayed on the app's KUDU env page straight away (although I acknowledge this may be a red herring and could be some KUDU caching thing which I'm unaware of).
I've deployed a few non-Core WebJobs in the past and have not come across this issue so wonder if it's Core related? Although I can't see how that might affect configs showing up KUDU though.
I was having this issue the other day (where the configs were not getting picked up by the WebJob or shown in KUDU) and was getting nowhere, so left it. When I checked back the following day, the configs were now correctly showing in KUDU and being picked up by the WebJob. So I'd like to know what has happened in the meantime which means the configs are now being picked up as expected.
I've tried re-starting the WebJob and re-starting the app after making config changes but neither seem to have an effect.
It's worth also noting that I'm not loading appSettings.json during the program setup. That being said, the connection string being loaded was consistenly the connection string from that file i.e. my local machine SQL Server/DB. My understanding was always that the anything in the Azure web UI would override any equivalent settings from config files. This post from David Ebbo indicates that by calling AddEnvironmentVariables() during the setup will cause the Azure configs to be observed, but that doesn't seem to be the case here. Has this changed or is it loading the configs from this file by convention because it can't see the stuff from Azure?
Here's my WebJob Program code:
public static void Main(string[] args)
{
var host = new HostBuilder()
.ConfigureHostConfiguration(config =>
{
config.AddEnvironmentVariables();
})
.ConfigureWebJobs(webJobConfiguration =>
{
webJobConfiguration.AddTimers();
webJobConfiguration.AddAzureStorageCoreServices();
}
)
.ConfigureServices((context, services) =>
{
var connectionString = context.Configuration.GetConnectionString("MyConnectionStringKey");
services.AddDbContext<DatabaseContext>(options =>
options
.UseLazyLoadingProxies()
.UseSqlServer(connectionString)
);
// Add other services
})
.Build();
using(host)
{
host.Run();
}
}
So my questions are:
How quickly should configs added/updated via the Azure web UI be displayed in KUDU?
Is the fact they're not showing in KUDU related to my Core WebJob also not seeing the updated configs?
Is appSettings.json getting loaded even though I'm not calling .AddJsonFile("appSettings.json")?
What can I do to force the new configs added via Azure to be available to my WebJob immediately?
The order in which configuration sources are specified is important, as this establishes the precedence with which settings will be applied if they exist in multiple locations. In the example below, if the same setting exists in both appsettings.json and in an environment variable, the setting from the environment variable will be the one that is used. The last configuration source specified “wins” if a setting exists in more than one location. The ASP.NET team recommends specifying environment variables last, so that the environment where your app is running can override anything set in deployed configuration files.
You can refer here for more details on Azure App Services Application Settings and Connection Strings in ASP.NET Core
NopCommerce version: 3.9
I've designed a web store using NopCommerce 3.9. Any code I added is in a plugin.
The store uses a front page that can be found in the plugin. It relies on a route called 'home' in a RouteProvider class in the plugin. It does not complain about that route, instead it complains about a route named 'RegisterVendor' found in the same file. Here are both routes
routes.MapRoute("home",
"",
new { controller = "AoiVendorsHome", action = "Index" },
new[] { "Nop.Plugin.Other.AoiVendors.Controllers" });
routes.MapRoute("RegisterVendor",
"register/designer",
new { controller = "AoiExchange", action = "RegisterVendor" },
new[] { "Nop.Plugin.Other.AoiVendors.Controllers" });
The plugin installs properly and everything works exactly as expected on my local machine.
The problem is after deploying to the web it can't find the route. Here is a imgur link, follow it to see the error
Restarting the server fixes the error for a while, but it does eventually come back. It also comes back any time I redeploy without restarting the server afterwards.
Does anyone have any ideas?
Thank You.
The "HomePage" route of nopCommerce is registred this way
//home page
routes.MapLocalizedRoute("HomePage",
"",
new { controller = "Home", action = "Index" },
new[] { "Nop.Web.Controllers" });
Check your load order: If your registration does not hit first, remove nopCommerce "HomePage" route and add yours or add yours first using the Priority property of IRouteProvider.
MVC uses the route that first matches the request.
Regarding the deployment problem, make sure your plugin is deployed to ~/Plugins/{yourPluginFolder} and not the bin folder of Nop.Web. Plugin in ~/bin folder can be loaded but without guarantee.
I was able to fix the issue by selecting the 'Remove additional files at destination' checkbox under file publish options on the settings tab in the publish popup dialog in visual studio. I imagine an older file was not being overwritten and was causing problems.
Here's what I'm doing.
Install latest Azure SDK (by the date)
Open Visual Studio 2013
Create a new Azure Mobile App project. The simple service is created with TodoItem DataObject and 2 simple controllers - TodoItemController and ValuesController
Do not change anything
Start the project
The service is started and hosted in local IISExpress on url http://localhost:50993/ (the port may vary).
The "This mobile app is up and running" web page is opened in the browser. But http 400 error is returned when I try to invoke some GET-actions: for example http://localhost:50993/api/values or http://localhost:50993/tables/TodoItem.
Any ideas? Is something wrong in my environment or is that me doing something wrong?
Thanks.
I guess you can opt out of version checking by setting a value of true for the app setting MS_SkipVersionCheck. Specify this either in your web.config or in the Application Settings section of the Azure Portal.
This generally happens when you don't add a ZUMO-API-VERSION header to the request. This is required when making requests from a REST client, but the mobile client SDKs add the header automatically.
To fix, add the header ZUMO-API-VERSION with value of 2.0.0.
To learn more, see https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-client-and-server-versioning/.
Adding
http://localhost:50993/tables/Location?ZUMO-API-VERSION=2.0.0
at the end will do the trick.