My Rants and Raves about technology, programming, everything else...
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.
In case you don’t know, at each stop of the http://hwroadtrip.com I’m doing a live recorded podcast as well as an hour talk about ASP.NET Core 1.0. We’re feeding everyone and giving away some great prizes by our sponsors including Pluralsight and Infragistics!
If you want to get the code from the ASP.NET Core 1.0 demo, I’m uploading each city to a common Github repo:
Now Angular 2 is in early beta and ASP.NET Core is in RC1 so I am taking a risk. I’m going to have a live webcast and I’ll build an Angular 2 app in an ASP.NET Core application. Come watch me walk the tightrope. No promises.
UPDATE: The webcast went great and you can now view all hour and twenty minutes of it on YouTube. Wasn’t perfect, but I hope you can learn a bit from it. The source I used in the webcast was from my re-write of my blog in ASP.NET Core. You can find that here on GitHub: