Application Insights requires empty appsettings.json - azure-application-insights

I've made a new .NET 6 MVC application, installed 'Microsoft.ApplicationInsights.AspNetCore' and added builder.Services.AddApplicationInsightsTelemetry(); to Program.cs
Without an appsettings.json file no application insights information is logged, if I add an empty appsettings.json file logs do appear.
This seems an odd (undocumented?) requirement, is there something simple that I'm missing to avoid this?
We are handling config for app insights elsewhere and don't want to have to add an empty settings file just for this.

Thank you #Tiny Wang for your suggestion that helped lot.
The Application insights SDK for AspNetCore package Microsoft.ApplicationInsights.AspNetCore Package required the appsettings.json file.
When you inject your application insights to your ASP .NET core application the service.AddApplicationInsightsTelemetry() requires the appsettings.json file. The Application starts when the configuration values can be read from appsettings.json file.
Refer here for more information

its better to add the "APPLICATIONINSIGHTS_CONNECTION_STRING" key value pair in your Secrets.json instead of appsettings.json. secrets.json is local to your pc and will not be pushed to github or any scm.
The services.AddApplicationInsightsTelemetry(); will look for the key APPLICATIONINSIGHTS_CONNECTION_STRING at runtime in your configurations
read more about Secrets.json at https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows

Related

ASP core config files

In ASP framework I can add
<connectionStrings configSource="ConnectStrings.secrets.config" />
to the Web.config file and have a local development database ConnectStrings.secrets.config file which is in the root folder of the project but not included in the solution, and a deployed ConnectStrings.secrets.config file with my live database details.
Its a great fail safe to only develop with the dev database and publish to staging and live environments without cross pollination.
I don't want to setup predicates etc, so wont use appsettings.development.json etc. Is there a way of working with ASP Core and its appsettings.json file to refer to a separate file as above.
I'm not aware of any binding redirects in the json config of ASP core.
Generally the way we handle something like this (which is not quite as great but helps solve the whoopsies) is to validate config on startup. Inside of each config file such as appSettings.development.json we have the following key
Environment: "Development"
If the environment variable ASPNETCORE_ENVIRONMENT is a mismatch, prevent app from starting.

How can I change a setting in appsettings.json after auto-deploy?

I have an ASP.NET Core application going on an have setup Github auto-deploy on it. But since it's an open repo I obviously don't want to upload my correct configuration file.
What I'd like to do is to replace some strings in the appsettings.json after a github auto deploy.
"AppSettings": {
"Token": "my super duper secret token"
}
How can I change my super duper secret token to my real token after a github deploy on Azure?
As I know we can config token in App Settings on the Azure port.
I do a test on this, it works successfully, the following is my detail steps.
Create an Asp.net core Application.
Add [AppSettings] section in the appsetting.json file (Token vaule: mysecretkey).
Add a public class AppSettings.cs under the created project.
Add the code services.Configure<AppSettings>(Configuration.GetSection("AppSettings")) in the function ConfigureService function in the Startup.cs file (For .net Core 1.0).
Note:The syntax for model binding has changed from RC1 to RC2. Using services.Configure<AppSettings>(Configuration.GetSection("AppSettings")), is no longer availableIn order to bind a settings class to your configuration you need to configure this in the ConfigureServices method of Startup.cs:
services.Configure<AppSettings>(options => Configuration.GetSection("AppSettings").Bind(options));
5. Add code to the HomeController.cs file.
Publish the WebApp to the Azure Portal.
Add [AppSettings: Token] in the Azure Portal.
Browse the WebApp and select the about tab to see the token value is that the value set in the portal.
Assuming the web site already exists as a resource in Azure, you can simply set the App Settings/Connection strings in the portal. These will override the ones in the appsettings.json file at runtime. Ie. your app will first look at the azure app settings/connection strings before looking for them in the local file. This is part of asp.net core's "cloud first" approach to configuration management. These settings wont get overwritten when you deploy code to the app/slot.
Found a blog post here which describes it in a bit more detail, using the .AddEnvironmentVariables() call to add azure slot settings to the configuration.
There is a code editing functionality in developer tools settings (Settings -> Development Tools -> App Service Editor (Preview)). You can go there and change any file you like in there. But you probably will need to restart the web application (by editing web.config or some other way).. You can also use Kudu (Advanced Tools) for that, but it's not as pleasant UI as Visual Studio Code in the first option.
Though the more advanced and correct way of dealing with application secrets is the special secret manager. You can read more about it on asp.net documentation here.
Generally it's a way to load the secrets from a protected data storage and override them with environmental variables in production (can be set in azure web app).
If you are using Azure DevOps Release to deploy, you can easily specify properties for each environment/stage.
You can use the task File Transform and indicate the path to appsettings.json:
Or if you are deploying directly to Azure:
So you just need to create the variables to override the data in the settings:

Where is my app.config file?

I have built a server api that consists aith 3 projects:
Api(an api project) that calles BL(class library) that calls Dal(class library).
Very standard.
It works perfectly locally.
Now when I publish it, the app.config of the BL disappears.
Why is it? Where can I store my configurable parameters?
Thank you very much. Tal
On your main project ASP.NET, use the Web.Config instead of App.Config to make it work.
app.config is only the name during development, once the project is built the app.config is copied to .config and this is what is used by the application when running
An asp.net application reads config from web.config so if you have an app.config it implies that your project is not a web project but a standard library or executable.
if it is a library (.dll) then you should place your config in the web.config (if the library is used by asp.net) or in the .config if its a standard executable.
Ideally your libraries should not read settings as this creates a hidden coupling between the library and config files, and it would be better to provide those configuration parameters to the classes that need them in the library externally, this then leaves the application using the library free to store them where ever is most appropriate.
How is the consumer of your library going to know that they need to add SettingX to the appsettings of their configuration file? Better for the library to require the setting value directly. So if your DAL needs a connection string then the class which wants a connection string should ask for it in their constructor. Then the application using it can get it from settings (or whereever) and pass it to the library., and the consumers have visibility of the dependency on the connection string. If the library reads it from config the consumer has no way to know that this is something they need add to the settings
So in a web app the startup would read the settings from web.config and pass them to your library but some other app using the same library could store them in a database if they wanted.

Adding web service reference to ASP.NET Website?

I want to add a service reference to a wsdl web service in my ASP.NET website. In Visual Studio I right clicked the project and then Add service reference. It then created the *App_WebReferences* folder with some files in it and it added some new things to my web.config.
After I moved the changes to my test server by copying the new file, the App_WebReferences folder and the changed web.config, the server tells me that I'm missing a reference for the web service. I thought it should be in either web.config or that ASP.NET should find it in the App_WebReferences folder.
I've missed something obvious but I can't figure out what. What have I missed and what do I do to get my web service reference to work on my test server?
It's working really well on my local machine.
Was this working fine locally? You need to make sure you import the service to any classes that may be using it (or Using if you are doing this in C#). Also, is the service you imported from a project that is on your pc? IF so, you will need publish that as well to the test server.

ASP.NET solution with class library project

I have an solution in VS 2008 which contains two class library projects and an ASP.NET web site. The ASP.NET site references the class libraries and one of the libraries contains a LINQ To SQL item.
My question is with regards to the app.config in the class library which contains the connection string for the database. When I build the project, this app.config isn't within the build directory and this means I can't dynamically change the connection string for the deployed project.
What am I doing wrong here, how can I have these settings deployed too so I can make changes to the connection string?
Thanks in advance,
Martin.
This caused me a bit of confusion at first as well.
You might think that the class library uses the app.config file that's contained in it's own project but it doesn't. It uses the config file of the project that is referencing it.
So what you need to do is look for the <appSettings/> tag inside the web.config file of your ASP.Net project and change it to <appSettings></appSettings> And add the <add ... /> tags that are contained in the app.config file of the library project. You don't need to change anything in your code for the ConfigurationManager class to figure this out. It knows where to look automagically.
Hope that makes sense.
You can edit the Web.config file in the final product. Configuration APIs normally will get configuration data from the primary configuration file of the application which, in case of ASP.NET apps is the Web.config and for client applications is Myfile.exe.config. It's important to know that class libraries in the project usually will not have their separate configuration file like MyClassLib.dll.config (unless you manually refer to the specific file).
To overcome the problem of connection string, here is the trick
Inside ur class library declare module that has got two properties, one is a setter and the other is a getter, and make them public.
Inside ur website project, go to the global file, and under both session start and application start call the setter property that u declared previously, and assign it the connection string that is located in ur web.config, now the connection string will be available in the website general scope and the value exists as long as ur session credential not expired.
Copy the connectionString section from your library's app.config file to your web.config file. Change the actual connection string from your development to your production server as necessary. The ConfigurationManager class that LINQ2SQL uses to obtain the connection string will look in the web.config file for the appropriately named connection string and use it if it exists.
If you want to have different settings for development vs production, use the Web Deployment Project. Download here. From Microsoft's description:
Visual Studio 2008 Web Deployment
Projects provide additional
functionality to build and deploy Web
sites and Web applications in Visual
Studio 2008. This add-in provides a
comprehensive UI to manage build
configurations, merging, and using
pre-build and post-build tasks with
MSBuild.

Resources