Alright, it’s time to start writing some code, but first, let’s decide how this project will be organized.
So far, the repository structure that I’ve found most appealing is the one I used for the SyncFramework (https://github.com/egarim/SyncFramework). Here is a representation with bullet points:
- Repo Folder: This is the parent folder that will contain all the code from our project. o Git Files: These are Ignore and attributes files.
- Clean.bat: This is a batch file that deletes all child BIN and OBJ folders to ensure our repository does not contain binary files (sometimes the ‘clean’ command from Visual Studio does not clear the outputs completely).
- CHANGES.MD: This is a Github markdown file that contains the history of changes in the code.
- README.MD: This is the landing page of the current repository where we can write some basic instructions and other important information about the project.
- src (folder): This is where the actual code resides.
- Directory.Build.props: This is a special file name recognized by the .NET Core’s MSBuild system. When MSBuild runs, it automatically imports this file from the current directory and all parent directories. It is typically used for sharing common properties across multiple projects in a solution.
Alchemy.Net.Core: This contains a class library where all the interfaces, abstract classes, and base implementations reside.
- Tests.Alchemy.Net.Core: This is the NUnit test project for AlchemyDotNet.Core. I typically write integration tests where I examine the use cases for the library, rather than unit tests.
- Alchemy.Net.sln: This is the main solution file. We will eventually create solution filter files for the rest of the projects.
- Examples: These are technical examples of how to use the library.
Before I conclude this post, I want to discuss versioning. The main idea here is this: the project AlchemyDotNet.Core will start at version 1.0.0, and the version will change when there is a fix or an update to the core specification. We will only move to a new version like 2.0.0 when the specification introduces breaking changes. This means that we will be on version 1 for a very long time.
Link to the repo