Tagged with asp.net core
I'm working on an example to explore some more complex modeling in EF (for SQL and NoSQL) but that's not ready so I thought I'd use it as a bed for some Validation testing I'm doing. The result is some exploration of the FluentValidation project that I haven't had time to dig into until now.
Validation is an interesting exercise in ASP.NET (Core) and trying to get it correct is quite difficult. Ultimately in this day of SPAs and mobile apps, we need a solution that handles the client and the server. If you don't validate on the server it just doesn't matter.
FluentValidation is a replacment for the existing validation attributes (DataAnnotations) that you might already be using. The idea is to separate the validation from the classes. To be clear, this doesn't replace setting up your Entity Framework types with Fluent API this is about server-side validation only. Think of it as a clearer way to define rules for validation of your models or DTOs.
Endpoint Routing was introduced in ASP.NET Core 2.2 but has been made a first class citizen of ASP.NET Core in 3.0. While you're old projects will continue to work without it, upgrading to Endpoint Routing will improve your applications.
Endpoint Routing is a system to handle routing across different middleware systems (e.g. MVC, Razor Pages, Blazor, SignalR and gRPC). By having endpoints that work with each other, you can think of a system more holistically then having terminal middleware that don't talk to each other. Let's see what that actually means in practice.
If you've seen the new project template, you've probably already noticed that setting up RazorPages and MVC look a bit different. First in the ConfigureServices:
I'm finally getting around to looking at updating my examples and courses to 3.0. This post is based on .NET Core Preview 8 so this might change in the future.
There are a number of great walkthroughs for moving your ASP.NET Core 2.x projects to 3.0. So I don't want to repeat that. Instead, I want to talk about what's happening, not just a list of things to do.
To discuss these changes, i'll talk about a project I'm current converting (CoreCodeCamp which is the basis for the Atlanta Code Camp), though it's a branch that likely won't be deployed until after the event.
If you've viewed my new "Designing RESTful Web APIs" course on Pluralsight, you've already encountered my small API that I use as an exammple. While the course is platform agnostic, i'll admit that I built it with ASP.NET Core (2.2).
For this new project, I decided that running in a container would be useful as it's pretty self-contained and should just return to it's initial state when the container is restarted. While I won't be releasing that source, I did learn a lot about debugging in a container that I thought I'd share.
I started this new project and opted into using Docker in the project:
ASP.NET Core 3 seems to be taking a similar tact to version 1 as it is adding a lot of functionality and phasing it in with different previews. While a lot of the articles seem to be focusing on the non-ASP.NET features (e.g. WPF, WinForms, etc.), I thought it would be nice to let those of you who are ASP.NET devs know what is in Preview 6 just for you.
It feels a lot like the ASP.NET MVC/API side is being treated as mature and stable as there is are not a lot of surface changes. Microsoft does seem to be doubling down on Razor Pages and Blazor. It feels like they want .NET Core to be a good fit for different styles and backgrounds of developer. This release is no different.
Let's take a look at the details:
I've been writing demos for Vue, Angular, and React for my SignalR micro-courses over on my Wilder Minds site. For Angular and React, I started out with the the SPA templates, but I found them confusing and hard to do a minimal example.
I tend to suffer from "You Moved My Cheese" and wondered if I was throwing the baby out with the bathwater. Let me talk about my experiences creating projects with and without the templates.
My initial problem with the templates is that they are using node under the covers to handle the build of the project. I hate that these details are hidden from me, but I'm confortable with having a console window to keep a watch on my webpack-based projects (the Vue CLI, Angular CLI and React CLI all wrap webpack).
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.
I'm going to assume you have used the Vue CLI and ASP.NET Core before. So I'm skipping a lot of steps like creating the ASP.NET Core project. I'm also going to assume you've opened up a console before and ran commands. Lastly, I'm assuming you're using Visual Studio (though shouldn't be much different if you're not), and that you have the Vue CLI installed.
At my training site (Wilder Minds Training), I'm working on a new kind of course for me. I'm calling them Micro-Courses.
The idea behind these new courses is that they are short and teach one very discrete skill. My first one is SignalR!
I will probably be adding more SignalR micro-courses for it's use in different SPA networks fairly soon. If you have a course idea that you would like me to make, feel free to contact me.
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.
The workshop will use the following technologies:
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:
Thanks for asking great questions and attending the sessions!
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.
I've noticed that Visual Studio 2017 only seems to notice files in the wwwroot folder. After trying a bunch of things, I think I found a solution. If you open the CSPROJ file and add this section to point at the node_modules directory:
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.
This course is my first try at this. Because Early Access means students will be something like the Beta testers for the course, I can release the course at a discount. So far I've been able to release the first six modules and I'm pretty happy with how the course is coming along.
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.
You can get the code I showed on Github:
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 order to be a Configuration Source, you must derive from the IConfigurationSource interface. You could implement this interface directly, or if your configuration is file based (like the one I built), you can simply derive from FileConfigurationSource. This class deals with most of the problem of opening and reading a file. Since my Configuration Source is to read the web.config, that's perfect.
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.
After help from @khellang - I found the real culprit. See new section at the bottom.
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.
Here is the idea. Instead of writing a script or using gulp to move the files, I'm thinking of using UseStaticFiles to just allow node_modules directory to be available to client-side development. My expectation is that this is a development-only idea and will allow you to get up to speed quickly. But when you're ready to deploy, you'll need to do the harder work of writing a NPM script to copy only the files you really need.
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).
Here are the materials from the talk:
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.
The ServiceContainer in ASP.NET Core is great, but we tend to worry about constructor injection in most cases. But once I realized I could inject directly into Razor, I realized I had a good solution for my needs.
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.
Back when I realized that you couldn't just use the seeding and initialization from EF6 in Entity Framework Core, I looked at a few solutions and pick and choose what made the most sense to me. This is what I had come up with:
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.
One of my favorite lines from music is "Every five years or so I look back on my life, and I have a good laugh." 1 That's how I have felt most of my life. This year is no different. One constant is my life is that I'm constantly trying to learn something new, whether that be technology or anything else. Here are some categories of my life that I'm looking back at:
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.
Before you get started, you'll need to make sure the project has some required packages and tools. If you open up your .csproj file, you'll need to add EntityFrameworkCore.Design and SqlServer (or whatever database you're using) as references:
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.
UPDATE: Seems that Yarn isn't tied to Webpack like I thought. Sorry for the confusion. I've removed that from the article and will have a new article on Yarn soon.
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).
So when I wrote my .NET Core version of the blog, I decided to bite the bullet and start storing them there. But I wanted to enable it directly from Blog authoring. I'm using my version of Metalog API middleware I wrote to do this (see more about that at Github). But I needed a small service to actually support saving new images to the storage service.