.NET core 3.1 ApplicationInsight IntrumentKey null - asp.net-core

In .net core 3.1 Blazor App, my Instrument Key is always null.
I added the follwing package
Microsoft.ApplicationInsights.AspNetCore 2.14.0-beta5
in startup.cs, i am adding the following line
services.AddApplicationInsightsTelemetry();
i even tried hardcoding the instrument key via options but no luck there either.
Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions aiOptions
= new Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions();
aiOptions.InstrumentationKey = Configuration.GetSection("ApplicationInsights:InstrumentationKey").Value;
services.AddApplicationInsightsTelemetry(options);
in appsetting.json, i have defined the applicaiton Insight
"ApplicationInsights": {
"InstrumentationKey": "XXXXXXX-4f59-4580-a96a-XXXXXXX"
}
In my Blazor Page i am inject the dependency
#inject Microsoft.ApplicationInsights.TelemetryClient telemetryClient;
now when i search for telemetryClient.InstrumentationKey it is empty.
What am i missing ?

It's weird. I tried to view the key by calling telemetryClient.InstrumentationKey as well, but like you said it's empty. But when I try to track something with .TrackEvent, it logs.
For example;
_telemetryClient.TrackEvent("BlazorAppSampleEvent", new Dictionary<string, string>() { { "Hello from", "Blazor App" } });
Sounds interesting to me, I will have a couple of minutes more and update here if I get something new.
BTW, just so you know, Microsoft.ApplicationInsights.AspNetCore 2.14.0 is publicly available, so you can upgrade it from beta-5 to public one.
https://www.nuget.org/packages/Microsoft.ApplicationInsights.AspNetCore/2.14.0/

This is an old issue.
TelemetryClient.InstrumentationKey or TelemetryClient.Context.InstrumentationKey should be empty unless you explicitly set it there as an override of what is in configuration.
As mentioned above, explicitly set it like: TelemetryClient client = new TelemetryClient() { InstrumentationKey= "your_ikey" };, then you can see the key via TelemetryClient.InstrumentationKey or TelemetryClient.Context.InstrumentationKey.
Note: this issue does not break the functionality of application insights.

Related

Telerik Reporting .NET 5 walkthrough yields error "ConfigurationHelper does not exist in current context"

Following the 'How to Host Reports Service in ASP.NET Core in .NET 5' walk through here and early on they have you paste the following in ConfigureSerivces:
// Configure dependencies for ReportsController.
services.TryAddSingleton<IReportServiceConfiguration>(sp =>
new ReportServiceConfiguration
{
ReportingEngineConfiguration = ConfigurationHelper.ResolveConfiguration(sp.GetService<IWebHostEnvironment>()),
HostAppId = "Net5RestServiceWithCors",
Storage = new FileStorage(),
ReportSourceResolver = new UriReportSourceResolver(
System.IO.Path.Combine(sp.GetService<IWebHostEnvironment>().ContentRootPath, "Reports"))
});
However ConfigurationHelper is flagged as 'does not exist in current context'.
I know I probably need to reference an assembly but I did add all the supposed required dependencies via nuget Telerik.Reporting.Services.AspNetCore.Trial.
So I don't know what assembly I need to get ConfigurationHelper.
I suspect this is a really stupid question because there is virtually nothing on the internet about ConfigurationHelper which means the answer is so simple people don't even need to google it.
So what do I need to add to a brand new ASP.NET Core Web Application 5.0 with nuget Telerik.Reporting.Services.AspNetCore.Trial in order to resolve ConfigurationHelper?
ConfigurationHelper is just a static class in your project, you can rename it if you want, then use it in this line ReportingEngineConfiguration = ConfigurationHelper.ResolveConfiguration(sp.GetService<IWebHostEnvironment>()),
Taken from the article you have posted:
static class ConfigurationHelper
{
public static IConfiguration ResolveConfiguration(IWebHostEnvironment environment)
{
var reportingConfigFileName = System.IO.Path.Combine(environment.ContentRootPath, "appsettings.json");
return new ConfigurationBuilder()
.AddJsonFile(reportingConfigFileName, true)
.Build();
}
}
You can have a look at the demo projects in your installation, the path should be similar to C:\Program Files (x86)\Progress\Telerik Reporting R2 2022\Examples\CSharp.NET 5\ReportingRestServiceCorsDemo

What is causing the error that swagger is already in the route collection for Web API 2?

I installed Swagger in my ASP.Net MVC Core project and it is documenting my API beautifully.
My co-worker asked me to install it in a full framework 4.6.1 project so I've done the following.
In Package Console Manager run:
Install-Package Swashbuckle
To get your Test Web API controller working:
1) Comment this out in the WebApi.config:
// config.SuppressDefaultHostAuthentication();
// config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));
Now this URL:
http://localhost:33515/api/Test
brings back XML:
<ArrayOfstring xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
<string>value1</string>
<string>value2</string>
</ArrayOfstring>
In Global.asax Register() I call:
SwaggerConfig.Register();
In AppStart.Swagger.Config Register() I put:
public class SwaggerConfig
{
public static void Register()
{
var thisAssembly = typeof(SwaggerConfig).Assembly;
GlobalConfiguration.Configuration
.EnableSwagger(c =>
{
c.SingleApiVersion("v1.0", "HRSA CHAFS");
c.IncludeXmlComments(GetXmlCommentsPath());
})
.EnableSwaggerUi(c =>
{});
}
private static string GetXmlCommentsPath()
{
var path = String.Format(#"{0}bin\Services.XML", AppDomain.CurrentDomain.BaseDirectory);
return path;
}
}
Now I get this error:
"A route named 'swagger_docsswagger/docs/{apiVersion}' is already in the route collection. Route names must be unique."
I've been stuck on this for hours.
How do you get rid of this?
This can happen when you re-name your .NET assembly. A DLL with the previous assembly name will be present in your bin folder. This causes the swagger error.
Delete your bin folder and re-build your solution.
This resolves the swagger error.
Swagger config uses pre-application start hook, so you don't need to call SwaggerConfig.Register() explicitly. Otherwise Register method is called twice.
[assembly: PreApplicationStartMethod(typeof(SwaggerConfig), "Register")]
in my case i added another project as refrence and that other project has swagger too.
i remove that refrence and move needed code to new project.
I solved the problem by deleting the SwaggerConfig.cs file from the App_Start folder as I had already created it manually.
Take a look at this link, here also has more useful information:
A route named 'DefaultApi' is already in the route collection error
In my experience the error occurs when you add reference to another project and that project is a service and it occurs on the SwaggerConfig of the referenced project. Removing project reference usually solve the problem, if you need to share classes I suggest you to create a specific project as Class Library and add its reference to both your services

Strongly typed configuration asp core

I am trying to create a strongly typed config section but struggling. Examples show that I can have a POCO and simply have an entry in my json this should automatically resolve.
This is what I have in ConfigureServices(). Please note, the configuration is IConfigurationRoot:
public void ConfigureServices(IServiceCollection services)
{
services
.AddOptions()
.AddMvcCore()
.AddJsonFormatters();
services.Configure<MySettings>(this.configuration.GetSection("MySettings"));
}
This is my POCO
public class MySettings
{
public string Foo { get; set; }
}
I get a compiler error Error:(41, 44) : Argument 2: cannot convert from 'Microsoft.Extensions.Configuration.IConfigurationSection' to 'System.Action<MySettings>'.
The JSON config:
{
"MySettings": {
"Foo": "hello world"
}
}
Clearly, I am doing something silly but unsure what this could be. All sources on the web suggest this "should" work.
If further info is required then I can provide that.
You are missing
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0"
in your project.json file.
(The version may be different in your specific case)
A more complete answer is that you need to add the following nuget package to your ASP Core Project if you want to configure the strongly typed config in that way.
Microsoft.Extensions.Options.ConfigurationExtensions
The extension methods contained in the package will allow you to configure the strongly typed configuration the way you want to and the way most tutorials show.
services.Configure<MyOptions>(Configuration);
Alternatively, you could add another binder package:
Microsoft.Extensions.Configuration.Binder
Configuration would then look something like this:
services.AddOptions();
services.Configure<MyOptions>(x => Configuration.Bind(x));
This is the downside of having so many modular packaged up extensions. It gets easy to lose track of where functionality exists.

Migration from WCF WebApi to MVC4 Api - Registering global error handler

I am migrating a project that was developed using WebApi Preview 5 (when it was part of WCF) to the final release of WebApi (part of MVC4). There is a document describing the process but it is extremely simplistic and doesn't cover most of the issues.
Now one of the issues I am facing is that a GlobalErrorHandler was created by inheriting from HttpErrorHandler and then overriding OnTryProvideResponse and that was used to hook error handling with Elmah. Now that was registered on AppStart with a line like this:
var configuration = new WebApiConfiguration();
//some other configuration for security and CreateInstance
configuration.ErrorHandlers =
(handlers, endpoint, description) => handlers.Add(new GlobalErrorHandler())
};
//then some registration
RouteTable.Routes.MapServiceRoute<SomeObject>("routeName", configuration);
and then mapping different route to this configuration. All this code doesn't work in the new world of MVC4 WebApi, it seems like there is a conflict between HttpErrorHandler and it can't even implement its members properly.
Now I've seen general posts about how to register Elmah with WebApi but I am trying to stick to the original code as much as possible and I am assuming - may be I am wrong - that there is a direct equivalent to what Microsoft had in the Preview version and what they released in the final one. So my questions:
What is the equivalent of this Global Error handling registation in ASP.NET MVC4 WebApi?
Do I need to do the configuration the same way it is done here (default webapi samples project doesn't seem to have similar code)
What is the equivalent of that route registration line of code: RouteTable.Routes.MapServiceRoute("routeName", configuration);
If you create a quick one-off WebApi MVC project in Visual Studio you will see an App_Start folder which contains some classes which have static methods for handling the registration, specifically:
FilterConfig.cs
WebApiConfig.cs
WebApi Config is where you need to register routes etc...
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
}
}
Filter config is what you need to handle your global errors... Filter config has a default error handler attribute added which you can swap out or out
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}
}
Global.asax calls these static registration scripts like so:
protected void Application_Start()
{
WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
}
In regard to Elmah it appears simplying including the Nuget package will register it...
Look for the package Elmah.Mvc
PM> Install-Package Elmah.MVC
it used to be like this How to get ELMAH to work with ASP.NET MVC [HandleError] attribute? but now according to this blog it has changed:
HandleErrorAttribute inside If you tried to use ELMAH in ASP.NET MVC,
you are probably implemented your own HandleErrorAttribute, as it's
shown in this example. You no longer need to apply this custom code
with Elmah.MVC. As soon you installed package, so can safely remove
your HandleError attribute, since it's already included into package.
This now appears to register itself in the Web.Config as a managedHandler so your code does not need to reference Elmah directly.

How to resolve dependency inside AuthorizeAttribute with WebApi and Ninject

My current setup is using Ninject for simple IoC, everything goes fine, but I'm not able to resolve one of the classes I need inside my AuthorizeAttribute. I need to access a class that does ClaimsVerification:
Here's my code:
IoC Config:
var kernel = new StandardKernel(); // Ninject IoC
// These registrations are "per instance request".
// See http://blog.bobcravens.com/2010/03/ninject-life-cycle-management-or-scoping/
kernel.Bind<RepositoryFactories>().To<RepositoryFactories>()
.InSingletonScope();
kernel.Bind<IRepositoryProvider>().To<RepositoryProvider>();
kernel.Bind<ISmartDocumentorUow>().To<SmartDocumentorUow>();
kernel.Bind<IClaimsVerification>().To<ClaimsVerification>();
// kernel
//kernel.BindFilter<MyAuthorizeAttribute>(FilterScope.Controller, 0).WhenControllerHas<RequireRolesAttribute>();
// Tell WebApi how to use our Ninject IoC
config.DependencyResolver = new NinjectDependencyResolver(kernel);
MyAuthorizeAttribute:
public class MyAuthorizeAttribute : AuthorizeAttribute
{
[Inject]
IClaimsVerification clamisverify { get; set; }
public MyAuthorizeAttribute()
{
//var x = System.Web.Mvc.DependencyResolver.Current.(typeof(IClaimsVerification));
}
Yap, sorry, the problem was injecting the iClaimsverification that isn't working in web api..
I tryed with the public property and still it didn't work.
the bindfilter is commented out, because it doesn't exist in the core NInject api (dll), it does exists in the MVC dll of ninject but it works for Action filters in the web mvc, and not in the api mvc for what i can tell..
i do solved the issue like this, though i don't like a lot of this fix:
private IClaimsVerification verifier
{
get
{
return (GlobalConfiguration.Configuration.DependencyResolver.GetService(typeof(IClaimsVerification)) as IClaimsVerification);
}
}
The property you have marked with Inject is private - you need to initialize Ninject with a custom configuration to opt into what would be a much less efficient process
(You didnt state the problem in your question. I see you were trying BindFilter, but it's commented out (why?) - this is the correct approach. I recommend reading the Ninject.MVC3 wiki article on BindFilter for an example)