As many of my readers already know, I've become enamoured with Vue.js. Because of this, I've been using it more and more on projects.
To start this workshop, I'm starting with my home town of Atlanta. On January 16-18th, I'm having a three day workshop to teach how to build a website using ASP.NET Core 2.2 and Vue.js.
This time I was in Ede, Netherlands for the first Techorama outside of Belgium. As usual, the team did an amazing job! Here are the slides and code as promised from that event:
I've been advocating using NPM for a client-side package manager in the last few months since Bower support has been depreciated. And while this works pretty well (using Scott Allen's UseNodeModules middlware) to allow you to just point at the NPM folder.
Of course, for production, this isn't a great solution. I've been showing people to use Gulp or WebPack to copy only the files you need in production. But for development, there is a problem: Intellisense.
Just got home from Music City Code conference had a great time catching up with attendees and other speakers. If you haven't made it to this great Nashville event before, plan for next year. It's well worth it.
As promised, here are the slides and code from my talks. I did talks on "Enhancing Web Pages with VueJS: When You Don't Need a full SPA" and "Versioning APIs with ASP.NET Core 2.1". Here you go:
In case you haven't been following on Twitter, you might not know that I've been working on a Vue course for a couple of months now. This particular course is now available as an Early Access model I'm trying out.
Instead of waiting and releasing the whole course, I'm publishing the course module-by-module. The idea is that Early Access gives you access to each module as I finish them.
Thanks to everyone who came to my webcast today! As many of you know, Bower is depreciated so I've been looking at the different ways to move to other solutions.
In the webcast (which will be streamable soon), I discuss using NPM, Yarn, LibMan (an upcoming tool for Visual Studio), and Gulp to get and package your client-side assets.
As I've been teaching ASP.NET Core for a while now, some things I've been saying I've taken on faith. One of these was that building a Configuration Source (a provider that can read configuration and feed it into the configuration system) is fairly easy.
With a break in building my Vue course, I was curious so I decided to build a configuration source that I hope no one uses. It is a configuration source that reads the AppSettings in a web.config file. This is a thought exercise, not a recommendation.
In my Pluralsight courses1 on ASP.NET Core, I show how to use JWT Tokens to secure your API. In building a new example for my upcoming Vue.js course, I decided to only use JWT (not cookies and JWT like many of my examples are).
But I kept getting redirects on failure to call an API made me realize that I wasn't sure how to make JWT the only provider. After some fiddling I figured it out. This blog post is mostly to remind me of how to do it.
Ok, please tell me how stupid this is. It's apt to be pretty stupid but I have a point to it. I'm trying to separate the ideas of prototyping quickly from preparing for production.
I've been using Bower to do examples of client-side dependencies. Bower is depreciated so for new dev, I don't want to recommend it (and VS2017 has removed it too). Bower is clean as you don't have to introduce a bunch of ideas like gulp or npm scripts to get someone with a working example quickly (Bower's .rc file let's you tell it where to put the dependencies). I want to do the same thing with NPM.
I'm getting around to this a little late, but late last month I had a great time presenting in Charlotte's Enterprise Developer's Guild. I showed them how ASP.NET Core 2 works.
They had a full house and I got to talk about how ASP.NET Core 2 and .NET Core itself works. Great questions about why bother with ASP.NET Core and how it's related to the new "Core" moniker that Microsoft seems to be putting on everything (answer is, probably no relation, just a marketing group that is latching on to the name).
I feel like the job of software developer in the last 20 years has been to decouple. Whether it's dependency injection or building modular systems, or even the new trend of micro-services; coupling has been the killer of everything good in software development (maybe).
In many small ways, I find that trying to fit in small disconnected sets of functionality into the ASP.NET MVC Controller to View mechanism can be overwhelming. In some cases I'll need something that is completely separate from the logic of the controller. Luckily ASP.NET Core comes to the rescue.
Back in ASP.NET 4, I really liked the way that it supported running migrations and seeding of the database for you. But in ASP.NET Core and EF Core, that hasn't come to the table yet.
I doubt it actually needs to happen because since ASP.NET Core gives you much more control over the life cycle of the web project. In Entity Framework Core, I've been using an approach to run migrations and seed the database that I kind of crufted together in the Betas. I don't think it's working.
With the New Year coming, I thought I'd look back at the last year in my life. Warning this is going to be technical and personal, that way I can turn 50% of the people off with every sentence...just a different set of people with every paragraph ; )
I've had a tough few years, but overall this has been a good year in the Wildermuth house (removing entirely our Political climate which I won't talk about here). It's not been easy, but it's been good. That's the way it usually is for me.
In my ASP.NET Core 2.0 Pluralsight course, I specifically teach how to build DbContext classes and the POCO classes that go with them. But I've been getting many questions about how to work with existing databases, so I thought I'd explain it in a blog post.
I purposely teach the DbContext and POCO classes first because I want the students to understand what is happening. The process of using it with an existing database generates sometimes a large amount of code.
Bower is still being maintained, but they're recommending that people move their projects to Yarn and Webpack. As you may not know, I'm on a sort of campaign to avoid the complexity of something like Webpack until you really need it.
In addition, some libraries aren't supported by Bower (e.g. Angular 2-5) so I wanted to finally end my use of two package managers when I needed Angular. My decision has been to use NPM instead of Bower since that's where Angular lives at and is a huge ecosystem thanks to node.
This blog has existed for 15 years now and I've moved it from server to server, service to service, in many forms over the years. As I moved servers, one of my biggest pains was copying all the images and downloads from server to server.
My site code took up about 1% of the space, and all those embedded images and downloads took a majority of the space. I was sick of it, especially on deploying the site (or saving the site in Git), so I decided to switch to storing it in Azure Storage (or AWS if you prefer).
When ASP.NET Core 2 shipped the early previews, I knew one large change was going to be the Identity subsystem. The Identity for ASP.NET Core 1 worked ok, but the setup was very confusing with identical configuration is more than one place.
I’m happy to say that in ASP.NET Core 2 it’s much better. Implementing JWT Tokens for APIs was more confusing than I liked back when I wrote my Implementing an API in ASP.NET Core course for Pluralsight. I was hoping that it changed to simplify the way it works.
I’m very excited that the v2 of ASP.NET Core is now released. Married with Visual Studio 2017 Update 3 (or VS Core), it is now a maturing platform.
I really like what the team has been doing since the release of 1.0. They seem to really have thought about the pain points of the initial versions and worked to eliminate as many as they could.
Doing a talk on a preview (ASP.NET Core 2.0) on top of another preview (VS 2017 Preview) is always risky, but it went well. Lots of great questions and hopefully I convinced some of the attendees to give it a try.
I’m working on an update for my ASP.NET Core course for version 2.0. One major change is to use Angular (v4 probably) in the new course.
My challenge was to get Angular and ASP.NET Core to work together. I like the idea about Angular-CLI doing all the boilerplate since setup is a bit of a headache. Should be an easy win-win. Well…
I am sure that many people like me are digging into ASP.NET Core 2.0 and curious about what has been changed. I’m going to start with the very start of your ASP.NET Core project, the program.cs.
Digging into the meat of ASP.NET Core 2.0 might lead you to identity, the better .NET Core support, and other changes. But I think the startup is where you can start to see the platform mature.
|Vue.js by Example (New Lower Price)|
|Bootstrap 4 by Example (New Lower Price)|
|Intro to Font Awesome 5 (Free Course)|
|Building an API with ASP.NET Core (New Course)|
|Building a Web App with ASP.NET Core, MVC6, EF Core, Bootstrap and Angular (updated for 2.2)|
|Less: Getting Started (New)|
|Using Visual Studio Code for ASP.NET Core Projects|
|Implementing ASP.NET Web API|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||v4.0.30319||Runtime Framework||x86|
|App Path||D:\home\site\wwwroot\||Runtime Version||.NET Core 4.6.27514.02|
|Operating System||Microsoft Windows 10.0.14393||Runtime Arch||X86|