A .NET library for loading environment variables from .env files, supporting .NET Core and .NET Framework.
dotnet-env is a .NET library that loads environment variables from `.env` files into your application's runtime. It solves the problem of managing configuration and secrets during local development by providing a familiar, file-based approach that keeps sensitive data out of source code. The library supports .NET Core and .NET Framework 4.6+.
.NET developers who need a simple way to manage environment-specific configuration locally, especially those transitioning from other ecosystems like Node.js where `.env` files are standard.
Developers choose dotnet-env for its seamless integration with .NET's `System.Environment`, type-safe helper methods, and advanced parsing features like variable interpolation. It's a lightweight, MIT-licensed library that follows established patterns while providing .NET-specific conveniences like a configuration provider.
A .NET library to load environment variables from .env files
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Provides an AddDotNetEnv extension for .NET's ConfigurationBuilder, allowing seamless loading of .env variables into app settings with __ mapped to : for sections, as shown in the usage examples.
Supports complex interpolation syntax with default, required, and alternative values, including nested references, detailed in the .env file structure section with examples like KEY=${ENVVAR:-default}.
Offers helper methods such as GetBool and GetInt with optional default values, reducing runtime errors compared to raw string access from System.Environment.GetEnvironmentVariable.
Allows loading from paths, streams, strings, or multiple files with configurable precedence and options like TraversePath to search parent directories, as demonstrated in the Load methods.
The README explicitly advises against using .env files in production, stating they should only be for local development, which limits utility in deployed environments.
Differences in handling whitespace around equals signs and comment recognition, such as allowing # directly after =, can break compatibility with bash-sourced .env files, as noted in the .env file structure section.
Environment variables are loaded only at application startup; changes to .env files during runtime are not reflected, restricting dynamic updates, as mentioned in the 'Note about Production'.