When building my ASP.NET Core apps, I usually enable the RequireSSL filter in production environments. But I’ve never went through getting it to work on my dev box as I thought it was harder than it actually was.
Effectively to get SSL running, I thought I needed to get involved in creating and handling certificates. Not really true.
I’ve been digging into ASP.NET Core for quite a while now (from the early betas through the current release). Recently I re-wrote the Atlanta Code Camp website using ASP.NET Core.
Through that process I’ve learned some new lessons about ASP.NET Core and this series of blog posts is going to talk about those lessons. I have no idea how many parts it will have, but I’ll post all that I’ve learned in building a site with real users ; )
I’ve been building some ASP.NET Core apps as of late and had to dig into how Dependency Injection works there. After talking with Julie Lerman a bit on Twitter about it, I realized that there might be some confusing things about how it works in ASP.NET Core, so I’m hoping I can add some clarity in this post.
One thing I like about ASP.NET Core is that since it is a new platform, I’m learning something new all the time. When I suggested to Julie to use DI in her example database seeder, but of course there were things I was missing and my suggestion would actually just leak a context object. Lets look at some of the default dependency injection in ASP.NET Core to see how it is supposed to work.
I know this was a “click-bait” post name, but so be it. I’ve been doing some small Angular2 in a recent project (rebuilding the new Atlanta Code Camp website) and I’ve been frustrated with the amount of ceremony. But I may be misunderstanding Angular2 so bear with me.
The problem for me is in the idea of SPA in general. SPA seems to imply monolithic apps but written in client-side web code. For a single, large scale application, Angular2 seems like it is just right…but that’s not what I do.
I’m really excited to announce that my popular Pluralsight course on ASP.NET Core has been updated to RTM. It’s been a long slog to update and I apologize for the delay but it’s ready now.
The course is so different from the earlier builds, that we’ve decided to retire the older course and create a complete fresh course. Over 60% of the videos had to be updated and the entire set of example code had to be changed too.
When I was a kid, I had the dream of building an immersive ‘video’ game. I thought the magic was going to be holography. My idea was a holographic skiing game. Of course holographic tech didn’t mature like I hoped it would.
So now that VR is having it’s resurgence, it’s made me think back to those days of old. In this post, I’d like to talk about the different devices I’ve had.
Like other posts, I am going to list all the changes I found but there are likely more that I didn’t run into. Feel free to use the comment system to add more as you like!
This day has been a long time coming but I want to congratulate the team at Microsoft for delivering the first version of ASP.NET Core! I’m very excited to start working with the bits on real projects.
If you haven’t had a chance to look at play with ASP.NET Core, it’s time! For the ASP.NET MVC and Web API users, the transition is pretty quick, but if you’re coming from ASP.NET Web Forms or another technology, there is a learning curve.
The shirts come in S, M, L, XL and 2XL but limited quantities of each. Please sign up below if you want win a shirt. We will be mailing them out by the end of July. Please note that we can only mail them to the United States and Canada.
We’re home. It’s a fantastic feeling, but we had a great time. I wanted to take some time to thank all the great attendees, guests and helpers that made this a great trip. We got some great podcasts and hopefully encouraged a lot of people to try out ASP.NET Core!
We took a lot of pictures and you can see some of them by clicking on the mosaic to the right!
With the release of ASP.NET Core RC2, Microsoft hit a major milestone. But this change isn’t a trivial one. It’s a big change.
Since I’m updating my Pluralsight course on ASP.NET Core, I wanted to get a list of changes for the new version. I figured I’d share all the changes I could find converting a stock RC1 project to a RC2 one. It’s a big list, but hopefully manageable. Please share in comments and changes I missed so others can be helped!
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.
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.
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.
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.
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.
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.
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.
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.
This time it’ll be using ASP.NET Core in a Docker container. In this shortish webcast, I’ll show you an existing project that uses ASP.NET Core to build a blog project (my open source WilderBlog example) and deploy it to a Docker container locally using the Docker tooling. I’ll also mention cloud providers too including using AWS, Azure and Google Cloud.
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.
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.
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!
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.
|Using Visual Studio Code for ASP.NET Core Projects (new)|
|Implementing and Securing an API with ASP.NET Core (new)|
|Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS|
|Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)|
|Best Practices in ASP.NET: Entities, Validation, and View Models|
|Front-End Web Development Quick Start|
|Lessons from Real World .NET Code Reviews|
|Node.js for .NET Developers|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||188.8.131.52||Runtime Framework||.NETCoreApp,Version=v1.1|
|App Path||D:\home\site\wwwroot||Runtime Version||.NET Core 4.6.25211.01|
|Operating System||Microsoft Windows 6.2.9200||Runtime Arch||X86|