A pattern that's common for some apps is the need to share settings across multiple projects. For example, imagine you have both an ASP.NET Core RazorPages app and an ASP.NET Core Web API app in the same solution: 

protected override void Seed(SeedingDataFromCSV.Domain.LocationContext context)
{
    Assembly assembly = Assembly.GetExecutingAssembly();
    string resourceName = "SeedingDataFromCSV.Domain.SeedData.countries.csv";
    using (Stream stream = assembly.GetManifestResourceStream(resourceName))
    {
        using (StreamReader reader = new StreamReader(stream, Encoding.UTF8))
        {
            CsvReader csvReader = new CsvReader(reader);
            csvReader.Configuration.WillThrowOnMissingField = false;
            var countries = csvReader.GetRecords<Country>().ToArray();
            context.Countries.AddOrUpdate(c => c.Code, countries);
        }
    }

    resourceName = "SeedingDataFromCSV.Domain.SeedData.provincestates.csv";
    using (Stream stream = assembly.GetManifestResourceStream(resourceName))
    {
        using (StreamReader reader = new StreamReader(stream, Encoding.UTF8))
        {
            CsvReader csvReader = new CsvReader(reader);
            csvReader.Configuration.WillThrowOnMissingField = false;
            while (csvReader.Read())
            {
                var provinceState = csvReader.GetRecord<ProvinceState>();
                var countryCode = csvReader.GetField<string>("CountryCode");
                provinceState.Country = context.Countries.Local.Single(c => c.Code == countryCode);
                context.ProvinceStates.AddOrUpdate(p => p.Code, provinceState);
            }
        }
    }
}

Finbuckle.MultiTenant

Finbuckle.MultiTenant is an open source framework for multitenant support in ASP.NET Core 2.0+ applications. Check out the GitHub repository for source code and samples or to provide feedback and suggestions. 

Entity Framework Core 2.0 introduces global query filters that can be applied to entities when a model is created. It makes it easier to build multi-tenant applications and support soft deleting of entities. This blog post gives a deeper overview of how to use global query filters in real-life applications and how to apply global query filters to domain entities automatically. 

• https://github.com/aspnetboilerplate/aspnetboilerplate/tree/dev/src/Abp/Specifications 
  
• https://github.com/vkhorikov/SpecificationPattern/blob/master/SpecificationPattern/Specifications.cs 

• https://aspnetboilerplate.com/Pages/Documents/Specifications 
  
• http://www.agiledevelopment.ir/ebook/design-pattern/business-logic-layer-patterns/applying-organization-patterns/specification/ 
  
• http://www.agiledevelopment.ir/ebook/design-pattern/business-logic-layer-patterns/applying-organization-patterns/composite/ 
  

Manage events entities is pretty easy. You define few informations like a subject, a content, and maybe the most important, dates (a start and a end date of course).
You’re ready to create calendar or timeline features. Baooom! Now you need to be able to create recurrent event ! And everything is going to break.
I’ve work on this kind of feature, and here are my small advices 

A simple library that support two way binding with angular syntax  

The Problem

What they neglect to say is all that testability and persistence ignorance flies right out the window when you create a new ASP.NET Web Application using the MVC template and "Individual User Accounts" authentication. What you get is a single-layered application, tightly coupled to Entity Framework, that:

• Ignores the patterns that facilitate testing, including: the repository pattern, unit of work pattern, and dependency injection;

• Forces you to implement their IUser interface in your application’s User entity, thereby coupling it to ASP.NET Identity;

• Eliminates any clear separation between your entities, persistence concerns, and business logic. Persistence ignorance? Forget about it.

Thankfully, due to the extensibility designed into ASP.NET Identity, it is possible to ditch the reference to the Microsoft.AspNet.Identity.EntityFramework assembly and write a custom implementation that can address these and other architectural issues. Just be forewarned: it is not a trivial undertaking, and you’ll have to put up with some code smell that is baked into the Microsoft.AspNet.Identity.Core assembly.