Early thoughts on asp.net core
The more I play with asp.net core (RC2 at time of publication) the more I’m liking what I see. I still don’t see a use case for me on OSX or Linux yet, so the portability isn’t a massive thing for me. In my mind the windows use case for asp.net is fantastic and licence costs aside the setup and configuration is so simple on Windows I can see little benefit from venturing elsewhere.
Application settings
There are still things I don’t particularly like about core, including recent changes. One of these is accessing settings file. In ‘current’ asp.net (must be careful not to call it ‘old’ or ‘legacy’) is the ConfigurationManager class made accessing your settings from web.config both simple and succinct. Now though, web.config is no more. Why, I’m not entirely sure. Maybe it’s the flexibility of having multiple configuration sources or not mixing application settings with its configuration. Regardless, you’ll now almost certainly be storing your configuration settings in a JSON file, with appsettings.json seemingly becoming the convention.
In early releases of core this was similarly easy to access settings from a JSON file for example simply by using the IConfigurationRoot dictionary (provided you added the source in the startup configuration). However, in the latest builds (RC2 onwards) this has changed. You now need to strongly type your settings via POCO classes and access these settings through the IOptions
State of flux
So at the time of writing asp.net core is at release candidate 2 stage. However, there are still some big, big changes going on. The underlying .net runtime has gone though a massive shift of late with the introduction of the much cleaner dotnet CLI. This is a big step forward IMO but not something you would normally expect in release candidates. This still feels much more beta than RC to me so be mindful that there are still lots of breaking changes going on.
Another example of this is that having followed the recommended guidance on setting configuration settings access up the “new way” I was still hitting issues. Turns out that a namespace shuffle occurred in the core libraries and was largely undocumented until a couple of days ago (https://github.com/aspnet/Announcements/issues/180). Following the new namespace import and package restore and things are now working fine.
As I say, core is still moving forward at a rapid pace with both minor and major changes causing breakage for the developer and at the same time invalidating lots of the already limited documentation.
Sending email
Another hurdle is the lack of System.Net.Mail in core. This means the tried and tested way of sending email is (at the time of writing) not currently available. That said, there are alternatives which are easily substitutable, including MailKit. A good overview of Mailkit using core can be found on Steve Gordons blog: http://stevejgordon.co.uk/how-to-send-emails-in-asp-net-core-1-0
Positives
Despite the above I am enjoying working with aspnet core. I like the changes to the dotnet CLI, the new startup configuration is nice and the ‘DI everywhere’ approach is very powerful (and beautifully executed with much greater simplicity than most other DI containers). I like the new IHostingEnvironment interface which provides strongly typed access to your environment including
|
1 |
Env.IsDevelopment() |
Which sees an end to the old #if debug compiler directives and the problems/ugliness that brought about. The middleware pipeline is really well put through (feels pretty much like a direct port from OWIN) and although I haven’t done much performance testing yet, the startup and shutdown times in Visual Studio feels very, very quick.
Final thoughts (for now)
All in all though, I’m really enjoying the freshening up on asp.net. The more you use it the more you realise how much has changed and the size of the job at hand.
I'm a gadget loving code-junkie who loves to program, create websites and try out new stuff. Married, with two young daughters I am also a keen marathon runner and fitness enthusiast.