{"@attributes":{"version":"2.0"},"channel":{"title":"DEV Community: Galdin Raphael","description":"The latest articles on DEV Community by Galdin Raphael (@galdin).","link":"https:\/\/dev.to\/galdin","image":{"url":"https:\/\/media2.dev.to\/dynamic\/image\/width=90,height=90,fit=cover,gravity=auto,format=auto\/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F15060%2F46b4bd62-158c-4a84-994c-2cfc98ee5300.jpeg","title":"DEV Community: Galdin Raphael","link":"https:\/\/dev.to\/galdin"},"language":"en","item":[{"title":"Build-time configuration for Blazor WebAssembly Apps using MS Build properties","pubDate":"Sun, 28 Jun 2020 12:04:44 +0000","link":"https:\/\/dev.to\/galdin\/build-time-configuration-for-blazor-webassembly-apps-using-ms-build-properties-3pgp","guid":"https:\/\/dev.to\/galdin\/build-time-configuration-for-blazor-webassembly-apps-using-ms-build-properties-3pgp","description":"

.NET Core in general has a nice configuration API that I've been fond of since .NET Core 1.x. But since Blazor WebAssembly apps run completely on the client, the configuration works a little differently that one might expect.<\/p>\n\n

The way configuration using appsettings.json<\/code> works is that, a HTTP request is sent to a appsettings.json<\/code> file. So if the app is available at https:\/\/xyz.com<\/code>, the request goes to https:\/\/xyz.com\/appsettings.json<\/code>. You can also use another file-name or path if you want to.<\/p>\n\n

But if you're just trying to do something like set the Web API's Base URL, a HTTP request on startup can feel like an overkill. I'm gonna try and address that with this post.<\/p>\n\n

Source Code:<\/strong> https:\/\/github.com\/gldraphael\/blazor-build-time-configuration<\/a><\/p>\n\n

First, we create a custom Attribute<\/code> to hold our configuration:
\n<\/p>\n\n

\n
[<\/span>AttributeUsage<\/span>(<\/span>AttributeTargets<\/span>.<\/span>Assembly<\/span>,<\/span> Inherited<\/span> =<\/span> false<\/span>)]<\/span>\nsealed<\/span> class<\/span> BuildConfigurationAttribute<\/span> :<\/span> Attribute<\/span>\n{<\/span>\n    public<\/span> string<\/span>?<\/span> BaseUrl<\/span> {<\/span> get<\/span>;<\/span> }<\/span>\n    public<\/span> string<\/span> BuildDate<\/span> {<\/span> get<\/span>;<\/span> }<\/span>\n\n    public<\/span> BuildConfigurationAttribute<\/span>(<\/span>string<\/span> baseUrl<\/span>,<\/span> string<\/span> buildDate<\/span>)<\/span>\n    {<\/span>\n        BaseUrl<\/span> =<\/span> string<\/span>.<\/span>IsNullOrWhiteSpace<\/span>(<\/span>baseUrl<\/span>)<\/span> ?<\/span> null<\/span> :<\/span> baseUrl<\/span>;<\/span>\n        BuildDate<\/span> =<\/span> buildDate<\/span> ??<\/span> \"n\/a\"<\/span>;<\/span>\n    }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Next, we apply this Attribute to the Assembly by passing MS Build properties in the .csproj<\/code> file:
\n<\/p>\n\n
\n
<ItemGroup><\/span>\n  <AssemblyAttribute<\/span> Include=<\/span>\"WasmApp.BuildConfigurationAttribute\"<\/span>><\/span>\n    <_Parameter1><\/span>$(BaseUrl)<\/_Parameter1><\/span>\n    <_Parameter2><\/span>$(BuildDate)<\/_Parameter2><\/span>\n  <\/AssemblyAttribute><\/span>\n<\/ItemGroup><\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
We could, optionally, set default values for MS Build properties in the same file, like so:
\n<\/p>\n\n
\n
<PropertyGroup><\/span>\n  <BaseUrl><\/span>https:\/\/example.org<\/BaseUrl><\/span>\n  <BuildDate><\/span>$([System.DateTime]::UtcNow.ToString(\"dd MMM, yyyy\"))<\/BuildDate><\/span>\n<\/PropertyGroup><\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Next, we access the ApiConfigurationAttribute<\/code> from Main()<\/code> to configure it with DI, so that it's accessible to the rest of the application in the usual way:
\n<\/p>\n\n
\n
public<\/span> static<\/span> async<\/span> Task<\/span> Main<\/span>(<\/span>string<\/span>[]<\/span> args<\/span>)<\/span>\n{<\/span>\n    var<\/span> builder<\/span> =<\/span> WebAssemblyHostBuilder<\/span>.<\/span>CreateDefault<\/span>(<\/span>args<\/span>);<\/span>\n    builder<\/span>.<\/span>RootComponents<\/span>.<\/span>Add<\/span><<\/span>App<\/span>>(<\/span>\"app\"<\/span>);<\/span>\n\n    \/\/ Get an instance of the attribute applied to the assembly<\/span>\n    var<\/span> apiConfig<\/span> =<\/span> Assembly<\/span>.<\/span>GetAssembly<\/span>(<\/span>typeof<\/span>(<\/span>Program<\/span>)).<\/span>GetCustomAttribute<\/span><<\/span>BuildConfigurationAttribute<\/span>>();<\/span>\n\n    \/\/ Register the configuration with DI<\/span>\n    var<\/span> baseUrl<\/span> =<\/span> new<\/span> Uri<\/span>(<\/span>apiConfig<\/span>.<\/span>BaseUrl<\/span> ??<\/span> builder<\/span>.<\/span>HostEnvironment<\/span>.<\/span>BaseAddress<\/span>);<\/span>\n    builder<\/span>.<\/span>Services<\/span>.<\/span>Configure<\/span><<\/span>AppOptions<\/span>>(<\/span>o<\/span> =><\/span>\n    {<\/span>\n        o<\/span>.<\/span>BaseUrl<\/span> =<\/span> baseUrl<\/span>;<\/span>\n        o<\/span>.<\/span>BuildDate<\/span> =<\/span> apiConfig<\/span>.<\/span>BuildDate<\/span>;<\/span>\n    });<\/span>\n\n    \/\/ Set the BaseUrl on the HttpClient<\/span>\n    builder<\/span>.<\/span>Services<\/span>.<\/span>AddTransient<\/span>(<\/span>sp<\/span> =><\/span> new<\/span> HttpClient<\/span> {<\/span> BaseAddress<\/span> =<\/span> baseUrl<\/span> });<\/span>\n\n    await<\/span> builder<\/span>.<\/span>Build<\/span>().<\/span>RunAsync<\/span>();<\/span>\n}<\/span>\n\n\/\/ AppOptions is defined as<\/span>\ninternal<\/span> class<\/span> AppOptions<\/span>\n{<\/span>\n    public<\/span> Uri<\/span> BaseUrl<\/span> {<\/span> get<\/span>;<\/span> set<\/span>;<\/span> }<\/span>\n    public<\/span> string<\/span> BuildDate<\/span> {<\/span> get<\/span>;<\/span> set<\/span>;<\/span> }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
And now we can use it as usual:
\n<\/p>\n\n
\n
@page \"\/\"\n@inject IOptions<AppOptions><\/span> options\n\n<pre><\/span>\n    <strong><\/span>Base URL:<\/strong><\/span> @options.Value.BaseUrl\n    <strong><\/span>Last Build:<\/strong><\/span> @options.Value.BuildDate\n<\/pre><\/span>\n\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
That's it. dotnet run<\/code> or running it within Visual Studio will use the dev-environment-friendly default values:<\/p>\n\n
\"Screenshot<\/a><\/p>\n\n
Now all you need to do to set (or override) the MS Build properties (BaseUrl<\/code> in this case) in the other environments is to use the -p:<\/code> or \/p:<\/code> switch:
\n<\/p>\n\n
\n
dotnet build -p<\/span>:BaseUrl=<\/span>\"https:\/\/prod.example.com\"<\/span>\ndotnet run --no-build<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
We now have a nice mechanism to use different API Base URLs for different environments, and have environment specific build-time configuration without the need to make a HTTP request.<\/p>\n\n\n\n\n
I think the decision of making a HTTP request to the appsettings.json<\/code> file was the right one. Because to me a \"configurable\" app is one that reads configuration at runtime. Build time configuration is like hardcoding the strings \u2014 well, different strings \u2014 for each environment in our case. So if I were to use docker, I'd now need to maintain an image for each environment if I choose to use \"build time configuration\".<\/p>\n\n","category":["blazor","dotnet"]},{"title":"How to post json with comments?","pubDate":"Mon, 20 Jan 2020 18:20:43 +0000","link":"https:\/\/dev.to\/galdin\/how-to-post-json-with-comments-3pfc","guid":"https:\/\/dev.to\/galdin\/how-to-post-json-with-comments-3pfc","description":"
Using a json<\/code> codeblock expects strictly valid JSON:
\n<\/p>\n\n
\n
{<\/span>\n  <\/span>\"Email\"<\/span>:<\/span> <\/span>{<\/span> <\/span>\/\/<\/span> <\/span><--<\/span> <\/span>settings<\/span> <\/span>grouped<\/span> <\/span>under<\/span> <\/span>\"Email\"<\/span>\n    <\/span>\"ClientKey\"<\/span>:<\/span> <\/span>\"xxx\"<\/span>,<\/span>\n    <\/span>\"ClientSecret\"<\/span>:<\/span> <\/span>\"xxx\"<\/span>\n  <\/span>}<\/span>\n<\/span>}<\/span>\n<\/span><\/code><\/pre>\n\n<\/div>\n\n\n\n
I tried jsonc<\/code> and json5<\/code>, both don't seem to be supported. Anyway to get dev.to to play nice with commented json without marking it as javascript<\/code>?<\/p>\n\n","category":"meta"},{"title":"You don't need IConfiguration outside Startup","pubDate":"Wed, 15 Jan 2020 17:53:00 +0000","link":"https:\/\/dev.to\/galdin\/you-don-t-need-iconfiguration-outside-startup-3p3c","guid":"https:\/\/dev.to\/galdin\/you-don-t-need-iconfiguration-outside-startup-3p3c","description":"
I'm writing this for those new to ASP.NET Core, based on what I see on StackOverflow. Most of what I've written here is already in the Docs, so check the links at the end of the post for detailed info.<\/p>\n\n
\n  \n  \n  The ASP.NET Core Web Host\n<\/h2>\n\n
Think of the web host as an instance of an application server that processes incoming web requests. We create one (usually in Program.cs<\/code>) as follows:
\n<\/p>\n\n
public<\/span> static<\/span> void<\/span> Main<\/span>(<\/span>string<\/span>[]<\/span> args<\/span>)<\/span> =><\/span> \n    CreateHostBuilder<\/span>(<\/span>args<\/span>).<\/span>Build<\/span>().<\/span>Run<\/span>();<\/span>\n\npublic<\/span> static<\/span> IHostBuilder<\/span> CreateHostBuilder<\/span>(<\/span>string<\/span>[]<\/span> args<\/span>)<\/span> =><\/span>\n    Host<\/span>.<\/span>CreateDefaultBuilder<\/span>(<\/span>args<\/span>)<\/span>\n        .<\/span>ConfigureWebHostDefaults<\/span>(<\/span>webBuilder<\/span> =><\/span>\n            webBuilder<\/span>.<\/span>UseStartup<\/span><<\/span>Startup<\/span>>()<\/span>\n        );<\/span>\n<\/code><\/pre><\/div>\n\n\n\n
When the WebHost<\/code> is built using Build()<\/code>, your startup class's ConfigureServices()<\/code> is called. See WebHostBuilder.cs L187<\/a>, WebHost.cs L110<\/a> and WebHost.cs L180<\/a>.<\/p>\n\n
\n  \n  \n  Using IConfiguration in Startup\n<\/h2>\n\n
You can get an instance of IConfiguration<\/code> for use in your Startup class by constructor injection:
\n<\/p>\n\n
public<\/span> class<\/span> Startup<\/span>\n{<\/span>\n    private<\/span> IConfiguration<\/span> Configuration<\/span> {<\/span> get<\/span>;<\/span> }<\/span>\n    public<\/span> Startup<\/span>(<\/span>IConfiguration<\/span> configuration<\/span>)<\/span> \/\/ <-- the framework injects<\/span>\n                                                 \/\/ a valid instance<\/span>\n    {<\/span>\n        Configuration<\/span> =<\/span> configuration<\/span>;<\/span> \/\/ <-- and we save that<\/span>\n    }<\/span>\n\n    \/\/ rest of the class ...<\/span>\n}<\/span>\n\n<\/code><\/pre><\/div>\n\n\n\n
The whole point of IConfiguration<\/code> is to provide a way through which the .NET Core app can read configuration from different sources: configuration files, environment variables, command line arguments, etc.<\/p>\n\n
\n  \n  \n  Using IConfiguration outside Startup\n<\/h2>\n\n
You can also inject an IConfiguration<\/code> instance almost anywhere:
\n<\/p>\n\n
public<\/span> class<\/span> EmailSender<\/span> \n{<\/span>\n    private<\/span> string<\/span> ClientKey<\/span> {<\/span> get<\/span>;<\/span> }<\/span>\n    private<\/span> string<\/span> ClientSecret<\/span> {<\/span> get<\/span>;<\/span> }<\/span>\n\n    public<\/span> EmailSender<\/span>(<\/span>IConfiguration<\/span> configuration<\/span>)<\/span>\n    {<\/span>\n        ClientKey<\/span> =<\/span> configuration<\/span>[<\/span>\"ClientKey\"<\/span>];<\/span>\n        ClientSecret<\/span> =<\/span> configuration<\/span>[<\/span>\"ClientSecret\"<\/span>];<\/span>\n    }<\/span>\n\n    \/\/ rest of the class follows...<\/span>\n}<\/span>\n<\/code><\/pre><\/div>\n\n\n\n
Let's just stop for a while and imagine an example: we're in a controller's action and need to send an email. We get an EmailSender<\/code> instance from DI, and use it to send the email. The EmailSender<\/code> gets email credentials from the IConfiguration<\/code> abstraction. It doesn't need to know where it's coming from: appsettings.json, command-line arguments, environment variables, azure vault storage\u2013 could be coming from anywhere and EmailSender<\/code> doesn't need to care about it.<\/p>\n\n
There are still areas left wanting though:<\/p>\n\n
    \n
  1. The configuration is not strongly typed: non-string values will need to be manually parsed.<\/li>\n
  2. The email sender above requires ClientKey<\/code> and ClientSecret<\/code> to be defined using the exact configuration keys. So EmailSender<\/code> is sort-of coupled with the way the actual configuration is set.<\/li>\n<\/ol>\n\n
    The solution to these is the Options Pattern.<\/p>\n\n
    \n  \n  \n  Options Pattern\n<\/h2>\n\n
    Think of this as an additional layer of abstraction. In the EmailService<\/code> example, we'd replace IConfiguration<\/code> with IOptions<\/code>. IConfiguration<\/code> knew how to get the right configuration from the right places for you, IOptions<\/code> knows how to get the relevant configuration from IConfiguration<\/code> for you.<\/p>\n\n
    Here's a simplified way to use it:<\/p>\n\n
      \n
    1. \n
      Group related settings together in your appsettings.json<\/code>:
      \n<\/p>\n
      {<\/span>\n  \"<\/span>Email<\/span>\"<\/span>:<\/span> {<\/span> \/\/ <-- settings grouped under \"Email\"<\/span>\n    \"<\/span>ClientKey<\/span>\"<\/span>:<\/span> \"<\/span>xxx<\/span>\"<\/span>,<\/span>\n    \"<\/span>ClientSecret<\/span>\"<\/span>:<\/span> \"<\/span>xxx<\/span>\"<\/span>\n  }<\/span>\n}<\/span>\n\n<\/code><\/pre>\n\n<\/li>\n
    2. \n
      Create a class to hold those settings:
      \n<\/p>\n
      public<\/span> class<\/span> EmailOptions<\/span>\n{<\/span>\n    public<\/span> string<\/span> ClientKey<\/span> {<\/span> get<\/span>;<\/span> set<\/span>;<\/span> }<\/span>\n    public<\/span> string<\/span> ClientSecret<\/span> {<\/span> get<\/span>;<\/span> set<\/span>;<\/span> }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/li>\n
    3. \n
      Register the Options with the DI container:
      \n<\/p>\n
      services<\/span>.<\/span>Configure<\/span><<\/span>EmailOptions<\/span>(<\/span>Configuration<\/span>.<\/span>GetSection<\/span>(<\/span>\"EmailOptions\"<\/span>));<\/span>\n<\/code><\/pre>\n\n<\/li>\n
    4. \n
      Inject it into the service that needs it:
      \n<\/p>\n
      public<\/span> class<\/span> EmailSender<\/span> \n{<\/span>\n    private<\/span> string<\/span> ClientKey<\/span> {<\/span> get<\/span>;<\/span> }<\/span>\n    private<\/span> string<\/span> ClientSecret<\/span> {<\/span> get<\/span>;<\/span> }<\/span>\n\n    public<\/span> EmailSender<\/span>(<\/span>IOptions<\/span><<\/span>EmailOptions<\/span>><\/span> options<\/span>)<\/span> \/\/ <-- here<\/span>\n    {<\/span>\n        ClientKey<\/span> =<\/span> options<\/span>.<\/span>Value<\/span>.<\/span>ClientKey<\/span>;<\/span>\n        ClientSecret<\/span> =<\/span> options<\/span>.<\/span>Value<\/span>.<\/span>ClientSecret<\/span>;<\/span>\n    }<\/span>\n\n    \/\/ rest of the class follows...<\/span>\n}<\/span>\n\n<\/code><\/pre>\n\n<\/li>\n<\/ol>\n\n
      Follow this, and you won't see the need to inject IConfiguration<\/code> anywhere outside Startup<\/code>.<\/p>\n\n\n\n\n
      \n  \n  \n  Microsoft Docs links:\n<\/h4>\n\n
The CreateDefaultBuilder()<\/code> sets up the app's configuration. Source (v3.0.0)<\/a>. The app's configuration is represented by the IConfiguration<\/code> interface. (You can also manually create your own WebHostBuilder<\/code> instance if the defaults don't work for you, in which case you're responsible for setting up the app configuration.)<\/p>\n\n
\"Screenshot<\/a><\/p>\n\n