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 ;)
Related
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
I have been trying out the AADv2 sample from BotAuth to no avail.
The error that I keep getting after I select the button on the action card is that either a HTTP 500 internal server error, or Cannot GET /botauth/aadv2. When I check if the root web page or the messaging endpoint is working or not, I get the same error - either Cannot GET / or Cannot GET \api\messages. The root page I have been trying to get to is https://(botname).azurewebsites.net
May I know what steps I can take to resolve this issue? I have tried to Google the error, but to no avail. Please let me know if you need more information!
Since you are test the sample directly on Azure Web Apps, there should be a few of questions we should pay attention on.
1, const MICROSOFT_APP_ID = envx("MICROSOFT_APP_ID");
const MICROSOFT_APP_PASSWORD = envx("MICROSOFT_APP_PASSWORD");
we declare the environment valiable as MicrosoftAppId and MicrosoftAppPassword. Please modify this sentence as
//bot application identity
const MICROSOFT_APP_ID = envx("MicrosoftAppId");
const MICROSOFT_APP_PASSWORD = envx("MicrosoftAppPassword");
2, And you also need to check the environment variables are set correctly in Application settings of Azure Web App, which is shown at https://github.com/MicrosoftDX/botauth/tree/master/Node/examples/aadv2#3-setup-environment-variables
3, You can leverage online code editor to develop, debug, and manage your project on Azure Web Apps.
And in the output column, you can see the detailed errors throwm by the application. You can leverage these info to narrow down your issue.
Tips, after you changing the application settings, it's better to restart your Azure Web App.
I've just started a PoC on service fabric for a project and I'm stuck on something that should have been straightforward but has become a real pain ...
What I need to do is host a console app returning some values in the service fabric and be able to call it on demand and get back its return value.
So I've created a simple exe looking like this, hosted in a GuestExe
static void Main(string[] args)
{
Console.WriteLine("123");
File.AppendAllText("hello.txt" + DateTime.Now.ToString(), "Hello world!");
//Console.ReadLine();
}
First, if the readline is commented, the explorer shows the guestExe as failing and the file is not created.
If I uncomment it, the guest exe will appear as being good in the explorer, and the console app will be started on it's own (despite I didn't ask for it), the file will be created, and I won't be able to call it.
cluster image
I've tried to just hit few things in my browser : the endpoint above, http://localhost:19081/PoC9/GuestExe?cmd=instance and same without the cmd argument.
If anyone has any idea of how that should be done, please help :)
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.
After upgrading to ServiceStack to 4.0.24.0, I started receiving this below error when trying to login using Google OAuth.
The same works locally on my dev machine.
Has anything changed since the 4.0.21.0?
The site is hosted on Azure as you can see from the address bar.
I've the licensed version of SS
Google OAuth Callback url is correctly registered http://somesite.azurewebsites.net/auth/GoogleOAuth
Using ServiceStack.Authentication.OAuth2 4.0.24.0
This is a pretty strange problem, but recently did some digging and here is what I found. It seems that Azure Websites doesn't like the HttpResult returning from the method Authenticate on the OAuth2Provider.
Important to note: This problem is only present when hosted on Azure Websites. ServiceStack OAuth2Providers (4.0.24 to 4.0.40) work as expected when hosted else where.
Specifically, it doesn't like the Content-Length header being set when returning a HttpResult. I'm not sure exactly why this is the case as it works locally and when deployed to my own IIS host on AWS.
I've created a repository you can deploy yourself that highlights this issue.
Azure Websites seem to be interpreting this response differently than on a standard IIS setup (eg, installed via Web Installer on a clean VM) which seems to be causing the problem.
One (not very nice) work around would be to use a GlobalResponseFilter stripping out Content-Length header of the only the GoogleOAuth2Provider response.
I've tested this out and indeed worked as expected and I was able to login using Google OAuth. Here is an example of using a GlobalResponseFilter to work around this problem.
GlobalResponseFilters.Add((req, res, dto) =>
{
if (!req.PathInfo.EndsWith("/auth/GoogleOAuth", true, CultureInfo.InvariantCulture))
{
return;
}
HttpResult httpResult = dto as HttpResult;
if (httpResult != null && httpResult.Headers.ContainsKey("Content-Length"))
{
httpResult.Headers.Remove("Content-Length");
}
});
Would be great if someone can point out why Azure websites does this.
Hope this helps.