This repository contains all code that I assume is useful in most of the cases where I need to build something. So, if you think that it could be useful for you, feel free to fork, clone, etc. Also, I tried to mention every person that I got something from. If you find code that needs to be given the correct authorship, please, let me know.

Instructions below will show your the way to get things working.

You'll need to install, at least, .NET Core SDK and Visual Studio Code. Just follow the links:

• .NET Core SDK
• Visual Studio Code

Here are a couple of apps that I find useful when developing:

• LINQPad: For writing LINQ-Queries or use as a REPL.
• Notepad++: You know what this is, don't you?
• SQLite Browser: One of the best data browsers for SQLite databases.
• Git: No need (I hope) for presentations.
• ILSpy: When you want to take a peek on the compiled code that no one have the source.
• SMTP4Dev: Small SMTP server that runs as a service on your machine, for send e-mail tests. Very useful.
• DBeaver: An alternative for databases management. Don't have all options for each specific database, but, Oh-boy, it's useful.
• Postman: Useful to test Rest API calls. Similar to SoapUI, but I think that it's much more easy to handle.
• Sonarlint: Analyze and suggest code modifications on-the-fly. Has a free-tier.

These are all just suggestions.

Maybe you'll need to install the coverage tool and report tool. If I'm not mistaken, Visual Studio already has those dependencies installed for you after restore. But...

.NET Coverlet Tool

dotnet tool install -g coverlet.console

.NET Report Generator Tool

dotnet tool install -g dotnet-reportgenerator-globaltool

Some tests will need a software to run or any other resource that may not be available on your build environment. For example, ProducerConsumer for RabbitMQ project needs RabbitMQ to run.

For these tests to run on my GitHub Actions (workflow) I needed a way to "mute" them and run only locally, since I could setup, again, RabbitMQ on a Docker container on my machine.

So, if you need to "mute" a test and run it only locally, use the RunsOnDevMachineAttribute attribute on your test method.

When you feel comfortable, you should run all tests and output the coverage result to a folder. The Report Generator Tool will take from there. So, do as follow:

Run tests with:

dotnet test --logger:"Html;LogFileName=code-coverage-log.html" --collect:"XPlat Code Coverage" --results-directory ./code-coverage/ --verbosity normal

Run the report tool with:

reportgenerator "-reports:./code-coverage/**/coverage.cobertura.xml" "-targetdir:./code-coverage/report" -reporttypes:Html

If you want to know more about the report tool, see their FAQ.

Nothing written into stone, use your ol'good common sense. But you can refere to this page, if you like: Common C# Coding Conventions.

• When I create a new extension method I never check for nullability of the target instance. If the target instance is null, you'll get an NullReferenceException on your face, punk!
• default vs null :
  • Am I sure is a reference type? null
  • Am I sure is a value type? default
  • I'm not sure at all: default
• I think that most of my developer's life I spent writing C# code. But I like that kind of code organization from Java. So, I use, almost, the same code style identation on my projects.
• Methods that returns arrays, collections or enumerables in general, DO NOT RETURN NULL VALUE EVER!!! If there's no value to return, just return an empty enumerable from the same type. Use Array.Empty<T>() or Enumerable.Empty<T>(), or I'll cut the tips of your fingers with a rust scissor...thanks.
  • If you're returning an IEnumerable<T>, probably you should use the yield keywork on your method return directive.

Let us not talk about Unity or MEF. These were from a really long time ago, on a far-far away galaxy...(I think that MEF is still in use inside some modern projects from Microsoft).

Look, I, really, understand that Microsoft has its own modern dependency injection system (ServiceCollection extensions). It'll work for most of all simple cases and applications. But for more complex scenarios, some that I cross paths on my developer's life, it'll not be the best.

Don't get me wrong, it's simple, fast, reliable and easy to use. And should be your first choice if you're starting a new ASP.NET Core project.

But I'll advocate for Autofac. It has way more road beneath its codebase and has some amazing features. Like Decorators and Type Interceptors. So, that said, all projects inside this repository will favor Autofac. 🤘😜

I'm using GitHub Actions to act as a CI/CD. All files are located in the .github folder.

There is a small "microservice" template inside the template folder. To install it just use:

dotnet new install <FULL_PATH_TO_MICROSERVICE_FOLDER>

E.g:

dotnet new install C:\Workspace\Nameless\template\Microservice\Nameless.Microservice

After that you can create a new project, using dotnet new or Visual Studio / New Project and search for Microservice template.

Just me, at the moment.

Using SemVer for assembly versioning.

• Marco Teixeira (marcoaoteixeira) - initial work

MIT

• Hat tip to anyone whose code was used.