I am trying to configure some key/value pairs for my Azure web application using app settings section on Windows Azure preview portal.
According to the documentation, Azure should inject configured key/value pairs into the .Net configuration AppSettings at runtime.
Do anybody know, how to read this values inside the RegisterServices method of the NinjectWebCommon class? I tried a common way
ConfigurationManager.AppSettings["MyWebApp.DbConnectionString"];
but it returns empty or null values. Reading app settings later in my web application works fine.
I do not know how exactly this works but the RegisterServices method is probably called earlier than Azure injects app settings into configuration. Fortunately, there is an alternative way to install Ninject for MVC3 that works (see Using Binaries from Github).
Related
I know that the Azure function supports HTTP trigger and we can write a function that can be exposed like an API. I'm looking for an option to host a complete C# WebAPI project (multiple Rest endpoints including swagger definition) into a single Azure function.
Is this feasible? and supported? I see this scenario is completely supported in AWS Lambda. Where we can deploy a whole WebAPI project into a single lambda. Here is the demo of
the same.
I have watched the provided Video and I observed the same functionality is also available in Azure Functions.
As Direct way is not available like publishing the Web API to the Functions but migration of Web API to Functions is possible if the Web API is authenticated with any option like Open API, etc and using the APIM Service we can manage all the operations in it.
And as per the Microsoft Update, Startup.csand program.cs is unified to the program.cs file. So, I have added the required swagger configuration code in the file program.cs and tested it, working successful locally.
Another approach is you can call the Web APIs from Azure Functions securely, here is one of my approaches along with few other ways to do it.
Refer to #VovaBilyachat alternative solution on publishing .NET Core Web API to Azure that provides the glimpse of using Containers instead Functions.
So, when I am trying to create a function inside a function app it shows Editing Java Function Apps is not supported in the Azure portal.
The Add button is not working and only local development option is present.
How can I overcome this problem?
Currently, it seems that we cannot create Java Function on Azure portal, because creating Java Function requires Maven or Gardle, but Azure portal does not seem to contain them.
So we can only develop Java Function locally and then deploy them to the Azure portal.
If you want to get this feature, you can go to the Feedback page to post your thoughts, and the Azure development team may adopt your suggestions.
By the way, not only Java, only script programming languages can be added to Azure Portal. In other words, Azure Portal can only create functions that use languages that do not require compilation
You might say that C# can be created directly on Azure portal, but the c# function created in Azure Portal is actually the c# script.
I'm searching for ways to modify and edit app settings for Azure function during runtime.
from the links below, I was able to find how to add bindings locally and add connection settings through azure portal or Azure Cli
https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local#local-settings-file
https://learn.microsoft.com/en-us/azure/azure-functions/functions-dotnet-class-library#environment-variables
However, I'm searching for ways to generate new connection setting variables as well as new bindings at runtime.
The use case would be, where we need to onboard users without manually interacting with the Azure function app configuration.
I also tried modifying it thorough an example given in below link:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp#environment-variables
I was able to modify the variable temporarily, but it appears that it loses the changes as soon as the run gets terminated (also, it didn't work when I published the app on Azure).
Is there way to accomplish this during runtime?
My set up is to have two azure functions:
1. dedicated to modifying app settings if change is detected in CosmosDB where new user information is added.
2. dedicated sending messages, but generating bindings based on app configurations added by azure function 1.
My initial thoughts were to store the whole app settings in cosmosDB and generate appsettings based on that document at every onetime, but I'm pretty sure there is better ways to do this.
also, it looks like my connection strings in local.settings.json don't get reflected when I actually publish them. what am I missing?
Thanks, in advance :)
What is the best way/recommended way to read settings from a worker/web role?
Is it:
CloudConfigurationManager.GetSetting("ConnectionString") (this I'm using)
or
RoleEnvironment.GetConfigurationSettingValue("ConnectionString")
Although both work fine ...
From the documentation for CloudConfigurationManager.GetSetting:
The GetSetting method reads the configuration setting value from the
appropriate configuration store. If the application is running as a
.NET Web application, the GetSetting method will return the setting
value from the Web.config or app.config file. If the application is
running in Windows Azure Cloud Service or in a Windows Azure Website,
the GetSetting will return the setting value from the
ServiceConfiguration.cscfg.
From above, it is clear that the function CloudConfigurationManager.GetSetting reads either from service configuration (ServiceConfiguration.cscfg) file or application configuration file (App.config/Web.config) depending on where the application is running.
RoleEnvironment.GetConfigurationSettingValue will only read from the service configuration file.
If your application component is used in both cloud and non-cloud applications, use CloudConfigurationManager.GetSetting so that you don't have to make any changes in the code. If your component would run only in the cloud, then I guess you could use either one.
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.