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.
I may be very late to the party, but once Gulp 3.x stopped working with recent versions of Node, I've been forced to update my projects to the newest version of Gulp.
I was hesitant to learn it as I often think of Gulp as just a side-line tool that I use for production. Luckily for me, the new Gulp is actually simpler and more intuitive. I wanted to write a quick blog post explaining how I converted them.
I was delighted to spend some time today at Connect.Tech conference. Great web conference and it was packed. So many excited people who wanted to talk about web technologies!
I saw some great talks before mine. I tried to convince the audience that Vuex would simplify not complicate their Vue projects. Hopefully I succeeded.
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.
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.
I started writing services in websites back in the .NET 1.0 days. Originally I was doing just POX (Plain Old XML) services in a very crude way so we could get the job done for our internal systems back in the early 2000's.
This means I've been through the "new tech" crazy with services for a long time. I've spent much of the last year digging into different tech for services to interact with websites (though many of the same issues are for rich clients and IoT). I'm not done and don't know how right my assumptions are yet, but I thought I'd try to start a conversation.
I've been updating the Atlanta Code Camp website to improve our administration workflow. With the Call for Speakers coming up soon, I wanted to make sure we had a good way of picking only the best talks.
One of the things I've done is move it to a Single App with Vuex at the center of it. But I ran into an oddity with Vuex that I thought I'd share.
There is a lot of buzz around the internet about Vue.js 3.0's announcement about a new composition model. There are a lot of questions about it and I think much of it is 'they moved my cheese' more than 'they're breaking everything'.
So let's talk about it...
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.
As you might have heard, GitHub has created it's own package registry. On the face of it, it might just feel like an opportunity to get more 'buy-in' into using GitHub, but I think something else is going on.
While most people are focusing on the support in NPM for the GitHub registry, they're actually supporting a package repository for a handful of package services. These include Nuget, Ruby Gems, Maven, and Docker. Why are they doing this?
One of the first times I started working with Vue, I was concerned about it's long-term success. I was coming from Angular and their ecosystem is huge.
I was delighted to find that the ecosystem is pretty varied. The Vue website tries to make it easier to find the kinds of libraries and components that you might need. It comes from two places on the website.
I have to admit, my first experiences with React several years ago were meet with a lot of cynicism. The idea of mixing JavaScript and Markup made me clutch my pearls to the core.
Now I know that you can use React without using JSX, but I think that is missing the point in a lot of ways. Of course, I'm not a React expert so I am sure you'll let me know how wrong I am ; )
If you're building larger scale Vue objects and you're not using Vuex to centralize your state, please stop and go learn Vuex. Really.
For those of you still here, sometimes it's helpful to be able to monitor state changes to perform other tasks. For example, to send messages or communicate with servers that aren't about state (e.g. SignalR is a good example). That's where Vuex plugins come in.
A Vuex plugin is a simple function that is called once during the setup of a Vuex store. Typically you'd just create the function/arrow function taking an instance of the store:
export default store => {
};
Inside the function, you just want to subscribe to changes to the store as you need. An easy way to think about this is to use subscribe to a mutation:
I had the opportunity to speak at the Atlanta Vue Meetup recently. This was a great group of people who had mostly had experience with Vue.js.
I'm so used to having to try and convince people to use Vue, that this was a fun talk to get people interested in using it in different ways than they are used to.
I had a great time presenting to the Atlanta .NET Users' Group last night. I talked about where I think Vue.js.
I got to espouse my opinion (again) about SPA being large monoliths instead of building 'islands of functionality'. I learned a new achronym too, "Multiple Page Apps" or MPAs for this type of client-side dev.
The Vue team has been working hard. Much like Angular, the Vue team has a command-line interface (CLI) to help develop projects with Vue.
If all you're doing is building a SPA, the CLI can really help simplify setting up a project. But is that all you should be doing with Vue?
If you're not in the south part of the Netherlands, you might have missed my most recent appearance last night. Great hosts, guests and sponsors make the night and easy and fun talk.
After a long day at Techorama NL, I was whisked away to Eindhoven for a talk at the .NET Zuid group (e.g. Southern .NET Group). I was able to show them the basics of Vue.js and pontificate about my continued hatred of the phrase "Single Page Applications".
Had a great week here in Warsaw! Got to see some great sights and great developers!
Thanks to the great team behind .NET Developer Days! Great group of attendees that asked some great questions.
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 know I am not going to make everyone happy with this post. I've been hoping to not have to make this post, but Entity Framework Core has finally added support for Lazy Loading, so it's time.
This problem is not new. Entity Framework (not Core) also has this problem. But it's far easier to accidentally do this in that version. Luckily, Entity Framework Core has made it harder to inadvertently turn it on. Let's see what's wrong with Lazy Loading in Web Apps.
Not John BoltonThe notorious quip by Mark Twain came to mind today as I was reviewing comments to my recent blog post about Blazor, a lot of the comments talked about WebAssembly being the death of JavaScript.
The fact is that we've all been here before. In fact, we've been here many times. And I, for one, don't want to simply see WebAssembly as something to replace JavaScript. Here are my thoughts.
In case you haven't been following the news about WebAssembly (e.g. WASM), it's a new way to build something akin to bytecode for the browser. The latest versions of most browsers now support it including Chrome, Firefox and Edge.
Microsoft has built an experimental release of something called Blazor that builds web projects in WebAssembly so you can write all your code in C#. But after playing with one of the builds, I'm starting to think about who this really is for. Let's delve into what WebAssembly is and then how Blazor works to explain what I think.
Since I do a lot of web development and teach web dev on the Microsoft platform, I spend a lot of time in tools that are node-based. If you don't know already, gulp, grunt, webpack, etc. all use node to run themselves.
Because of this, Visual Studio tries to be a good guy and pre-installs Node with Visual Studio. When you use some of these tools in Visual Studio, they just work. No more having to tell dev's to go install something to get them to work.
As many of you know, I'm a Pluralsight author and I've been writing courses for the site for a long time now. I have over twenty courses to my name. While my ASP.NET Core courses get a lot of attention, I've been trying to help people get started in general web development through my courses.
To this end, I wanted to answer the question I get a lot of times about how someone would transition into web development from desktop or other programming (or even completely new to the field). This post's purpose is to help people see what Pluralsight courses (mine and others) would be a good primer into web development.
I’ve been feeling kind of old school lately. I’ve been pining for just writing client-side code and watching it work. That’s not the world that we’re in these days.
Writing web apps has become complicated. Transpilation has made some thing really awesome, but it also has complicated the field. Webpack, Browserify, Babel and even TypeScript have all make our lives easier and awful at the same time.
| Application Name | WilderBlog | Environment Name | Production |
| Application Ver | v4.0.30319 | Runtime Framework | x86 |
| App Path | D:\home\site\wwwroot\ | Runtime Version | .NET Core 3.0.0 |
| Operating System | Microsoft Windows 10.0.14393 | Runtime Arch | X86 |
