My Rants and Raves about technology, programming, everything else...
I’m starting to play with the Preview of RC2 (nightly builds). It’s not time to do it for most people, but I’m trying to prepare for the update to my ASP.NET Core RC1 course on Pluralsight.
I have a couple of small library projects that I created when I build the new website. Since they are both pretty small and have xUnit testing, I thought it might be a good place to start.
I started by branching the projects so that I could merge them after RC2 shipped. The one I’ll walk you through is the MetaWeblog project. This is a small middleware for ASP.NET Core to support the Meta Weblog API to support Windows Live Writer (and other tools) for writing your blog items. You can see the comparison between the master and the RC2 branch here:
If you’re not paying attention to Twitter, the ASP.NET Standup or the Github repositories, you might be missing a big change coming to ASP.NET Core. Now is time to add your opinion so that Microsoft can make the right move.
I suggest you read up on the change and make your voice heard if you have an opinion. My opinion is pretty clearly stated in the GitHub discussion so I won’t bother to repeat it here, but I’m asking you to get involved.
Microsoft has decided after the RTM of the ASP.NET Core framework to phase out project.json and use MSBuild for build data. They’ve not decided whether to keep the NuGet dependencies in a pared down project.json (maybe renamed to nuget.json) or whether to just allow for a command-line action like “nuget install dependency --save” to mirror what other package managers do.
Before ASP.NET Core, our world was split between ASP.NET MVC and ASP.NET Web API. In ASP.NET Core that changes to a single model in ASP.NET MVC 6 for handling requests, whether they end up returning data or views.
There is a Web API Shim to bring over old controllers for use in ASP.NET Core. But for new projects (e.g. greenfield), I’d suggest writing your API controllers without the shim.
In case you haven’t looked at View Controllers, Let’s look at a simple example from my WilderBlog project:
We arrived at Techorama, I did a couple of talks and recorded our Belgium podcast with the great Bill Wagner. That should be up this weekend.
We have just over half of the stops left in the trip. If you want a chance to see me record a live podcast and talk about ASP.NET Core, sign up for this free event in the following cities:
As you can see, I recently updated this blog. I wrote the new blog using ASP.NET Core RC1 (as related technologies) so when time came to deploy it, I had some issues.
At the time I thought it was Azure, but after testing with an empty project that worked, I figured it was probably something I did. In this post, I’ll talk about what I did to get it to work in Azure Websites.
There a couple of ways to do this. I preferred the publish from source approach. You can use the Visual Studio publish options too:
I recently added a logging provider to my open source project (WilderBlog). I know I shouldn’t have implemented a provider myself, but I wanted to see how the sausage was made.
The reality is that I should have used an existing library like Serilog or others, but digging into the logging framework taught be how the system works. I’m hoping to show you what I learned.
Before we get started with what I did, let’s talk about how logging works. In Startup.cs you can ask for the ILoggerFactory object which you can use to support different types of logs. For instance, here is the DebugLogger being added when we’re running under development:
When I created my blog in ASP.NET Core, I forgot about one feature that I used to help out some other Pluralsight authors by creating a quick top 100 list of courses. Because Pluralsight doesn’t really expose that data as an API, I didn’t want to hammer their service, so I had been using a memory cache to do it.
But when I moved the code over, I realized that the old, reliable Cache object was missing. Luckily I found it and like much of ASP.NET Core, adding it was simple and consistent. Let me show you.
First thing was to see how caching was being handled. Instead of having different caches, ASP.NET Core has an abstraction around caching and then you can support different types of caches. For me, it was a simple memory cache I wanted so I needed two Nuget packages:
A while back, I decided that this blog deserved a clean coat of paint and since I’m digging into ASP.NET Core, it was logical to re-write it. I wanted more than just to change the look, I wanted to make some real changes to the code and finally open source the code too!
Open sourcing the code required that I do a few things. First of all, I had to change any code that I would be embarrassed by (not a trivial task), but also make it so that much of normal secrets weren’t exposed by open sourcing it (e.g. connection strings, etc.). But as of now, I’ve done it. The source is available and the site is live! I am sure that there are issues with the site, but hopefully I’ll iron those out as they crop up.
My goal here wasn’t to build a blog engine. This isn’t a carefully designed and architected solution that is easily skinned for your site, but it should be a good start to understand how to build a site with ASP.NET Core and related technologies. You can see the code here:
As you might know, in ASP.NET Core, the MVC6 stack now includes the Web API functionality. Having a single stack has advantages and I’m happy they’ve converged the two stacks.
While working with early builds, I noticed the patterns for doing content negotiation weren’t working as expected so I defaulted to the MVC approach to REST APIs. In the RC1 build, it seems to be working as expected. Let’s talk about it.
ASP.NET Core gives you options. You could write APIs like I started to in earlier builds:
We’re in San Francisco today and I thought it would be a good time to write a quick update to the trip. As some of you know, we’re currently in the middle of a twenty-five city trip and so far so good.
Tomorrow night we do the event here in San Francisco (with the amazing Beth Massi as our guest) and I’m excited to do our sixth event. It’s been an amazing couple of weeks and we can’t wait for the rest of the trip to unfold.
Me and my wife are travelling to each city to put on the road trip and we’ve done events in Atlanta, Birmingham, Austin, Phoenix, and San Diego. I’ve had the pleasure of interviewing Jim Wooley, Todd Miranda, Rod Paddock, Joe Guadagno, and Tim Huckaby so far.