Support LicenseKey via environment variable fallback

[Nit8]

PR: Auto-Detect License Key from Environment Variables Fixes #4631

What Changed

Added support for reading the AutoMapper license key from an environment variable instead of requiring manual configuration in code.

Why

In containerized and cloud environments, it's better to use environment variables for sensitive configuration instead of hardcoding values in code.

How It Works

The LicenseKey property now checks for values in this order:

1. Explicit value set in code (cfg.LicenseKey = "key") - highest priority
2. Environment variable AUTOMAPPER_LICENSE_KEY - fallback
3. Null if neither is set - lowest priority

Usage

NEW WAY - Using Environment Variable:
Set environment variable AUTOMAPPER_LICENSE_KEY before running your app
Then just add AutoMapper without setting the license key:

services.AddAutoMapper(cfg => 
{
    cfg.CreateMap<Foo, FooDto>();
});

OLD WAY - Still Works (Backward Compatible):

services.AddAutoMapper(cfg => 
{
    cfg.LicenseKey = "your-license-key";
    cfg.CreateMap<Foo, FooDto>();
});

BOTH SET - Code value wins:
If you set both the environment variable AND code value, the code value is used.

Tests Added

• Tests for environment variable auto-detection
• Tests for old explicit assignment (backward compatibility)
• Tests for precedence when both are set
• Integration tests with dependency injection

Backward Compatibility

100% backward compatible. All existing code continues to work exactly the same way.

[Nit8]

@jbogard can you run this pipeline to check if anything goes wrong

[Nit8]

Hi @jbogard, is this issue related to pipeline, am I missing something?

[jbogard]

Hmm that is odd, I tried to re-run it but still getting that error.

[Nit8]

yeah @jbogard thats strange does it have something to do with ci pipeline and about read and write permissions?

[Nit8]

Hi @jbogard I see you changed the permission into your release.yml and maybe same has to be done from ci.yml from read to write for this to complete as mentioned in my previous comment, and you can try firing the pipeline to verify. Thanks

[SubashPaudyalTR]

This would be a great relief if we have this directly fed from the configuration, and introduce less noise ... as we are having more than dozens of services which is using automapper and we just acquired the enterprise license. We are looking for best option weather to go with per service configuration v/s one-place shared library. Both holds its own pros and cons, but if we get this env. var auto-discovery, it would be the real winner for us... with minimal changes.

Waiting for this and any other valuable suggestions!!!

[jbogard]

Hey all, I want this to land in the next release. I need this to also work with MediatR so I'm going to suggest some changes that allow it to work in environments that use a single Bundle key across both products in a single application.

[jbogard]

Thanks for this, @Nit8 — really appreciate the contribution, and it pushed exactly the right feature forward. 🙏 I've pushed a few commits on top of your branch to get it merge-ready, and wanted to walk through what changed and why.

What I kept: your core idea — falling back to an environment variable when no key is set in code, fully backward compatible — is exactly right, and the precedence model (explicit code value wins) is preserved.

What I changed:

1. Moved the discovery out of the property getter into LicenseAccessor. Reading Environment.GetEnvironmentVariable(...) inside the LicenseKey getter made the property side-effecting and non-deterministic (it hit the environment on every access). I reverted MapperConfigurationExpression.LicenseKey back to a plain auto-property and centralized resolution in LicenseAccessor.ResolveLicenseKey(...) — the single place that actually consumes the key. This also gives us a clean seam for the IConfiguration / file-based discovery that Support automatic discovery of license keys #4631 also asks for.

2. Added a second, shared LUCKYPENNY_LICENSE_KEY variable. Lucky Penny licenses are sold as a bundle covering both AutoMapper and MediatR, so a company-wide variable lets both libraries read the same key. Resolution precedence is now:

   • cfg.LicenseKey (explicit code) →
   • AUTOMAPPER_LICENSE_KEY (product-specific) →
   • LUCKYPENNY_LICENSE_KEY (shared)

   Product-specific wins over the shared key, mirroring how Duende IdentityServer layers a product key over a company-wide one. (Note: the shared key still has to be for a license that includes AutoMapper — a MediatR-only license won't validate here.)

3. Reworked the tests to target ResolveLicenseKey directly for the precedence rules, and disabled parallelization on that class since it mutates process-global environment variables.

4. Documented the new auto-discovery section in License-configuration.md.

The env var names follow the flat all-caps convention used by other commercial .NET libraries (Particular's PARTICULARSOFTWARE_LICENSE, Telerik's TELERIK_LICENSE, etc.), since AutoMapper reads them directly rather than through IConfiguration binding.

Thanks again — your authorship on the PR stands, this just builds on it.

[Nit8]

Thanks so much for taking the time to build on this rather than just closing it really means a lot.
The refactor to LicenseAccessor.ResolveLicenseKey() makes complete sense in hindsight; I hadn't considered the side-effect problem with hitting the environment on every property access.
Happy with everything you've done on top, and glad the core idea was worth building on. Looking forward to seeing it merged this is a library we use in our own project, and having run into this issue ourselves, it felt worth solving for everyone's benefit.
Looking forward to contributing more to this amazing project!