Here is the Core code to install as a NuGet package for all of my studio Solutions. Anyone who may be reading this 👀 is free to do the same. This package is based on net10.0.
NuGet package 📦: SonghayCore
documentation 📚: SonghayCore API
One of the most important additions to .NET came in .NET 6.0 (circa 2021): the .NET Generic Host [📖 docs]. This host concept from Microsoft allows developers to not have to reinvent:
- Dependency injection (DI)
- Logging
- Configuration
- App shutdown
IHostedServiceimplementations (for long-running background tasks 📖 docs🔖)
All ASP.NET developers expect to get these things “for free” and, finally, Microsoft is basically letting all .NET developers get these things for free. This Core recognizes the .NET Generic Host, stating with the DefaultHostedService class (see Songhay.Extensions below for more details).
This Core is concerned with tracing as well as logging. Logging concerns should be logically above this Core. TraceSources and TraceSourceExtensions define how tracing should be implemented with a bias toward using all source levels. When tracing is not configured for this Core then it will be ignored without throwing exceptions.
For a review of the organizational difference between tracing and logging, see “Tracing vs Logging vs Monitoring: What’s the Difference?” by Chrissy Kidd.
Documentation 📚: Songhay.Diagnostics
The Songhay System uses imperative C# code with a view to make it more functional in an effort to control complexity and enhance maintainability.
The preference for extension methods encourages stateless, reusable routines (many of them are “pure” functions).
Notable extensions:
IConfigurationExtensions— defines shared routines based on conventions around the .NET Generic Host [📖 docs].IConfigurationBuilderExtensions— defines shared routines for application configuration building under .NET Standard.ILoggerExtensions— defines shared routines based on conventions around the .NET Generic Host [📖 docs].HttpRequestMessageExtensions— defines shared routines for HTTP access. Routines for Azure Blob Storage are included here.HttpWebRequestExtensions— defines shared routines for HTTP access for the legacy .NET Framework.
There is support for URI templates (to be used with RestApiMetadata) in the form of extension methods, running on top of Tavis.UriTemplates.
Documentation 📚: Songhay.Extensions
The Core models of the Songhay System define types for MIME, XHTML, OPML, REST, the Repository, the Display Item (for WPF and other MVVM solutions), etc.
The Core models are “anemic” by design (there are very few abstract classes)—any logic would be found first in an Extension Method.
Notable models for the client side:
DisplayItemModel— defines the conventional way to display data.MenuDisplayItemModel— defines the conventional way to display nested/grouped data.RestApiMetadata— defines conventional REST API metadata.
Selected server-side models:
EndpointContentResult— defines the result returned from all Web-based, boundary-crossing Activities.ProgramOutputResult— defines the general-purpose Result concept of Program completion with output, avoiding third-party dependencies that are not compatible with F♯.StorageObject— defines an “intersection type” for theS3Objectdefacto standard andFileInfo.
Documentation 📚: Namespace Songhay.Models
The “core” of the Core is concern for XML. The Songhay System started out as utilities around XPathDocument and grew into LINQ for XML—over XDocument.
Documentation 📚: Namespace Songhay.Xml
This Core features the concept of the Activity which is to be seen in the context of workflow solutions like Windows Workflow Foundation, Durable Task and the dapr Workflow building block. The following abstractions classify the Activities needed so far:
IActivity— defines the conventional, synchronous, input-output ActivitiesIActivityOutputOnly— defines the conventional, synchronous Activities with output only (input usually comes fromIConfigurationin this case)IActivityOutputOnlyTask— defines the conventional, asynchronous Activities with output only (input usually comes fromIConfigurationin this case)IActivityTask— defines the conventional, asynchronous, input-output Activities
This Activity concept exists to formally recognize that a Program is a ‘tree’ of inputs and outputs—the process we are drawing to form an Activity should be shaped like a tree 🌳
Amazon S3 routines for .NET Core. Outside of the world of the Microsoft cloud (Azure), the rest of the world’s cloud storage is (mostly) standardized around the AWS S3 API. Financial motivations lead one to respect this reality and the following Activities were added for access to S3 storage:
AmazonS3DeleteS3ObjectActivityAmazonS3DownloadToStringActivityAmazonS3ListBucketObjectsWithPaginationActivityAmazonS3UploadStringActivity
NuGet package 📦: SonghayCore.S3
Documentation 📚: Namespace Songhay.S3
Extensions and Handlers for Songhay Web projects. Specifically, this renewed investment in ASP.NET minimal Web API is needed to develop AOT-compiled .NET microservices for OCI-compliant containers.
NuGet package 📦: SonghayCore.Web
Documentation 📚: Namespace Songhay.Web
Defines reusable class definitions for xUnit. Featured is the ProjectFileDataAttribute, allowing test data files to be loaded from a relative path.
NuGet package 📦: SonghayCore.xUnit
Documentation 📚: Namespace Songhay.Tests
Core reusable, opinionated Newtonsoft concerns for my C# projects.
GitHub repo: https://github.com/BryanWilhite/SonghayCore.Newtonsoft
NuGet package 📦: SonghayCore.Newtonsoft
flowchart BT
netstandard2[[.NET Standard 2.0]]
net10[[.NET 10.0]]
1[SonghayCore 📦]
2[SonghayCore.Newtonsoft 📦🧊]
net10-->1
netstandard2-->2
2-..->|optional addition|1
1-->3[SonghayCore.S3 📦]
1-->4[SonghayCore.Web 📦]
1-->5[SonghayCore.xUnit 📦]
1-->6[Songhay.DataAccess 📦]
1-->8[Songhay.Publications]
3-->7[Songhay.Feeds 🌩]
4-->7[Songhay.Feeds 🌩]