Dev Story #3 – Configure outside of Startup.

I don’t like MSDN examples.

I admire they easy to use approach, and ready to copy paste and play around.

Although I found they promoting bad practice, in the mean of class hierarchy or concern separation.

Today I’m playing a bit with configuration files (appsetings.json) and build in .NET CORE DI container.

Target is trivial

I have two projects. Engine and WebAppCore (classic .NET CORE web Application).

I would like to add to DI container Configuration objects like this:

Currently this is all put inside my Startup (WebAppCore). But I would like to above code be split among modules, for instance my Engine.

Basic Step

I add static configuration class within Engine proj.

Then I fill it with simple code like this.

Configure is main entry point and will be called from webAppCore

This is our target – configure service with additional Configuration object in this case EmailConfiguration.

(Not working) (Above)

To get it like this, working and compiling I lost quite a couple of minutes to discover why my coded is highlighted on red when in the Startup it was ok.

Not So Easy…

More or less, I was filling that my code was missing something. I’m quite newbie so I don’t really know what…

I just tried to Reverse engineer using build in resharper decompilation blessing.

This is what I found above the hood of serviceCollection.Configure while using startup version:

And here you got our not working version:

As you can clearly see Startup is using OptionsConfiguration… Namespace while as EngineModule is using just OptionsServiceCollectionsExtensions. What’s more Engine Project is also .NET CORE APP proj with the same SDK but it clearly miss somethings.

Solution:

This package is required to make things working. Without it, you will be shaking your head with no idea what’s going on.

Summary:

Making code better is usually a road with a lot of obstacles which sometimes (like today) make things frustrating. Because you know what to do, but you struggling to get it working as you would expect it.

I still missing those good examples where good programming aspects have been taken into consideration instead of just poorly making things working.

Remember that those extra effort will benefit in future, or make you regret that you didn’t make it earlier.

Ps.

I should also mention, that my steps was the minimal way of improving things and make my code a little bit more manageable and extracted into rights components. I don’t like feeding my startup like a trash with lot’s of different configuration.

Also in this simple project, on this stage(!) we found out that we don’t need a dedicated DI container like AUTOFAC or NINJECT when you could load all you assemblies with convention loading type (like pro does ?:)).

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *