Yesterday, I realized, that it's been almost 2 long years since my last post. A lot has happened in that time and while migrating this blog to ghost, I reflected on some older posts of mine and noticed how things got easier.
Since most of my posts are basically about me struggling with technology and finding solutions or workarounds, it means that many of them are outdated by now. The question (also for me) arises, which issues wouldn't happen today anymore, and which solutions would be different and hopefully easier.
I classified the posts, which I feel like they deserve a short update, into the following categories...
Linux Tools on Windows
- Hyper-V error "IDE/ATAPI Account does not have sufficient privilege to open attachment..." (2012)
- How to Forward HTTP Requests in Windows 8 to a Hyper-V VM (2014)
- Vagrant on Windows with gulp-watch and similar file watching tools (2016)
Sure, these posts are about Hyper-V, Vagrant (and VirtualBox). But why did I use those tools? It was basically, because I needed both, Linux (mostly bash) and Windows. On one hand, I needed Visual Studio for work related things, because most of my projects were related to C# development. On the other hand, when I was experimenting with side projects, it was often times with open source tools which expected a bash, and Linux or MacOS (at those times still OS X) environment.
While nodejs, for instance, got much better at working on Windows, with Windows 10 came the WSL (Windows Subsystem for Linux). To my surprise, latest since the 2017 Fall's Creator Update, it can do suprsiginly a lot. Sure still not everything - go ahead check out the ~1000 issues on GitHub - but for me it's great. At work (currently apaleo) we have developers using Windows, MacOS and Linux machines. Originally we had to duplicate the scripts to set up the environment for bash and PowerShell. But since the mentioned Windows 10 Creator Update in Autumn 2017, and the possibility to interact with other Windows applications from the WSL, we could throw away our PowerShell scripts and are relying solely on bash scripts, since they also work in Windows.
I have a gist how I set up my bash on windows in case you want to check it out. It will be also attached at the end of this post.
Docker on Windows
This is a subsection to the general Linux tools on Windows. One of my last posts in 2016 was Vagrant + Docker = Rainbows + Unicorns. Back then, I thought it was genius. Already at that time you could get an installer with VirtualBox and docker, but my solution was more raw, that's why it was better (well at least in my mind). 2 years later, we have an official supported docker on Windows based on Hyper-V which has support for mounting volumes connecting networks, ... And, native support for Linux docker containers on windows is supposedly coming - can't wait for that.
In the gist about my bash on windows setup, you can also find, how I enabled docker within the bash - just create a link of
docker-compose.exe without the file extension, and all tools you are used to should work.
sudo ln -s /mnt/c/Program\ Files/Docker/Docker/resources/bin/docker.exe ~/.local/bin/docker
sudo ln -s /mnt/c/Program\ Files/Docker/Docker/resources/bin/docker-compose.exe ~/.local/bin/docker-compose
C# in Linux
What to Consider when running ASP.NET MVC 4 in Mono is now pretty much irrelevant. With .Net-Core 2.0 out ASP.NET Core 2.0 works pretty much the same way on Windows, Linux and MacOS. As I mentioned earlier, my colleagues and I develop apaleo on different environments and in the end it's running in Linux containers. So far I couldn't recall a case where code or libraries would work in Windows or Linux but not the other platform. The framework Microsoft built is really amazing and easy to use.
Request Authorization in ASP.NET Web API in Mono - there are actually 2 aspects to this post.
- Issues with the session object in mono. Definitely should be fine in ASP.NET Core. It's also possible to store the session on a central place, like an RDBMS or Redis, in order to share it across multiple processes running.
- Authorization via sessions and cookies in the first place. ASP.NET Core has 2 aspects to authorization and authentication. There is ASP.NET Identity, which consists of some services, EF Core extensions, ... to store users correctly in your application. And there is the IdentityServer which is more about issuing tokens and has a middleware to again read and validate those issued tokens. The IdentityServer is really a centralized user management system for multiple micro services, with libraries to handle those share users on each micro service. We actually use it together with ASP.NET Identity which basically matches some IdentityServer interfaces quite well (or vice versa). ASP.NET Identity than mostly provides database back-end for the stored password hashes and salts, ... which can be used by the IdentityServer to manage users and issue the correct tokens.
Considering both parts, the Session object should be fixed by now, but I'm not convinced, that we actually should be using sessions, since OAuth tokens seem to work much better.
The last 2 posts in this category are basically a shorter and longer version of the same topic, about connecting to Oracle:
- How I managed to connect from Mono in Linux to Oracle (2014
- How to connect Mono in Linux to Oracle (2014)
Actually, I don't know what's the current state of connecting .Net Core applications to Oracle in Linux nor Windows. The reason is, that PostgreSQL, which got so much more traction over the years, became a fairly safe choice as an RDBMS besides SQL Server and Oracle. And with version 10 it got even better, with more features for larger loads of data. Additionally, it's so easy to deploy it locally for development or on a build agent, just run the docker image, they even provide a super tiny alpine based image.
Npgsql, the driver to connect from .Net to PostgreSQL, works with many different ORMs, including EF Core. Npgsql doesn't yet have support to map all the rich features of PostgreSQL, but a lot is supported already. For instance we're using right now the
HStore (just by defining the property as a
Dictionary<,>) and also arrays work quite well.
Angular(JS) and TypeScript
The support for TypeScript is phenomenal. It's just amazing how things almost didn't seem to change at all from 2012 to 2015. Back then, I wrote TypeScript Development in Practice, one of my most often read posts, which just confirmed that it was really a big pain for many people. Fast forward to now, it's so much joy, but more on that in a separate post.
Update - the separate post is here: The State of Angular and TypeScript Development in 2018
My Bash on Windows configuration ...