My Rants and Raves about technology, programming, everything else...
When I built this blog, I wanted to get comfortable with Angular 2. I shoehorned Angular 2 into the contact page as an excuse to use it. Never a good decision.
My goal with replacing Angular 2 was to remove a lot of the complexity. Getting Angular 2 up and running requires a lot of moving parts. By removing Angular 2 I was able to eliminate a lot of pieces of the build. These pieces were making my builds on Azure App Services brittle so it had to go.
Finding the project after upgrading it, I had to look for those points of contact I had gotten comfortable using. The upgrade wasn’t painful (look back at those Beta 7-Beta 8 upgrades for that story), but knowing where they moved your cheese is important. Hopefully this post helps you with the same issues.
I’ve been watching the changes from using the project.json file to MSBuild (e.g. .csproj) for a while. Instead of manually updating it (which you can do with the SDK alone), I decided to just open the project in Visual Studio 2017 and let it update it for me. What I ended up with was a backup directory with my old project.json file and a couple of new files:
This new, six-hour, course covers the basics of building REST APIs with ASP.NET Core. Whether you’re just exposing your data via REST, or building microservices, this new course should have you covered.
Here is a preview of what the course contains:
I run this blog and other sites on Azure App Services (used to be called Websites). As you might know all that code is open source on GitHub and I use that code to deploy directly to Azure.
I use the GitHub deployment that Azure offers so that every time I push a change to my master branch, it creates a new deployment for me. It's been pretty great, except...the deployment is pretty slow. Normally the speed of this deployment wouldn't matter a lot, except of course when I push a bug out to 'live'. Then the speed really matters.
I was perusing the builds and noticed that a build was taking 1014 seconds. That's an ASP.NET project with very little client-side building (e.g. no webpack or similar). Getting the source, doing the restore, building the project, and deploying it all shouldn't be taking 16+ minutes.
Some of my students were using ASP.NET Core 1.1 in their walk through using my Pluralsight course and I was unsure of how much of a problem that was going to be, but so far no problems really.
So to upgrade my WilderBlog project, I did two uneventful things:
I’ve known Glenn Block for a long time now and I’ve heard about the ScriptCS project he’s worked on for a long time. I’ve never had time to dig in until now.
For the uninitiated, ScriptCS is a scriptable environment that uses .NET and C# for it’s platform. It makes writing simple scripts easier if you know C# already. It has support in several different editors, but I’ll talk about how I used it with Visual Studio Code since that’s my new favorite toy.
Before I can learn something interesting I have to have a job to do. In this case I had a simple problem: I needed to clean up Visual Studio projects. I create a *lot* of projects. Whether they are examples for courses, talks, or for my own investigations, I end up with projects lying around everywhere. Before I could share them, I want to clean them of temporary data (e.g. bin and obj directories, et al). Now that I use GitHub for many of these projects, cleaning isn’t that important but even in that case I still have a lot of disk space devoted to these files, so I still want to clean them up.
So I’ve been on a mission of sorts…I’m looking for the right size framework for some of my web development. I know what you’re saying, “Aren’t you suggesting Angular2 for everything”? No, no I’m not.
I just made a bunch of you excited. You React, Aurelia, and Ember enthusiasts and now probably foaming at the lips ready to tell me to use one of your frameworks! Hold off for now. Let’s talk about it.
The problem for me is fairly simple, I don’t want to build a Single Page Application (e.g. SPA). Yeah, I know.
I had the good fortune of being picked to speak at the Boston Code Camp for their winter event. As some of you know I used to live in Boston and it was a fun few days of reminicence.
The talk that got picked was ASP.NET Core Logging. As I've discussed on this blog, I'm a fan of how the logging is implemented.
Thanks for coming to my talk if you were able to come. The talk wasn't recorded, but I'm happy to share the code and the slides:
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.
If you’re developing in Visual Studio 2015 and running on Windows, enabling SSL is really easy. Just open your project settings and look on the Debug tab. You’ll see a checkbox to enable SSL in IIS Express (make sure you have “IIS Express” selected in “Profile”
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 ; )
Originally, the old Atlanta Code Camp utilized MVC Areas to handle the different years that we held the code camp. I wanted to keep that functionality (and even move prior years to the new site) but I wanted to avoid Areas. I like areas for real site areas, but it felt like a hack to use it for separate years. In addition, the Areas forced me to copy/paste each year and modify them every year.