Subscribe: CodeClimber
http://feeds.feedburner.com/codeclimber
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
angular bootstrap  angular  bootstrap  core angular  core  development net  end development  end  front end  net core  net 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: CodeClimber

CodeClimber



Climbing the Cliffs of C#



 



Preface to Frontend development with ASP.NET Core MVC, Angular and Bootstrap - Day 24

Sun, 24 Dec 2017 12:30:32 Z

On the last day of my 24 days of Christmas from my upcoming book Front-end Development with ASP.NET Core, Angular, and Bootstrap I want to share the preface to the book written by Mads Kristensen, PM in the Visual Studio team at Microsoft.

The web becomes an increasingly capable platform with each new browser release. Tomorrow’s new features become available to early adopters while yesterday’s stabilize for mass adoption. This ever-growing toolbox of HTML, CSS, and JavaScript capabilities seems to be accelerating and shows no signs of slowing down. In fact, it’s growing so fast that specialized tooling is required to take advantage of these new features – tooling such as WebPack and Gulp.

The amount of knowledge required to build modern browser applications is illustrated by the new job title “front-end engineer” – a term that didn’t exist just a few years ago.

In addition to the advances in the web platform, the server-side technologies powering the web are evolving as well. To provide the best experience for both end-users and web developers, the server-side platform must be ultra-fast, secure, cross-platform, cloud scalable and have great tooling.

Most web applications consist of client-side code running in the browser and server-side code running on one or more servers. So, to be a proficient web developer it is necessary to know enough of both client- and server technologies and that is a big challenge. Because how much is enough and how much time should we devote to continuously learning?

One way to make it easier for ourselves is to choose the right set of frameworks and tools to build our applications upon. Frameworks are useful because they usually wrap complex platform features into easy-to-use components, so web developers can focus on writing their applications logic instead of all the plumbing needed to work with the browser or server platforms.

Choosing the right frameworks is important. The options are many, but here are a few that have shown to be particularly well suited for building modern web applications. ASP.NET Core as the application framework for the server and Angular for the client is a great combination. Bootstrap makes sure the app looks good in all browsers and on all types of devices.

Simone has done a great job showing how these frameworks complement each other and how tooling provides a great development experience. In the fast-moving world of web development, it is good we have books like this to give us a pragmatic approach to building web applications using the latest and greatest in both client- and server technologies.

With this post I conclude the series. If you liked it, I encourage you to go pre-order my book and now enjoy you season holidays!

(image)



The book Table of Content - Day 23 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Sat, 23 Dec 2017 12:30:18 Z

With the series coming to an end, it's time to look back at these last 22 days of content, and see how they relate to the outline of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". Introduction Day 1 - Polyglot Developer Chapter 1: What's new in ASP.NET Core MVC Day 2 - Web Host Builder in ASP.NET Core 2.0 Day 3 - TagHelper syntax for View Components Chapter 2: The Front-End Developer Toolset Day 4 - The Front-end developer toolset Day 5: Not just Bootstrap: Semantic UI Chapter 3: Angular in a Nutshell Day 6 - Angular Concepts Day 7 - How an Angular project is built Day 8 - JavaScriptServices Chapter 4: Bootstrap in a Nutshell Day 9 - Bootstrap Responsive Grid System Day 10 - Bootstrap Snippet Pack for Visual Studio Chapter 5: Managing dependencies with NuGet and Bower Day 11 - What are package managers and why we need them Day 12 - How to publish your own Nuget Package Chapter 6: Building your application with Gulp and webpack Day 13 - What is the role of build systems in front-end development Day 14 - Introduction to webpack Chapter 7: Deploying ASP.NET Core Day 15 - Deploy ASP.NET Core apps on IIS Day 16 - Deploy ASP.NET Core apps to Azure Day 17 - Continuous Deployment on Azure with Git Chapter 8: Developing outside of Windows Day 18 - Omnisharp: the tooling behind the C# integration in Visual Studio Code Day 19 - Git support in VS Code Chapter 9: Chapter 9: Putting It All Together Day 20 - Entity Framework Core migration Day 21 - How to seed your database with EF Core Day 22 - How to add Social Media Authentication to ASP.NET Core [...]



How to add Social Media Authentication to ASPNET Core - Day 22 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Fri, 22 Dec 2017 10:27:26 Z

It's day 22 and till now I've shared two or three extracts from all the chapters, in the order in which they appear on my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". For today I'll still share something from the last chapter: how to enable social media authorization to an ASP.NET Core application. Adding social media authentication is easy with ASP.NET Core. You start by creating another project, still as an ASP.NET Core MVC project, and selecting Individual User Accounts as the Authentication mode. This way the project template will add the database entities, controllers, and views to collect and store all the information needed to create a private site where users can register either directly (providing a username and password) or via OAuth providers like Facebook, Twitter, Google, Microsoft, GitHub, and others. Adding a social login is just a matter of adding the right Nuget package and configuring the authentication provider in the ConfigureService method in the Startup class. For example, to add a Facebook login, add the Nuget package Microsoft.AspNetCore.Authentication.Facebook. Then add the following lines of code in the ConfigureService method: services.AddAuthentication().AddFacebook(facebookOptions => { facebookOptions.AppId = Configuration["Authentication:Facebook:AppId"]; facebookOptions.AppSecret = Configuration["Authentication:Facebook:AppSecret"]; }); Now you have to register a new application on the Facebook developer portal in order to get the AppId and AppSecret needed to authenticate your application with Facebook. Go to the URL https://developers.facebook.com/apps/ and click on the Add a New App button and add the basic information for your app. Once done go the settings and enter the URL for the OAuth redirect page, which is /signin-facebook (but you need to specify the absolute URL, so also http://localhost:nnn). This route is added by the Nuget package for the Facebook authentication. The last thing is to retrieve the AppId and AppSecrets needed for the application to work. For this go to the Dashboard inside the developer portal Now that you have these values, you have to store them in the settings of your application. Since these are sensitive data, you don't want to accidentally commit them to a public source repository, so it's better to store them in the User Secrets. The file is stored in the user profile, still easily readable, but in theory only by its owner. The in production these information can be passed to the app in different ways, like shown when explaining the configuration of app settings inside the WebHost. { "Authentication": { "Facebook": { "AppId": "myappId", "AppSecret": "myappsecret" } } } Now just launch the site and you'll see a new button to sign-in and log-in via Facebook. This post is an extract of chapter 9 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". To know more about what I'm publishing, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book. [...]



How to seed your database with EF Core - Day 21 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Thu, 21 Dec 2017 12:00:01 Z

Yesterday I've shown how to do EF Core DB migrations using either the Package Manager Console or the dotnet CLI. But you can also do these code migrations automatically, triggering them via code. After following the steps shown yesterday, you have all your migrations setup, and you can apply the DB changes using the dotnet CLI. But there is less-know feature, still experimental and not ironed out completely, that makes it possible to run migrations from code, and even seeding the DB with initial data. Apply migrations with code To just apply migrations you need to call the db.Database.Migrate() method, where db is the EF Context. Typically the following is the code needed to run the migration in code: public static void Initialize(IServiceProvider service) { using (var serviceScope = service.CreateScope()) { var scopeServiceProvider = serviceScope.ServiceProvider; var db = scopeServiceProvider.GetService(); db.Database.Migrate(); } } This method can be called in the Configure method in the Startup class: public void Configure(IApplicationBuilder app, IHostingEnvironment env) { ... Initialize(app.ApplicationServices); } Seeding the DB with data As part of the database initialization you can also add some initial test data to the database. Unfortunately it is not that automated as in Entity Framework 6, but can be coded manually. For, example, to add a new entry in the Race table, to code is as following: private static async Task InsertTestData(TriathlonRaceTrackingContext context) { if(context.Races.Any()) return; var race = new Race { Name="Ironman World Championship 2017",Location="Kona, Hawaii",Date=new DateTime(2017,10,14,7,0,0) }; context.Add(race); await context.SaveChangesAsync(); } The advantage of having to code it yourself is that you can decide if/when/how to seed the database. In this I just do it if the Race table is empty. But I could have decided to always wipe it clean, or anything else. To include data seeding into the Initialize method, a few changes have to made as the data seeding is an async method. So the Initialize becomes an InitializeAsync: public static async Task InitializeAsync(IServiceProvider service) { using (var serviceScope = service.CreateScope()) { var scopeServiceProvider = serviceScope.ServiceProvider; var db = scopeServiceProvider.GetService(); db.Database.Migrate(); await InsertTestData(db); } } Also the call from the Configure method must be slightly changed into InitializeAsync(app.ApplicationServices).Wait();. This post is an extract of chapter 9 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". To know more about what I'm publishing, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book. [...]



Entity Framework Core migration - Day 20 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Wed, 20 Dec 2017 12:46:23 Z

In the last chapter of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap" I build a very simple application to show how all the various technologies play together, and also to show some features that are not specific to front-end development but are needed in a real world application. One of the technologies I don't cover in the other chapters of the book but is covered in the last chapter is Entity Framework Core. Today I'm showing is loosely taken from the section about EF Migrations. Let's say you have a class called Race defined by the following lines of code public class Race { public int ID { get; set; } public string Name { get; set; } public string Location { get; set; } public DateTime Date { get; set; } } In order to work, EF Core needs to know the mapping between database tables, fields and properties of classes. The easiest approach, unless you want to write a lot of mapping code yourself, is to just stick to the default mapping conventions, and name tables and columns accordingly. And the best way of doing it, is to let EF generate the database for you. And this is done with a feature of EF called migrations. Migrations can be used for the first setup of the database but more importantly later in the development when adding more features that require new tables or columns for existing tables. To create the baseline migration for the class Race, you need to run the Add Migration command to generate the code to create the database schema (it gets stored in the Migrations folder), followed by the Update Database command to run this code on the database. These two commands can be run either inside Visual Studio 2017, the Package Manager Console, or using the dotnet command-line tool. In the first option type the following: PM>Add-Migration Initial PM>Update-Database If you prefer using the dotnet command line, type these lines in the command prompt (but first you need to add the Microsoft.EntityFrameworkCore.Tools.DotNet package to the DotNetCliToolReference to the .csproj file). >dotnet ef migration Initial >dotnet ef database update The table is created in the database configured in the appsettings.json file, under the ConnectionSettings section. In the case of the Race class, the migration code generated is the following: migrationBuilder.CreateTable( name: "Race", columns: table => new { ID = table.Column(type: "int", nullable: false) .Annotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.IdentityColumn), Date = table.Column(type: "datetime2", nullable: false), Location = table.Column(type: "nvarchar(max)", nullable: true), Name = table.Column(type: "nvarchar(max)", nullable: true) }, constraints: table => { table.PrimaryKey("PK_Race", x => x.ID); }); And the following mapping code: modelBuilder.Entity("TriathlonRaceTracking.Models.Race", b => { b.Property("ID") .ValueGeneratedOnAdd(); b.Property("Date"); b.Property("Location"); b.Property("Name"); b.HasKey("ID"); b.ToTable("Race"); }); This post is an extract of chapter 9 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". Tomorrow I'll continue covering Entity Framework Core migrations. To know more about what I'm publishing, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book. [...]



Git support in VS Code - Day 19 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Tue, 19 Dec 2017 12:57:10 Z

Visual Studio Code comes with native support for Source Control systems. Let's see how it integrates with Git. Originally Visual Studio Code came with native support for Git, but recently, in order to allow support for other systems, also the source control support became an external plugin. At the moment there six SCM provider Let's have a look at my favorite features of the Git support in Visual Studio Code. The one I like the most, and was just recently added is the visual representation of which files have changed directly in the file explorer view. Another feature I like is the diff view, which can be both side by side or inline. And diff can also be displayed by simply clicking on the gutter. Another feature I like is the easy procedure for committing code: just type the message and you can commit all the changes. Or you can also choose which changes to commit. And once committed, the status bar shows that there is a pending commit Also, in the command palette, there are accessible most of the git commands, like branch, checkout, clone, merge, commit, ecc... But to really enhance the experience using Git in VS Code, I recommend also checking out two very useful extensions: Git history which adds, as the name suggests, possibility of reading the change logs, compare between commits and see a graph of all commits, branches and merges Git Lens which adds code lens features (so small overlay next to lines of code showing when and by who it was changed) and much more This article contained some of the pieces that didn't make into chapter 8 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap" because to volatile for a printed book. So consider this a "bonus" section. To know more about what I'm publishing, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book. [...]



Omnisharp: the tooling behind the C# integration in VS Code - Day 18 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Mon, 18 Dec 2017 12:56:01 Z

We are entering the last week of the calendar, and we are also reaching the end of the book. Today is time to look at the cross-platform tools used to develop ASP.NET Core application on any platform. We'll have a look at Visual Studio Code, and specifically how the C# integration works.

Visual Studio Code is just a simple text editor, with no language-specific features or knowledge. All language-specific tools are coming as external extensions, either developed by Microsoft or by the community.

So how can Visual Studio Code show Intellisense when you type .NET code, or provide refactoring suggestions or show compilation errors in real time? This is done using Omnisharp. Here is an extract from chapter 8 of book, which briefly explains what Omnisharp is.

All these features, as far as their support for .NET Core is concerned, are possible thanks to OmniSharp. OmniSharp is a set of OSS projects that work together for bringing .NET development to any text editor.

The base layer is a server that runs Roslyn and analyzes the files of the project that is open inside the editor.

On top of this there is an API (REST-based over HTTP or over pipes) that allows clients (text editors via their extensions) to query the code model to get intellisense, parameter information, the references to a variable, or the definition of a method. At the top layer are all the editor-specific extensions that display the information retrieved from the OmniSharp server in a user-friendly way. The top layer also includes other features that are purely client-side such as code formatting or snippet expansion. It is also the extensions that interact with the debugger to provide all the features needed for debugging your code.

OmniSharp extensions have been developed for the most popular text editors on the market. Apart from Visual Studio Code, there are extensions for Atom, Vim, Sublime, and even Emacs. This means that you can continue using your favorite text editor and still be able to get all the benefit of a rich code-editing experience powered by OmniSharp.

This article was short summary of the chapter about deploying ASP.NET Core from my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

To know more about what I'm publishing, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book.

(image)



Continuous Deployment on Azure Git - Day 17 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Sun, 17 Dec 2017 12:40:46 Z

Deploying to Azure can be done with WebDeploy, as seen yesterday, but we can also go one step further and setup a continuous deployment using Git.

The first step is to create the App Service directly in the Azure portal, and then configure the Deployment Source.

(image)

As you can see from the image you can select Visual Studio Team Services, a local Git repository or hosted git like Github or Bitbucket, or even file storage like Drobpox or OneDrive.

The easist solution is configuring a Local repository directly in Visual Studio and then add as additional remote the git repository just created from the portal (the url can be found in the overview of the Azure App Service). This can be done either from within Visual Studio or with the Git command line.

(image)

Now the code can be pushed to the remote, either directly from Visual Studio or from the command line. As part of the push operation, Azure launches the publish command, which restores all NuGet packages and builds the application using the project file. Every time a commit is pushed to the repository, the publish process starts, effectively implementing a continuous deployment scenario.

If you created the remote within Visual Studio, the remote is not tracked by the local repository, so the first time you want to push, you have to do it from the Command Prompt and type: git push -u azure master. The -u option instructs git to start tracking the remote branch.

On Azure portal you can see the list of deployments and the log message for each commit.

(image)

This article was short summary of the chapter about deploying ASP.NET Core from my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

To know more about what I'm publishing, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book.

(image)



Deploy ASP.NET Core apps to Azure - Day 16 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Sat, 16 Dec 2017 12:12:34 Z

Yesterday we've seen how to deploy an ASP.NET Core app to IIS, and today we look at how to do the same on Azure.

Publishing on Azure is super-simple and can be easily done from within Visual Studio.

From the overview screen of the project, just select "Publish" and then "Microsoft Azure App Service".

(image)

You can then either select an existing App Service or create a new one directly from the Publish dialog, without going to the Azure Portal.

(image)

One thing I recommend doing is also creating a new Resource Group and service plan (if you are just testing, remember to select the Free size).

So, nothing different from a standard ASP.NET application. The only difference is that the actual publishing consists on Visual Studio running dotnet publish to create the file bundle on a temporary folder, followed by Web Deploy moving the files to the server.

There is another way of deploying applications to Azure, and it is done via Git. But this is something for another day.

This article was short summary of the chapter about deploying ASP.NET Core from my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

To know more about what I'm publishing, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book.

(image)



Deploy ASP.NET Core apps on IIS - Day 15 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Fri, 15 Dec 2017 10:54:35 Z

After developing the ASP.NET Core application, adding client-side interactivity with Angular and styling with Bootstrap, all automated using webpack and with dependencies managed with Nuget, the time has come to deploy the application. My upcoming "Front-end Development with ASP.NET Core, Angular, and Bootstrap" book explains how to deploy ASP.NET Core applications with three different methods: On-Prem on IIS On Azure App Services To Docker containers On day 15 of my advent calendar I'm showing how to publish to a local IIS. In "classic" ASP.NET, applications are DLLs that are hosted inside the IIS Application Pool (also known as Worker Process, w3wp.exe). They are instantiated from IIS's runtime manager. When requests come in, they are sent to the HttpRuntime of the right site, which lives inside an AppPool. In short, they are basically modules controlled by IIS itself. In ASP.NET Core, it is totally different. ASP.NET Core applications (remember, they are all console applications) run their own web server using Kestrel. Each application already hosts itself and can directly respond to requests over HTTP, so you might be wondering why you need IIS in first place. In this case IIS basically acts as a reverse proxy, receiving the requests and forwarding them to the ASP.NET Core application self-hosted on a Kestrel web server. Then it waits for the execution pipeline to complete its processing and sends back the HTTP output to the originator of the request. This is accomplished by AspNetCoreModule, which calls the dotnet run command to fire up the application the first time it is requested. This module is configured via the web.config file in the root of the application. But you don't have to worry too much about this web.config since it's automatically generated, together with the compiled DLLs and other configuration files, when you run the dotnet publish command. Now rarely people still deploy to servers on premise, so tomorrow I'm going to show how deploying to Azure. Come back to my blog to read more, and to read more about deploying applications on IIS and Azure, please consider pre-ordering my book. To know more about what I'm publishing, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book. [...]



Introduction to webpack - Day 14 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Thu, 14 Dec 2017 10:04:34 Z

What is webpack? Why is it listed as part of my chapter on build automation systems? Let's find it out in this extract from chapter 6 of my upcoming "Front-end Development with ASP.NET Core, Angular, and Bootstrap".

webpack is a module bundler that loads all the dependencies of a JavaScript application and bundles them to optimize the loading time in the browser. Although it is not strictly speaking a task runner, webpack can be used to accomplish most of the tasks performed by Gulp, like minification, bundling, and linting. Let’s see how this works.

webpack’s main concepts

webpack has a bit steeper learning curve compared to Gulp, so before seeing some examples, let’s have a look at the main concepts: entry, output, loaders, and plugins.

It all starts with the entry point of the application, which is where webpack starts to follow the dependencies tree from. The end of the process is the output, which is where webpack will save the bundle once it has completed its job. Between the entry and the output, all the processing happens, which is done by loaders and plugins.

webpack is a JavaScript module bundler, which means that it discovers JavaScript modules and their dependencies and bundles them. However, webpack can also treat .css files, sass files, TypeScript files, and even images and .html files. Loaders are used to “convert” any kind of file in a module treatable by webpack. Plugins do not work on the individual source files but are used to perform general operations on the final output of the bundling.

The configuration of webpack is stored in a webpack.config file.

For example, the following configuration bundles all JavaScript files of the application (or at least the ones "reachable" from the entry point via ECMAScript 5 export/import of modules)

var path = require(‘path’);

module.exports = {
  entry: ‘./src/index’,
  output: {
    filename: ‘bundle’,
    path: path.resolve(__dirname, ‘dist’)
  }
}

The book covers the usage of webpack more in details. If you are interested, please consider pre-ordering my book.

Tomorrow I'm going to cover installation of ASP.NET Core on on-prem IIS. If you are interested, don't forget to check my blog again, subscribe to my RSS feed, follow me on twitter or like the Facebook page of my book.

(image)



What is the role of build systems in front-end development - Day 13 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Wed, 13 Dec 2017 11:03:55 Z

With JavaScript frameworks becoming more and more complicate, and with the increasing demand for performances also on the client-side of applications, gone are the days when it was just enough to put some javascript or css files in a static folder. Today, 13 days into the advent calendar of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap", I'm going to share an extract of chapter 6, which introduces the role build systems in front-end development. What Front-End Build Systems are for In the context of server-side compiled languages, build systems are used to compile code into binaries, to run tests, to compute metrics, and to perform transformations of configuration files from development to a production setup. Other typical operations include moving files around and creating release files. Front-end build systems are also used for more or less the same reasons as server-side build systems because even front-end development requires "compiling" code files into "binaries" (for example Less or Sass to CSS or TypeScript to JavaScript) or running JavaScript test suites or metrics (JSLint for example). However, front-end development also requires some tasks that are specific to JavaScript and CSS development and that are used during the development phase and not just during the final release. One such task is automatically including references to Bower files. Another example is minification and concatenation of JavaScript and CSS files to reduce the size and number of files downloaded by the client. The rest of the chapter explains how to perform some of the most common tasks. It will show how to: Automatically include references to Bower packages Compile Sass files to CSS Compile TypeScript to JavaScript Combine and minify JavaScript and CSS files Run JSLint to detect JavaScript problems Perform tasks and automatically reload the browser when changes are detected in a file The tool used to show how to perform these tasks is Gulp, since it is the tool the .NET community is mostly leaning toward. Later in the chapter there is also a quick introduction to webpack, which was already briefly mentioned in Chapter 3 since it is used by the Angular Command Line tool and is gaining a lot of traction in the front-end development community. Tomorrow I'll give a quick introduction to webpack, so come back for more. If you are liking this series of posts, please consider pre-ordering my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap", from which all these extracts are taken, and cover all of these topics more in details. [...]



How to publish your own Nuget Package - Day 12 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Tue, 12 Dec 2017 15:50:25 Z

With package managers you consume libraries but eventually you will end up releasing yours for others to use, either to the community or as shared among co-workers. Today we look into how to do it with Nuget and .NET Core. Doing a Nuget package was a bit convoluted with the traditional .NET Framework, but with .NET Core it's very easy. Add metadata After having developed the application, just add to your .csproj file the metadata needed (no need for a specific .nuspec). netcoreapp2.0 Wrox.Book 1.0.0 Simone Chiaretta Show the title of the book First release Copyright 2017 (c) Simone Chiaretta book title Wrox http://example.com/Wrox.Book/ http://example.com/Wrox.Book/32x32icon.png http://example.com/Wrox.Book/mylicense.html Create the package Now just go to the root of the project (where the .csproj is) and type dotnet pack -c Release. This will build the project and create a nuget package file, saved in bin\Release. If you now open the file with the Nuget Package Explorer you'll see the content of the file Publish the package Now you can just either copy the file to a local repository or publish it to the Nuget public repository. To do so: Download the NuGet command line utility (the dotnet cli is not enough here). You can install it via Nuget as well: Install-Package NuGet.CommandLine Create an account on the NuGet.org gallery (if you don't have one) Set your API-KEY: nuget setApiKey Your-API-Key Publish the package: nuget push YourPackage.nupkg This topic is covered more in details, together with how to develop packages for NPM and bower, on my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". If want to read more extracts of the book, come and visit my blog again tomorrow. [...]



What are package managers and why we need them - Day 11 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Mon, 11 Dec 2017 11:51:16 Z

Over the weekend I wrote about the Bootstrap grid system and the Bootstrap Snippet Pack for Visual Studio, both extracts from Chapter 4 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". Today I'm going to cross halfway point in my book, taking a extract from chapter 5, which is about package managers and Nuget, NPM, Bower. And I'm going to introduce package managers and why we need them. Why we need package managers Modern software development, both front-end and server-side, is based on small and very focused components that can be composed as needed. While it is good to avoid the monolithic frameworks of the past, this new approach introduces a problem: how do you manage all these components? Components usually depend on other components, which depend on yet other components, which depend... well, you got the idea. To make things more difficult, there might be a component, let's call it A, that depends on component B, but also another component, C, that also depends on B, but a different version of it. And on top of this, all components must be kept up-to-date. Finally, in some cases, to correctly install a component, additional operations might be needed, like compiling some native library or changing some configuration files. Fortunately, all these tasks are automated by specific tools that are called package managers. What package managers do All package managers, apart from the obvious differences given by the different technologies or languages they target, are practically identical. Here are their common concepts: They all rely on a public registry that contains all published packages. The registry might also store the actual package or just provide the URL where the package can be downloaded. Packages are downloaded and stored in a local folder (usually within the current user folder) that acts as a local cache. This way when a project needs a package that has been already downloaded, it's directly copied from the cache instead of being downloaded again (providing that it is the latest version). This saves bandwidth and time (especially if packages are restored every time a project is built). It also allows some kind of offline development experience that would be otherwise impossible. Projects declare which third-party libraries they depend on. This is usually done by specifying in a JSON file the names of the packages and their versions. Package managers take care of downloading not only the projects’ dependencies but also the libraries they depend on, descending the entire tree of packages. There are still lots of interesting topics coming up from my book. If you are interested in knowing more, come back tomorrow and also remember to follow me on Twitter @simonech and like the Facebook page for my book. [...]



Bootstrap Snippet Pack for Visual Studio - Day 10 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Sun, 10 Dec 2017 15:04:34 Z

Today let's have a look at how to type less when adding Bootstrap components using the Bootstrap Snippet Pack.

This is an extract from Chapter 4 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap".

Most Bootstrap components are made of long pieces of HTML, most of which have to be copied as it is, and only few strings need to be updated. There are two options to avoid repeating yourself all the times:

  • one is creating TagHelpers, which is covered in my book.
  • one is using the Bootstrap Snippet Pack, which is also covered in this post.

The Bootstrap Snippet Pack is a collection of 30+ snippets that can be added to an HTML page by simply dragging them from the Visual Studio toolbox.

Now development becomes very easy as the strings that can be modified are clearly marked and you can cycle through them with the Tab key.

For example, in the snippet for the modal dialog, the only strings needing customization are the ID, the title, the content, and the text of the two buttons. As you can see in following picture, these strings are highlighted for easy identification.

(image)

If you want to see more of what is coming, come back tomorrow for more tips.

(image)



Bootstrap Responsive Grid System - Day 9 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Sat, 09 Dec 2017 07:54:00 Z

After covering the chapters on ASP.NET Core, on the The Front-End Developer Toolset (and mindset) and on Angular, let's have a look at Chapter 4, which is all about Bootstrap. A few days I said that Semantic UI has class nicer naming than Bootstrap (and easier to remember) for specifying columns sizes in grids. Well, let's see how the responsive grid is defined in Bootstrap. This is an extract from Chapter 4 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". Bootstrap Grid System A basic feature of any CSS framework, the grid system allows you to create a page layout based on a series of rows and columns. On top of the basic behavior, Bootstrap provides a 12-column fluid grid layout that adapts to the size of the screen. Bootstrap defines four classes of devices, and for each of them there is a different CSS class prefix: Extra small devices, like smartphones, with a screen size smaller than 768px (.col-xs-) Small devices, like tablets, with a screen size bigger than 768px but smaller than 992px (.col-sm-) Medium devices, like normal laptops, with a screen size bigger than 992px but smaller than 1200px (.col-md-) Large devices, like desktops, with a screen size bigger than 1200px (.col-lg-) If size of columns is specified with class .col-sm-*, it means that everything smaller than 768px would get the default vertical stacked layout. To get the cells stacked for both smartphones and tablets but to be horizontal on desktops, the class .col-md-* should be used. But more complicated layouts can be achieved by combining different classes. For example, if you do not want the smartphone version to stack horizontally but you want two columns per row, you can define this behavior by using col-xs-6 col-sm-1. On the other hand, if you want the same layout in all device sizes, you just need to apply the class for the smallest size, and all bigger sizes will inherit it. For example, if you always want two columns per row, no matter the size, just apply col-xs-6. Just by reading the extract from the chapter it looks pretty complicated, but with the help of samples and figures everything is clearer. If you are interested, consider pre-ordering my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". If you want to see more of what is coming, come back tomorrow for more tips. [...]



JavaScriptServices - Day 8 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Fri, 08 Dec 2017 12:00:00 Z

Today marks the beginning of the second week of my advent calendar, and I'll just quickly introduce the JavaScriptServices, which makes it easier to include Angular (or React, Vue, Aurelia, Knockout) in an ASP.NET Core project.

JavaScriptServices was an experiment of Steven Sanderson which later made it into ASP.NET Core v2 as part of the core libraries.

You can create an ASP.NET Core project with Angular by selecting the template in the "New ASP.NET Core Web Application" dialog.

(image)

You can also create it via from the command prompt, via the dotnet CLI, by typing dotnet new angular.

The resulting project is more a sample than a template, but it gives a good starting point for exploring all the features of JavaScriptServices. You get:

(image)

  • server-side rendering of Angular components
  • server-side and client-side routing (defined only once)
  • a WebPack ASP.NET Core middleware which simplifies the development process by automatically running WebPack whenever a file is changed
  • NodeServices for invoking Node code from the ASP.NET Core application

The project that gets created has the structure shown in this picture.

You can discover more about the JavaScriptServices directly on their GitHub repository: aspnet/JavaScriptServices

My upcoming "Front-end Development with ASP.NET Core, Angular, and Bootstrap" book shows how to add a simple hierarchy of Angular components to the application created from the project template.

If you want more extracts from book, come again tomorrow for more. And if you want to learn about all these topics, please consider pre-booking my book.

(image)



How an Angular project is built - Day 7 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Thu, 07 Dec 2017 10:46:41 Z

Yesterday I introduced the foundations of Angular and today I'm going to briefly explain how an Angular project is built and why adding an Angular component to an ASP.NET Core is not as easy as just adding a few JavaScript files in a folder. The following is an extract of chapter 3 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap". How an Angular Application Is Built for the Browser Using WebPack To understand why it is not possible to just drop a JavaScript library in an ASP.NET Core project and have everything working, you have to understand how an Angular project is built. As you might have noticed, Angular is a very modular framework. Each different piece of the application, both your own and from the framework, is in a separate file or module and imported as needed. Styles are spread among numerous files, potentially one per component. All these files have to be bundled together to avoid sending hundreds of files to the browser. In addition to this, Angular applications are built using TypeScript, which needs to be converted into standard ES5 JavaScript to be consumed by browsers. Discovering the dependencies and relationships between the various pieces, transpiling JavaScript to TypeScript, bundling JavaScript and CSS, and finally including the correct references in HTML files are all steps that are needed before anyone can run an Angular application. As you can imagine, it’s a pretty daunting task. It could have been done with a generic front-end build tool like Gulp, but the Angular team decided to use a build tool focused only on module bundling, called WebPack, which takes care of everything. And the Angular CLI tools use it to run the Angular project during development and to build the artifacts needed when publishing the application. The rest of the chapter then explains how to integrate an Angular application into an ASP.NET Core project. You have three options: Do not integrate them. Keep two separate projects, one client only and one server-side only with Web applications. Integrate them in one project and have the Angular CLI create files into the wwwroot folder of the ASP.NET Core project. Use the new-ish JavaScriptServices and have everything managed natively into ASP.NET Core. Every option has pro and cons, and also a lot is decided by personal preferences. But it's important to see which the options are and how they work. Tomorrow I'll briefly show how to use the third option of the JavaScriptService. If you want to see more of what is coming, come back tomorrow for more tips. [...]



Angular Concepts - Day 6 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Wed, 06 Dec 2017 12:00:00 Z

On day six of the advent calendar I'm going to share some content from Chapter 3 of my book "Front-end Development with ASP.NET Core, Angular, and Bootstrap", which is all about Angular (v5). Specifically I'm going to introduce the concepts that make the foundation of Angular. AngularJS vs Angular I started writing this book in Summer 2015 with the hope of releasing it in Spring 2016 when the then ASP.NET 5 (and ASP.NET, MVC 6) were released. But unfortunately, as most people know, ASP.NET 5 Core had a long history full of fundamental changes that delayed the release of a complete working version, with both library and matching tooling till Summer 2017. This had a lot of consequences also on chapter 3 about Angular: I started writing about AngularJS 1.5, but during the two years wait for ASP.NET Core to be done, the vNext of Angular went from Alpha, to Beta, to release of Angular 2, and later even to the releases of v4 and v5. So chapter 3 went through one complete rewrite and a few smaller ones. The following is an extract of Chapter 3 about Angular, introducing the foundations of the framework. Angular Concepts Angular is a web application framework developed and maintained by Google and the open-source community. The framework has many features, like two-way data-binding, templating, routing, components, dependency injection, and so on. Unfortunately, like all frameworks of its breed, it has a pretty steep learning curve due to the many concepts you have to grasp in order to be fluent in it. Here is a list of the most important Angular concepts: Modules: Containers that group together blocks of functionalities that belong together, like components, directives, services, and so on. Components: Define the behavior of a “portion” of the screen. Templates: HTML files that define how the view for a component is rendered. Data binding: The process that connects a component to its template and allows data and events to flow between them. Directives: Custom attributes that enhance HTML syntax and are used to attach behaviors to specific elements on the page. Services: Reusable functionalities that are independent from the views. Dependency injection: A way to supply dependencies (services most of the time) to classes (other services or components). Metadata: Instructs Angular on how to process a class, whether it’s a component, a module, a directive, which services have to be injected, and so on. Those terms might sound abstract at the moment, but the upcoming pages will make everything more clear, as all of these concepts are used to build a sample single-page application. The development of the sample SPA is covered in the third chapter of my upcoming book Front-end Development with ASP.NET Core, Angular, and Bootstrap. If you want to see more of what is coming, come back tomorrow for more tips. [...]



Not just Bootstrap: Semantic UI - Day 5 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Tue, 05 Dec 2017 14:01:20 Z

Bootstrap is the most popular and used CSS framework, and my book "Front-end Development with ASP.NET Core, Angular, and Bootstrap" covers it in details in chapter 4, but today I want to highlight one o f the possible alternatives that my chapter 2 briefly covers: Semantic UI. Semantic UI The idea behind the Semantic UI CSS framework is that names of CSS classes should simply be names and concepts coming from natural languages. For example, to style a button with the primary color, you use



The Front-End Developer Toolset - Day 4 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Mon, 04 Dec 2017 12:15:23 Z

As the title says, my book doesn't covers just ASP.NET Core, but also other technologies and frameworks that are important for the development of a web site or web app from A to Z. Chapter 2 of my book is called "The Front-End Developer Toolset" and is an overview of the five categories of "tools" needed by a front-end developer. Today I'm posting an extract from the beginning of the chapter, and is of much lighter reading and less technical then the two posts I wrote over the weekend, which were about the new Web Host builder in ASP.NE Core and the TagHelper syntax for ViewComponents. JavaScript frameworks: These frameworks help you build complex web interfaces by bringing to front-end development the best practices that are typical of server-side systems, like the model-view-controller (MVC) pattern, the model-view-view model (MVVM), dependency injection (DI), routing, and many others. CSS frameworks: Developers are generally bad at making web apps look good and consistent. CSS frameworks provide a set of styles and UI components with which you can build web applications that look as if they were created by professional designers. CSS frameworks also help address the issue of responsive design that adapts to multiple resolutions and screen sizes and can also apply complex animations and transitions. Package managers: Systems are becoming more and more a mix and match of different components, many of which depend on other components. Managing all these dependencies and correct versions would be a nightmare if it wasn’t for package managers. Build systems: If you are coming from a pure .NET background, you probably have used some build systems already, like NAnt or MSBuild. The front-end development world came out with their own build systems, which are made specifi cally for managing the build of front-end systems. Languages: These extend beyond C# or VB.NET. Most of the tools from the previous categories are built and must be used with JavaScript or other domain-specific languages (DSL). Explanation of these five categories is covered in more details in the second chapter of my upcoming book Front-end Development with ASP.NET Core, Angular, and Bootstrap. If you want to see more of what is coming, come back tomorrow for more tips. [...]



TagHelper syntax for View Components - Day 3 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Sun, 03 Dec 2017 12:31:13 Z

It's the 3rd of December, and today I want to talk about View Components, showing how they can be added to a page using the Tag Helper syntax. This is covered more in detail in the first chapter of my upcoming book Front-end Development with ASP.NET Core, Angular, and Bootstrap. What are View Components View Components is something introduced in ASP.NET Core, and they are used to encapsulate both UI and logic for reusable portions of pages: we can see them as the new version of the Child Actions (which have been removed from the MVC framework in ASP.NET Core). A big improvement if you ask me. In it's simplest implementation, a View Component is just a class which extends ViewComponent and implements the method Invoke which returns a IViewComponentResult. This renders a view which is by convention stored in \Views\Shared\Components\{component_name}\Default.cshtml. As very simple view component that shows a counter to a specific date can be implemented with few lines of code. Here the component public class CountdownViewComponent: ViewComponent { public IViewComponentResult Invoke(DateTime to, string eventName) { var today = DateTime.Today; var diff = (to - today).TotalDays; var model = $"{diff} days to {eventName}"; return View(model); } } And it's view @model string It's @Model How to include the View Component into a view The original way of including the view component is a view is by using the Component class specifying the name of component (as string) and an anonymous object with the parameters: @await Component.InvokeAsync("Countdown", new {to = new DateTime(2017,12,15), eventName="Christmas"}) But this syntax is not easy to use and not discoverable as it relies on magic strings and on the developer needs to know the exact name of parameters. There is also the TagHelper syntax, which is much easier. And also comes with Intellisense: For this to work, also remember to register you View Components as tag helpers. In the _ViewImports.cshtml file add the following line (where projectName is the name of your project, actually the assembly name in which your project is compiled): @addTagHelper *, projectName If you want to learn more about View Components, Tag Helpers and much more, consider pre-ordering a copy of Front-end Development with ASP.NET Core, Angular, and Bootstrap and get it as soon as it hits stores. If you want to see more of what is coming, come back tomorrow for more tips. [...]



Web Host Builder in ASP.NET Core 2.0 - Day 2 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Sat, 02 Dec 2017 12:26:03 Z

On the second of December, I want to share something from the first chapter of my upcoming book Front-end Development with ASP.NET Core, Angular, and Bootstrap. While reviewing and updating the code from ASP.NET Core 1.0 to version 2.0 I was faced with the challenge of how to explain what's going on in the initialization of the WebHost which was make much more simple and logic ASP.NET Core 2.0, but at the cost of being more "magic". Initialization in ASP.NET Core 2.x But let's get back to basics a bit. The initialization happens inside two files: Program.cs, where the WebHost is built Startup.cs, where the execution pipeline and dependencies are set up The ASP.NET Core 2.x the initialization of the WebHost in the Program.cs file is just a few lines of code: public class Program { public static void Main(string[] args) { BuildWebHost(args).Run(); } public static IWebHost BuildWebHost(string[] args) => WebHost.CreateDefaultBuilder(args) .UseStartup() .Build(); } And the code in the Startup.cs file is exactly just about configuring the request execution pipeline. public class Startup { public void ConfigureServices(IServiceCollection services) { } public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } app.Run(async (context) => { await context.Response.WriteAsync("Hello World!"); }); } } But now you don't really understand what has happened. Especially if you have worked with ASP.NET Core 1.x where everything was much more verbose and explicit. I bet you would be surprised to know that after this 3 lines of code you have: configured the app to use Kestrel as web server configured integration with IIS specified to use the current project directory as root for the application set up the configuration sub-system which reads settings from: appsettings.json in the root of the project appsettings.{env}.json which specifies environment specific configuration local user secrets storage for things like password and auth tokens (but only in the Development) Environmental variables to allow for server-specific settings command line arguments configured to logging sub-system to read its filters and rules from the Logging section of the appsettings.json file and log to the Console Debug window In ASP.NET Core 1.x you had to specify everything explicitly, even adding references to a few additional Nuget packages. All these configuration are hidden inside the CreateDefaultBuilder method. To understand better what's going on I recommend you go on the ASPNET/MetaPackages git repo and read its implementation. How do you like this new approach? I personally like it as it declutters the code and removes all plumbing code what is supposed to be just the creation of the execution pipeline of you application. But I admit it made my job of explaining what happens behind the scenes more difficult. If you are interested in learning how to become a polyglot front-end developer using ASP.NET Core as basis, consider pre-ordering a copy of Front-end Development with ASP.NET Core, Angular, and Bootstrap and get it as soon as it hits stores. If you want to see more of what is coming, come back tomorrow for more tips. [...]



Polyglot Developer - Day 1 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Fri, 01 Dec 2017 08:53:26 Z

Today it's the first of December and this year I'm trying to do something I've never done before. I'm going to write an Advent Calendar. And each day from today to the 24th of December I'm going to write a short post with a tip, an extract, a code listing or topic from my upcoming book Front-end Development with ASP.NET Core, Angular, and Bootstrap. The posts will be published around noon European time so that they are the first thing you see in the morning in USA time zones. The book is made of 9 chapters plus introduction and preface, so it'll roughly be 2 days per chapter. Today, as first day, the content comes from the introduction of the book, and is the reason why I decided to write the book. After changing job and industry (almost 8 years ago now) and moving from companies in the IT industry to an organization where IT is something to support the main business, I've seen a big difference in the type of developers: mostly were the so called "enterprise developers" which only knew their language and their framework of choice, but had little (or no) knowledge of the revolution that was happening in our industry, more specifically about the fast-paced evolution in the world of front-end development and integration with server-side development. This is what pushed me to write this book. And here is an extract of that chapter: What is a polyglot developer In every-day life, a polyglot is a person who knows and is able to use several language: their are not necessarily bi-lingual (or multi-lingual) but they can use their second or third or fourth language with a good level of proficiency. With that definition in mind, what is a polyglot developer? It's a developer who knows more than one (programming) language or framework and uses them within the scope of the same application. From the beginning of IT industry, applications were mainly written in one language: I personally started with C, then moved to Visual Basic, landed on Cold Fusion, used JavaScript at its early stages, both on the client and the server, did a bit of Java and finally landed on the .NET platform, but only one at a time. It was the time of the big enterprise frameworks, when vendors tried to squeeze into their language or platforms all the possible features than an application might need. Probably you all remember when Microsoft tried to shield web developers from the actual languages of the web, HTML and JavaScript, introducing ASP.NET WebForms and the ASP.NET Ajax Framework. And if you look back at your personal experience in the IT industry you'll probably find many other similar examples. But lately a new trend appeared, which went in the opposite direction. The IT industry understood that maybe some languages are more suitable than others for specific tasks, and instead of trying to force everything on top of one and only language, applications started to be written in multiple languages. And that was the beginning of the era of the polyglot developer. If you are interested in learning how to become a polyglot developer using ASP.NET Core as basis, consider pre-ordering a copy of Front-end Development with ASP.NET Core, Angular, and Bootstrap and get it as soon as it hits stores. If you want to see more of what is coming, come back tomorrow for more tips. [...]



My new book Front-end Development with ASP.NET Core, Angular, and Bootstrap is coming out soon

Thu, 12 Oct 2017 19:03:54 Z

I'm so excited to announce that I just sent to the my editor the final chapter of my upcoming book Front-end Development with ASP.NET Core, Angular, and Bootstrap. Which means that in a few months you will be able to get your hands on it. What is the book about The book covers a series of technologies that are important to master in modern front-end development with ASP.NET Core. I'm not talking only about Angular and Boostrap, but also about WebPack, Gulp, TypeScript, Node, Bower, Nuget and NPM. This book is meant as a reference for backend ASP.NET developers which still have to make the step to the mix of technologies that is modern front-end development. But it also good for front-end developers that come from other technologies and never used Visual Studio: they will learn how Visual Studio 2017 helps a lot with common task. And also they will learn how to developer ASP.NET applications on a Mac. It has 9 chapters, one per type of technology or tool ASP.NET Core MVC A general overview of modern front-end development Angular Bootstrap Package Managers (Nuget, NPM, Bower) Build tools and task runners (WebPack and Gulp) Deployment on-prem and to Azure How to develop without Visual Studio A sample that combines all these technologies Each of the chapters start explaining the library or technology by itself, and later shows how it works in the context of ASP.NET Core development and what Visual Studio 2017 helps doing faster or without errors. A bit of behind the scene Writing this book was a massive effort because of the constant changes in the technologies I'm covering. I started writing the book in summer 2015, when ASP.NET Core was called ASP.NET 5, ASP.NET Core MVC was called MVC 6 and the only cross-platform compiler was called dnx and was only for web development. Angular was called AngularJS v1, Bootstrap 3 was still in beta and Grunt was the main task runner, Gulp a rising star and Bower was the package manager for front-end components. Then ASP.NET 5 became ASP.NET Core... all the .NET went cross-platform as .NET Core, they went from the beloved JSON-based configuration file back to the csproj file. But ASP.NET Core was "final" only in the libraries, but not in the tools, so I had to wait for the ASP.NET Core tooling to go RTW, which happened only this spring with Visual Studio 2017. In the meantime, Bootstrap 3 became stable, and v4 was still in alpha, Angular 2 was released, Grunt felt out of grace and WebPack came to the scene. So not only I had to update the bits about ASP.NET Core, but had to completely rewrite the chapter on Angular, add some new content on WebPack and get rid of Grunt. While I was updating all of these, ASP.NET Core v2.0 was released, this August. Luckily nothing major changed since this summer (apart from Angular becoming v4 and soon to be v5 but with little or no fundamental changes) so I just finished the last chapter that combines everything which I had left as last to avoid rewriting it zillion times. A funny thing: when I started the book I asked Mads Kristensen from Microsoft if he wanted to be my Tech Editor, and he declined because he was about to become father soon and would not have had time for that. And now his kid is almost 2yo... But Mads is providing the preface to the book, so no all was lost. What's next I just have to complete some last minute changes and then the book will be sent to print (and eBook product[...]