Query - Is there any way to generate console log statements from a .Net Standard 2.0 library?

[MarkStega]

My Blazor project implements and consumes several .Net Standard 2.0 assets. From one of these is there any clever way to access the console logging supplied by the extension?

[galvesribeiro]

Hey @MarkStega

Assuming that your netstandard2.0 library rely on logging from Microsoft.Extensions.Logging and it is injected on the same DI context as blazor, you should be able to use this logger with the library without problems.

In other words, if your library depends on ILogger, ILogger<T> or ILoggerFactory and it is added to Blazor DI container, you should be able to use it just fine.

Please let me know if I can help further.

[MarkStega]

@galvesribeiro

Thanks; The issue went back to the same problem with the 'inject' in #15 leading me to believe that it couldn't work.

[MarkStega]

@galvesribeiro I modified the 'inject' in my netstandard2.0 library and received an error message. I then created a Blazor dll and received the same error when I try to log a message.

ORManagerView OnInitAsync() entry
blazor.webassembly.js:1 WASM: [System.ArgumentNullException] Value cannot be null.
blazor.webassembly.js:1 WASM: Parameter name: logger
blazor.webassembly.js:1 WASM:   at Optimiser.DataTier.RestServices.RestBaseService.GetAsync[TResult] (System.String controller) [0x0013c] in C:\Solutions\OHI\Optimiser\NG-Blazor\DataTier.Rest\RestServices\RestBaseService.cs:61 

The first message 'ORMAnagerView OnInitAsync() entry' is logging output from the logging extension. The error that follows results from using the injected property in an attempt to create a log message.

In a previous reply you stated "Assuming that your netstandard2.0 library rely on logging from Microsoft.Extensions.Logging and it is injected on the same DI context as blazor, you should be able to use this logger with the library without problems. "

I am not certain by the meaning of "and it is injected on the same DI context as blazor,"

[galvesribeiro]

Hey,

As I mentioned on other question, if you look at Blazor docs here https://blazor.net/docs/dependency-injection.html you will see that you need to register your component on Blazor's service collection (DI container) like this:

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IDataAccess, DataAccess>();
}

That is on your Startup.cs class.

Once you do that, your component can receive injected types from the DI container like in this case, ILoggerFactory , ILogger<T> or ILogger.

The error is clear. It is not able to inject the logger because (1) you are not adding the logger to the DI container or (2) you are not added your component to the container.

In case of (1), please check the Readme.md page of this repo. In case of (2), check the Blazor docs I mentioned here again.

Note that Blazor components always leverage the container so it doesn't need to be injected there.

I would suggest a good read on Blazor docs. They are not extensive and give you a good feel on where things glue together.

[MarkStega]

Thanks, I had read that page about 3 times and I really didn't 'get it'. Once I realized I had to convert everything all the way up the chain to the actual Blazor page it finally made sense. I have things working but am not fully convinced that the DI pattern improved my code. I am used to explicitly managing object lifetimes. I may try an experiment and do dependencies the 'old fashioned' way by creating the truly needed services (HttpClient & ConsoleLog so far) at the Blazor level and passing them as parameters down the chain of classes.

In any case, thanks for sticking with me over the many questions and lack of understanding.

[galvesribeiro]

No problem.

There are many advantages of using DI. I'm not advocating it but, if you look at all the current Microsoft ecosystem of libraries, they all somehow are tied to Microsoft.Extensions.Logging.Abstractions, Microsoft.Extensions.DependencyInjection.Abstractions, Microsoft.Extensions.Options.Abstractions and (soon) Microsoft.Extensions.Hosting.Abstractions. Those things cover all basic crosscutting concerns you would find on any kind of app.

You can still manage the lifecycle of the classes. Look at this article https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1#service-lifetimes

It is focused on Asp.Net but use that DI abstractions and can give a overview on how to define lifetime of classes.

I hope it help.

Thanks