Early .NetCore: An Experience
I build Web applications for a profession. When you are developing for someone else, you need to follow different priorities. So as a way to stay sharp, I developed my own Webapp to test out alternate architectural choices. Sometimes I wouldn't agree with a design or I couldn't justify spending time on testing both implementations.
I built this Web app using all the design decisions that I wanted to use or didn't have the time to implement. It's my own time so I could afford to do whatever I wanted. One of them was eagerly using .netcore before it was out of version 1.0. I had experience working with C# and expected the change to be minor. As the language is almost the same, and the framework would be very similar It would be easy I thought. This was not the case.
When I started the project, upgrading from version to version was also a significant challenge. Not only did you have to re-engineer each service to work with the changes and then find out the packages are broken for that particular version. Which happened more often than I would have liked.
Initially, I didn’t like Entity Framework as It seemed way too powerful. It is still the top dog for database connectors in c# applications today. It handles migrations, Object mapping, and Is super easy to chuck into a service. I figured I only wanted to be able to write SQL. All this other stuff was far to fancy to need. I had also come from a workplace that didn’t like Entity Framework. So I attempted to build my own. This approach was way more costly than I anticipated. It required so much work to get anything to talk to the database.
I ended up biting the bullet and Entity framework anyway. Though it had its own problems when it came to net core. I wanted to use a MySQL database because I was familiar with it and the licensing was cheap. net core at the time had two competing MySQL connectors for EF. I used both throughout the versions because they alternated between which one actually worked.
Testing was started right at the beginning of the project. I wanted to be able to develop without having to have a database active. Entity Framework has an in-memory connector for local development. This made it really easy to develop quickly as I could check regressions and develop features and have a fast turn around time to see if I had broken anything.
I extended the testing to be able to “unit” test services as well which I wrote up here. It gave me the benefit of being able to test parts of the application without mocking the whole application out. Performing particular scenarios was also made easier as I could optionally provide simple implementations of injected services.
Keeping testing in mind the application is written in a way that makes it easier. As new features are added and the application scales it can be tested without any restrictions.
After I read some blog posts about why you shouldn't implement user authentication and password management. I got the hint that it was a bad idea and you should never do it. You will always get it wrong and its best to leave it to a framework or another party. So I decided to build my own anyway. I found ASP.net’s implementation of user auth not very flexible. So by implementing it myself, it gave me a greater understanding of what was going on under the hood.
I Used SHA256 to hash passwords but It should be flexible enough to be upgraded fairly easy at a later date. They are also salted so its more difficult to get useful information out of.
Though In hindsight I should have used SSO or another auth provider instead to handle users for me. In another work project, I implemented Federated user authentication using Cognito and Active Directory. If I was to do this again I feel this is the best approach.
During development one of the major hurdles I had was the lack of HttpContext. In .net Framework it is exposed as a static class that can get the current request. In net core, it is exposed as an injectable class. But when I went looking for this change the documentation didn't have the information available…
Another issue that appeared during development was the touted “cross-platform” of net core. I use a MacBook when I do work outside the house. Which should be fine, right? Net Core runs on both. but Opening files and working with the environment is different. MSBuild also had a big change while I was working on the project that made the application build on one OS but not always work on the other. Later versions fixed this so its no longer an issue.
The project is working and more than a minimum viable application, however, there is a significant amount of work left to do. The application can be found here. As it is only a side project it doesn't get all the attention I could be giving it, so there are still bugs.
