ProMatrix Training & Consulting

Learn Tips and Tricks How to Integrate Angular and ASP.Net Core

Angular and ASP.Net Course Overview

Overcoming Common Angular Obstacles

Letting Gulp do the Heavy Lifting

Increasing Your Productivity in Visual Studio

This course is all about productivity, performance, efficiency, and the integration of 2 of the most powerful frameworks, Angular, and ASP.Net Core.

As a Microsoft developer, you already know the advantages of choosing ASP.Net Core for the back-end, but now you should know how to integrate with Angular, the most powerful front-end technology to create rich, robust, web applications. By using these 2 powerful frameworks, and by using the productivity tips and tricks demonstrated in this course, your projects will be months ahead of schedule, with applications that are built for the future, and run on multiple platforms.



Playlist: Angular and ASP.Net Course Overview

 

Hello! My name is David Donovan. Welcome to this ProMatrix course titled, “Angular and ASP.Net Core”. Since ASP.Net Core is open source and runs on MacOS, Linux, as well as Windows, there is more interest than ever integrating these 2 powerful frameworks, Angular on the front-end and ASP.Net Core on the back-end.



Playlist: Overcoming Common Angular Obstacles

 

Welcome back to this ProMatrix course titled, “Angular and ASP.Net Core”. I’d like to take this opportunity to share some of the obstacles that you will be faced with when integrating Angular with ASP.Net Core. Many are the same that you will face integrating any modern client-side framework, but most are specific to Angular. Please keep in mind that the key is automation.



Playlist: Letting Gulp do the Heavy Lifting

 

Welcome and thanks for returning to this ProMatrix course titled, “Angular and ASP.Net Core”.
I would have never guessed that I was going to need Gulp and NodeJS to be an efficient Microsoft application developer. Now I truly can’t live without these 2 technologies. In case you didn’t know, NodeJS comes with NPM, which is a repository for storing Node packages. And Gulp is a JavaScript task runner that lets you automate tasks.



Playlist: Increasing Your Productivity in Visual Studio

 

Welcome to the final module for this ProMatrix course titled, “Angular and ASP.Net Core”. In this module we will concentrate more on productivity by using Visual Studio, integrating with the ASP.Net Core framework, many debugging techniques, such as concurrent debugging, performance analytics, and TypeScript OO techniques, such as inheritance.



ProMatrix Inc.
1650 Galiano St.
Coral Gables, FL. 33134

(786) 408-0969

Contact:

Please call for courses, scheduling, and pricing.

(786) 408-0969

 
 
 
 
 
Welcome Hello! My name is David Donovan. Welcome to this ProMatrix course titled, “Angular and ASP.Net Core”. Since ASP.Net Core is open source and runs on MacOS, Linux, as well as Windows, there is more interest than ever integrating these 2 powerful frameworks, Angular on the front-end and ASP.Net Core on the back-end. Interesting enough, there are many obstacles to streamlining the process of quickly developing web applications with Angular and ASP.Net Core. However, I have overcome all of these obstacles and will demonstrate techniques that will allow you, as a developer, to just concentrate on development. Unlike many developers, I spend much time analyzing the workflow and looking for shortcuts to developing an application. The key is automation. A little upfront time, researching and analyzing the workflow, will save you months of development time later. And that is what I can share with you. I’ve spent months, not only looking for shortcuts to make the development quicker, but also to enhance the performance, and make the applications easier to maintain. As a Microsoft developer, you have become used to not needing to drop down to the command line to perform an operation. By automating the development process, you will be less fatigued, and be able to spend your attention doing development. In fact, with the techniques you will learn in this course, you will be able to get more accomplished in a shorter amount of time, and still have time to goof off. Introduction There is a lot of confusion about how to integrate Angular and ASP.Net Core. A big part of the problem is a lack of resources and limited understanding of how to integrate these 2 awesome technologies. Here is what you will take away from watching this course. • How to access the Node Modules which are not in the wwwroot folder,,,,,,, • How to integrate Angular with ASP.Net Core,,,,,,, • The benefits of abstracting the Debug mode from the Release mode,,,,,,, • How to automatically restart your application when files have changed,,,,,,, • How to Bind to build events, or Git Hooks,,,,,,, • Better bundling techniques that favors the returning user,,,,,,, • New squashing techniques to compress your components’ HTML and CSS,,,,,,, • Productivity gains by publishing and reusing your own Angular modules,,,,,,, • More productivity by publishing and reusing your own Gulp files,,,,,,, • How to automate versioning of your application,,,,,,, • How to automate the creation of the application manifest,,,,,,, • Better server-side exception handling and client-side logging,,,,,,, • How to pass application settings to C#,,,,,,, • How that software switches can automate the development workflow,,,,,,, • Benefits to using client-side OO techniques,,,,,,, • How to use performance markers for gathering timing metrics,,,,,,, • A better way to organize your Gulp files,,,,,,, • And, how to debug Gulp files,,,,,,, You’ll learn these things and more by watching this course. Target Audience The target audience for this course is the ASP.Net Developer that would like to use Angular, which is Google’s well documented, and robust client-side framework. I recommend using the latest version of Visual Studio. If you are only familiar with Visual Studio Code, some, but not all things will apply. This course is designed for those who want to learn how to integrate Angular with ASP.Net Core to create web applications with a rapid and streamlined approach. The most efficient and productive Microsoft developers, don’t normally like to drop down to the command line. We like to do everything from within the I D E…. After all, the “I”, in I D E means integrated, and that is what we are going to do. Some experience with Angular, TypeScript, and other modern technologies such as Gulp is strongly recommended. This course assumes viewers are proficient with using Visual Studio, C# and JavaScript. The development environment should already have node.js and npm installed. I will not teach you how to write code within the Angular framework, or do testing, but we will cover a few debugging techniques. This includes how to debug Gulp tasks, and Git hooks, and how to set breakpoints in TypeScript files within Visual Studio with a few tricks and tips. We will also cover how to capture performance metrics.,,,,,, This course is all about productivity, performance, efficiency, and the integration of 2 of the most powerful frameworks, Angular, and ASP.Net Core. Demo of App 1 When I created my first Angular application, I was shocked at how many files were downloaded. Even the simplest Angular application makes 393 requests to the server. No big deal when you are running locally, but try loading that many files without bundling could cost you your client. In order to fully appreciate the techniques used in the Angular.Net Starter App, I will do a quick demonstration. First, we will be in Debug mode, where you will be able to develop, and see your changes quickly, and second, the Release mode, after you have prepared the application for deployment. Demo of App in Debug Let’s restart the application and look at the network tab to see all the files downloaded to run the Angular.Net Starter app.,,,,,,,,,,,,,,,,,,,,,,,,, Now, let’s open the Developer Tools, by clicking on F12.,,, Notice all the files.,,,,,,,,,,,,,,,,,,,,,,,, Also, notice the html and css files associated with its’ component. These will all go away in a minute. Demo of App in Debug 2 I am binding the bundling process to a Git hook which I will explain later in the course, but for now I will tell you all the things we will accomplished during the bundling process. First we separate the framework from the application and create 2 different bundles. We concatenate, minify, and squash the html and css. Then we enable the production mode. And finally we create an application manifest for performing offline. These are all the things necessary to create a Release build. When I did a commit to the Git repository, I automatically created the Release build, and by simply changing to the Release mode, we will run the Release build for our application.,,, Demo of App in Release Let’s change to the Release mode and start again, only this time using the Release build.,,,,,, Then, let’s start up the application to see if there is a difference. I have setup my development environment so that Developer Tools opens whenever I start Google Chrome from within Visual Studio. This way, I can see the Network tab immediately at application startup. I’ll show you how to do that later in the course.,,, We greatly reduced the number of requests made to the server.,,,,,, Also, notice that there are no html or css files that were associated with the components. These files are now compressed into the components, which are now bundled. And, one last thing.,,, We won’t see the warning that says we should enable production mode. You see this warning in Debug mode because we haven’t made a call to “EnableProdMode”. Do you want to know how I used a different build in Debug mode, than I used in Release Mode? Well then, stay tuned because I am about to show you. At the Time this course was created This course will use the latest versions of Angular, TypeScript, and ASP.Net Core, during the time when this course was created. And, this course will use the latest version of Visual Studio. Also, there will be no use for jQuery, React or other legacy technologies.,,, We will however still be using Bootstrap, but without the Bootstrap JavaScript library, since the Bootstrap JavaScript uses jQuery as a dependency. Requirements Starter App Here are the requirements to follow along with this course. First, you should download and install NodeJS globally. When you install NodeJS, it will automatically install NPM, the Node Package Manager. Here is a download link.,,, And here are instructions on how to install.,,,,,, Next, you should download and install the Angular.Net Starter App from GitHub. Here is that web address. https://nodejs.org/en http://blog.npmjs.org/post/85484771375/how-to-install-npm https://github.com/ProMatrix/Angular.Net Project Template I used the following project template when I created the Angular.Net Starter App. And this is my recommendation when creating any ASP.Net Core application with Angular. First select File,,,,,, New,,,,,, Project,,,,,, then choose “ASP.Net Core Web Application (.Net Core).,,,,,,,,,,,, Give it a name,,,,,,, then click OK.,,,,,, Next, choose Web API. Then click OK.,,,,,,,,, If you haven’t learned by now, you should realize that when you are using Angular, you have no need for ASP.Net MVC. Sorry to have to tell you this, but Angular and MVC are mutually exclusive.,,, One or the other, people! Debug Project While we are at it, let’s go ahead and create a project that will assist us to debug Gulp files. It is, by far the easiest way that I know to step into the code of a Gulp file. Gulp files use Node, so it makes sense to add to the Visual Studio solution, a Node console application. So let’s do that now.,,, Right click on the solution and choose “Add”.,,,,,, “New project”.,,,,,, Then scroll down and choose TypeScript,,,,,,, Select “Blank Node.js Console Application.,,,,,, Give it a name.,,,,,, Then click OK. Now we have created the Visual Studio solution for the Angular.Net Starter app. Next, let’s look at the project layout. Project Layout Let’s take a quick look at the Angular.Net project layout.,,, Inside the wwwroot folder is everything that will be published.,,,,,,,,, Inside the app folder are all the source files that are specific for this application. It’s interesting to realize that these files are only necessary for development. What I mean to say, is that once they are bundled, compressed, and you publish the application to the server, these files are no longer necessary. However, my recommendation is to keep them as they are in development, in case you decide to debug from the server. Inside the app folder, I have 3 folders. The common folder contains anything that is common across the whole app, such as the services, or the Animation library. Then there is the features folder.,,,,,, This folder contains the files needed to implement each feature. The feature corresponds to a component and is comprised of 3 or 4 files. I like the way that Visual Studio arranges these files, so that they are easier to maintain. As I mentioned earlier, each component has a number of files associated with it. An html, a TypeScript, a css, and oh, yes of course, a JavaScript file. The last folder worth mentioning is the models folder which contains the client-side viewmodels. These classes are necessary in order to use strong typing, and each class corresponds to a server-side viewmodel.,,,,,, Inside the “dist” folder are all the files that will be distributed to the server. It is this folder that contains the files that will be included in the application manifest. Interesting enough, this is the only folder containing the release build, and it contains the only files necessary to run the application from the server. The other folders, are boiler plate folders used in development and creating the production build. Stepping back into the project folder, we have some project files. These don’t get published, but instead are used in the building the application.,,,,,, The “package.json” file contains all modules and libraries needed for both development and runtime.,,,,,, The “appsetting.json” contains connection strings, the version number, and anything you pass to the middle layer.,,,,,, The gulpfile.js contains the tasks used to automate and streamline the workflow. I plan to show you ways to manage and debug your Gulp files later in this course. Demo of Features I’m not going to bore you with all the details of creating the Angular.Net Starter App, but I can tell you it took months of “trial and error”, and research. If you would like to know how something in the Starter App works, read the Angular documentation or set some breakpoints and step into the code. I will share with you, later in this course, easy and fast ways to develop and debug Angular TypeScript files, as well as Gulp files. Please allow me to quickly show you some of the features of the Angular.Net Starter App. First, from a user’s point of view, then from a developer’s point of view. Ok! Looking at this from a user’s point of view,,,, But before doing that, Let me explain that the features, in the Angular.Net Starter App, are just placeholders for your features. Each feature is easy to remove, or expand upon. I am just using these features to demonstrate the project’s scaffolding and the integration with ASP.Net Core. I see a group of features listed horizontally on the right side. These buttons will navigate me to the feature using the Angular router. Here are the features,,,, “Restart”, followed by, “App cache”,,,, then “Splash,,,, Settings,,,, Features”,,,, “Analytics”,,,, and further right, you will see,,,, the “About” feature, which pops up a modal dialog with project details, such as the version number.,,, The “Restart” button reloads the application. Just a convenience, really. The “AppCache” button will reload the application, specifically the application manifest for offline performance. All other features are using the Animation library to fade into the display of the feature. The “Settings” button navigates you to the Settings feature, which displays information of which mode you are in, and if you are online.,,,,,, The “Features” button navigates you to the Features view. Here you can find more in depth information about the Starter App.,,,,,,,,,,,, The “Analytics” button navigates you to the Analytics feature, which is intended to give performance data and error information. The “Splash” button navigates you to the Splash feature, which animates all the technologies used in this application. The animation of these logos are using the animation directive “expandVisible”, which is part of this project. You will find this library in the common folder. More on that later.,,,,,, The “About” button opens up the “About” dialog. This dialog will tell you the version number of the application that you are currently running.,,,,,, With the animation still running in the background, while the modal dialog is open, it gives the appearance that the application is multi-threaded.,,,,,, Hmmm… Demo for Developers Slice and dice (quick demo) of built in project features. Block Diagram Just like a desktop app, there are many ways to design a web application. The design I use makes it easy to add new features. Basically, the MainFrame components stays alive the whole lifetime of the application or, a better way to say it, while the application is open. The MainFrame owns a directive named “router-outlet”, which is where the features, of the application, will be swapped in and out of.,,,,,, The router is responsible for swapping in and out the features.,,,,,, Then there is a BaseServices class that all other services are derived from.,,,,,, Also, included within the Angular.Net Starter App, is an animation library. This library is a self-contained Angular module, which makes it really easy to reuse throughout your enterprise. More on that subject coming up, so stay sharp. 3rd Party Libraries Many 3rd party libraries are already integrated as part of the Angular.Net Starter App. Following is a list. • Bootstrap, • ng2-toastr, • font-awesome, • rxjs, • lodash, • moment, • and file-saver, These 3rd party libraries are what most enterprise applications will eventually need, and are already included into the Angular.Net Starter App. Before you Begin Before actually setting breakpoints and stepping into the code, I will encourage you to disable the integrated Chrome and IE debugging within Visual Studio. We will go more into detail how to integrate with Visual Studio’s debugger, but for now let me say it is really slow at startup. And that is because an Angular project contains a lot of files in the Debug mode, and these files are not cached. So just for this part of the course I would like for you to disable debugging with Chrome and IE. Here is how to do that… Go to Tools,,,,,,, Options,,,,,,,,,,,,, Debugging,,,,,,,,,,,,, and then scroll down to Enable JavaScript debugging for ASP.Net and uncheck this option.,,,,,, Now your startup will be very quick. From now on, until towards the end of the course, we will be using Chrome’s Developer Tools. Later, I’ll show you how to launch the application with Chrome Developer Tools opening automatically right from within Visual Studio. Big time saver! Coming Up Coming up, in the next videos, we will be looking at the obstacles that you will be faced with, when trying to integrate Angular with ASP.Net Core. There are many, but all have a solution or a workaround. Plan to have a different way of approaching the development of a web application. You will have a faster application with a smaller payload, easier to maintain, and be able to use the same Object Oriented techniques that you have been using for server-side development, such as inheritance. We are going to cover a lot of ground in the next few videos, so stay tuned. Welcome Welcome back to this ProMatrix course titled, “Angular and ASP.Net Core”. I’d like to take this opportunity to share some of the obstacles that you will be faced with when integrating Angular with ASP.Net Core. Many are the same that you will face integrating any modern client-side framework, but most are specific to Angular. Please keep in mind that the key is automation. As a Microsoft developer, we expect to stay within the Integrated Development Environment, and consider it less productive to need to drop down to the command line, or merge files manually, or make changes depending on the configuration we are in, Debug or Release. Let’s overcome any obstacles that will compete for our attention. How to Access the Node Modules When I first looked at the Angular “Quick Start” tutorial, I was approaching it in the same way as most developers. The tutorial is brilliant, but doesn’t assume any specific development environment. It is important to realize that an ASP.Net Core application can access anything within the wwwroot folder. And only things within the wwwroot folder. If you didn’t realize that before, then you will, once you have create an ASP.Net Core project, and start adding the Angular framework to the node modules. One of the first questions you are going to ask is, “how can I access the node modules from within my running application, unless I copy them to the wwwroot folder”. Normally you can’t. However there are some tricks you can play that will allow the router to serve up these files to you from the node modules folder. That’s good! Because copying these files all the time, to a place where the running application can get to, would be a maintenance nightmare and a complete waste of time. You should understand that access to the node modules folders is only necessary when running in debug mode, that is, before you create a Release build. You should think of creating the Release build as a compilation process, as it is with C#.,,, What does that mean? That means that in a debug mode, you are not interested in compressing, bundling, or bumping up the version number. And why should you? Shouldn’t your first priority be to get the application working, before creating a release build?,,,,,, The Release build process can be a complex process that does many things. It’s more than a compression and a bundling process. In fact, to do it right, you need to bump up the version number, squash the html and css, EnableProdMode, and create an application manifest, all during the Release build creation process.,,,,,, All of these things are triggered by a Git Hook. More on that later.,,,,,, Many of the developers I have spoken to, are bundling every time, even in debug mode, to avoid the issue of “how to get to the Node Modules”. Completely and totally a waste of time and machine cycles, and it slows down the workflow. Realize that the client-side development is not too much different than the server-side development, in that you first get your application working in a debug mode, where you can set breakpoints and do analysis, then you create a Release build. Anyway, back to addressing the issue of, “how do I get to my node modules in a debug build?” The two files that are involved are the “startup.cs” and the “systemjs.config.js”. First, let’s take a look at the “startup.cs” file. Project Root Folder Access to the project root folder is the key to a lot of things. And, if you don’t know by now, I’m telling you, that the startup.cs file is a significant file to make this happen. It determines how the files get served to the application. This is a very deep topic and fortunately, for me, it is out of the scope of this course. But I will show you how to serve up files that you normally couldn’t get to, and how to switch out index.html files depending on what mode you are in, Debug mode or Release mode. And I will show you how to implement this without using MVC. Any ideas why we need 2 different index.html files?,,, We will come back to that in a minute.,,, So what’s going on in the startup.cs file?,,, What’s going on in this code right here?,,,,,, Basically, in this code we are saying “anytime we reference this folder, the “project root folder”, drop-back into the project root to locate the files”.,,, And notice that this only happens in Debug mode.,,, SystemJS The “systemjs.config.js” is as significant of a file on the client-side as the “startup.cs” is on the server. This file is responsible for how and what files get loaded. Let’s examine this file. Notice on line 9 that we are referencing the “project root folder”. Now, when the server-side router sees this folder name in the path, it will assume the path of the project root folder. This only works in debug mode, on your local machine. And that is the only place we need it to work, because before we publish the application to the server, we are going to create a Release build. Then we have no need to get to the node modules.,,, A good exercise, is to launch the Angular.Net Starter App, in Debug mode, and look for these files in the Network tab, of the Developer Tools, and make a note of the requested URL. Debug Vs Release Let’s think about Debug verses Release, and how to abstract the debug and release modes. The issue is that you really need two different index.html files, one for Debug mode and the other for Release mode. I don’t want to be swapping out index.html files, depending on what mode I am in. I only want to change the mode from Debug mode to Release mode, and I do that by simply changing the selected item in the Solution Configurations dropdown list. Let’s address the question of “why do we need two different index.html files”. Because, • The Release build should be bundled, and the Debug build should be unbundled. • In the Release build, we make a call to Angular’s “EnableProdMode”. The Debug build should not make a call to “EnableProdMode”. • The Release build, will be minified and we will remove all debugger statements. For Debug purposes, the Debug build cannot be minified. • In the Release build, we squash the components’ html and css into the component. In the Debug build it’s faster to have the html and css outside of the components where we can use a normal html and css editor. • In the Release build, we bump up the version number. In the Debug build it is not necessary to bump up the version number. • In the Release build, we will create an application manifest, which will allow us to perform offline. This is an extra step that is not necessary for running in Debug mode, and before we publish to the server. And one last thing to consider.,,, The index.html file, for Release mode, is different than the index.html for Debug mode. As you have seen from developing C#, the Debug build is much easier to debug than the Release build. Well guess what? TypeScript is no different. It will always be more productive to develop with a Debug build before creating a Release build. In fact, I normally bind the process of creating a Release build to a “pre-commit” Git Hook. By doing it that way, the Release build is created automatically every time I commit my changes, and before I publish to the server. Startup.cs Then how do we request a different index.html file depending on the mode we are in? And how can we do this without using MVC? The answer, again lives in the “startup.cs”. Here we can request a different default index.html depending whether we are in debug or release, and the router will automatically serve up the appropriate index.html file. In Debug mode, our default html is declared in this line of code,,,,,,, but, when I change to the Release mode,,,,,,, it is declared in this line of code.,,,,,, Now, there is no need to change the index.html, the URL, or anything except the solution configuration in order to serve up the appropriate index.html. Hooks to Create a JavaScript Release Build Let me talk about hooks to create a JavaScript Release build. We have already discovered the huge performance gains to creating a Release build, but how can we automate the build process? Are there hooks we can use, or do we need to do this manually? Well, you could do it manually, just before you publish to the server, but there may be other things that you need to do, such as bumping up the version number. The answer is using a combination of NodeJS, Gulp, and Git Hooks.,,, Let’s take a quick look at the Task Runner Explorer. Here are all the Gulp tasks that are part of the creation of the Angular.Net Starter App. Many are responsible for creating the Release build.,,, Here is the Gulp task responsible for creating the JavaScript Release build. To execute this task, you can double-click on this task, in the Task Runner Explorer, or you can bind it to an event. Let’s take a look at this Gulp task.,,,,,, You may notice that it has a dependency that will be completed first, before doing the bundling.,,,,,, The way this task is written, it will first increment the project version number before doing the bundling for a Release build.,,, When I first looked into this issue of, when to create a Release build, I ran into many issues. The first issue that I ran into, is that it’s impossible to know what configuration mode you are in, Debug, or Release, in order to know if creating a JavaScript Release build is necessary or not. The Solution Configurations dropdown list gives you the ability to switch from Debug mode to Release mode,,,,,,, but it is not possible to determine which mode you are in, to determine if it is necessary to create a Release build for the JavaScript. It seems inefficient too create a Release build all the time, even when you are in debug mode. Hmmm… The gulp task runner will allow you to bind to specific events, such as the before build event, however, here again, this build event doesn’t distinguish between Release and Debug. I prefer a more streamlined approach. The approach that I prefer for creating a Release build, is to bind the Release build process to a Git hook. By placing a pre-commit script file in the git hooks folder you can run the scripts every time you do a “commit”. It is important to point out that you will need to do a “commit” before publishing to the server, however you should do that anyway. Development Workflow The basic workflow for your development process should be to first, get your application working in debug mode, commit to the git repository, then publish to the server the release version of your code. This is probably the same workflow that you are already accustomed to. Features of the JavaScript Release Build The Angular.Net Starter App has many features that can make your application perform faster and make it easier to maintain, and one of the main the features is creating a Release Build. However, by now, you should realize that the Release build, is only used in Release mode. As an example, before you will published to the server. Creating a Release build, is one of the features that does many things in one process. Within the Angular.Net Starter App, I am using the pre-commit git hook to automate the following tasks for the Release build. Here is a list of all the things accomplished by creating a Release build using the routines provided by the Angular.Net Starter App. • Separate the Angular framework code from the application code, • Bundle the Angular framework with the 3rd party libraries, • Minify the Angular framework bundle, • Squash the HTML and CSS into the components, • Bundle the application code, • Minify the application bundle, • Enable the production mode, • Create an application manifest, • And bump up the version number, These are all the features that occur automatically, when creating a Release build using a pre-commit Git hook. It is important to realize that you will not be able to do a commit, to fully see how this works automatically, unless you are using your own Git Repo. This git hook works for me, on the original Angular.Net Starter App Git repository, because I own that repository. If you are pointing to your own repository, this will work for you. Later, in this course, I will detail how to debug your Git Hooks. Bundling Techniques There are many bundling techniques as well as philosophies of which is the best way to bundle JavaScript for a web application. In fact, some are way over the top. I always like to examine how things are accomplished on a desktop application, then try to mimic the same behavior for creating a web app. Let’s first look at how a .Net desktop app gets installed, then see if we can mimic this behavior. To use a desktop app, you first download and install the .Net framework.,,,,,, Then you download and install the application, which also installs the 3rd party libraries, as well as the desktop application.,,,,,, But what happens if there is an update to the desktop application? Well, that is the pain point with a desktop application. There is no automatic way of getting the update without downloading and installing the update. And this is where a web application has it all over a desktop application. The good news is that updating the desktop app should go fairly quickly, since we don’t need to download and install the .Net framework or 3rd party libraries. So I recommend that we take that same approach for installing a web application as we do a desktop application. But how can we do that? Well, let’s look at the traditional method for bundling a web app. The popular method is to bundle the Angular framework, the 3rd party libraries, and the application, all in one big bundle. This approach will favor the new user. But what happens when the application gets updated? How does that affect the returning user? Well, unfortunately, it will be necessary to download the one big bundle again. Hmmm… The approach that I recommend is to create 2 bundles, one bundle for the Angular framework and 3rd party libraries,,,, and another bundle for the application.,,, This way, when the application changes, the user will only need to download the updated application bundle.,,, Easy peazy lemonade squeazy. Auto Restart 1 Some days I spend the whole day working on TypeScript. One of the handiest features of Visual Studio, is a feature called “Browser Link”. You have probably used it when creating your MVC applications. This feature reloads your application, anytime it detects a change in the project’s wwwroot folder. Pretty awesome, really, and it can save you a lot of time!,,, Browser Link works great when you create a project using the ASP.Net Core MVC project template. However, this feature doesn’t work when you create a project using the ASP.Net Core WebAPI project template, which I did with the Angular.Net Starter App. And since we have no need for MVC, jQuery, or SignalR, I implemented this requirement a different way and basically here’s how it works. Auto Restart 2 During startup, the application makes an asynchronous call to the server, then waits there until another call is made to the server before returning back to the application, which will restart the application. The second call to the server originates from a gulp task that is watching for any change to any file in the app folder. When the watch task detects that a file has changed, the gulp task makes a call to the server to tell the application to return from the wait, which will restart the application. Maybe this doesn’t seem like the most elegant way to do it, but it works flawlessly and doesn’t require MVC, jQuery, SignalR, or any other technology. Let’s do a demo. Auto Restart 3 The ASP.Net Core WebAPI controller that is responsible for handling the restart request from the Gulpfile is the SyncController. I already set breakpoints on lines 34,,,,,,, 54,,,,,,, and 55.,,,,,, Now let’s start the application.,,,,,,,,, We just hit our first breakpoint, where we are going to wait. Hit F5 to continue.,,, It may seem like we are in an endless loop because we didn’t get to line 55, however we will get to line 55 once we request restarting the application by changing any file within the app folder. So let’s do that now.,,,,,, Let’s open any file in the app folder, and make any change, then save the file. Once the gulp watch task sees the change, it will make a call to the server that causes the return of the first call to the server. Upon returning from the server, the client-side code will reload the application. Kind of complicated I know. Anyway, I’m making a file change,,,,,,, and saving.,,,,,, Now see what happens.,,, I hit another breakpoint on line 34.,,, This is from the Gulp task that made a request to the server, after seeing a file change.,,, Then I will hit F5 to continue. Now I hit the breakpoint on the break.,,,,,, Another play on words. But I think you know what I mean. I’m going to remove that breakpoints here to eliminate some confusion. And finally, I will hit F5 again to continue and the application will restart. Restart Issue This method of restarting the application works, but it has 1 issue. And that is, when you make a call to the server, and don’t return for an indefinite amount of time, eventually the server will timeout and return a 502 error. A good exercise is for you to look at the code and try to figure out how I accommodated for that issue. Coming Up We just learned how to get to our node modules while in Debug mode, and how to abstract and serve up the appropriate index.html file, depending on the mode we are in. We also learned all the things that can be accomplished during the Release build process, and a few ways to hook into events that will do the build for us automatically. And finally we learned how to restart our application upon changing of any file in the app folder. In the next video, we will discover how easy life can be if we allow NodeJS and Gulp to do the heavy lifting for us. It’s all about automation people! Almost everything you do, there is the easy way, and then there is the hard way. The easy way allows you to concentrate on what is important, such as gathering requirements and doing development. However, the hard way, has you dropping down to the command line every few minutes to perform a task that could have been automated. Stay tuned as I am about to show you ways to make your life more enjoyable, and fun, which will give you more time to,,,, well,,,, slack off. Welcome Back Welcome and thanks for returning to this ProMatrix course titled, “Angular and ASP.Net Core”. I would have never guessed that I was going to need Gulp and NodeJS to be an efficient Microsoft application developer. Now I truly can’t live without these 2 technologies. In case you didn’t know, NodeJS comes with NPM, which is a repository for storing Node packages. And Gulp is a JavaScript task runner that lets you automate tasks. You can use Gulp tasks for everything from downloading and updating libraries to restarting your application anytime a file has changed. And you can bind these tasks to events, such as build events, and Git hooks. In this course I will explore all the things that you can do to let NodeJS and Gulp do the heavy lifting. Binding with Project Events and Git Hooks Visual Studio gives you many options for binding with Build events and Git Hooks. But before getting into that, let me explain that I have implemented an easier way to organize my gulpfile by breaking it up into smaller, more manageable gulp files. I’ll talk about that, as well as other techniques that you can use NodeJS and Gulp later in this course, but in meantime, here are all the events that you can bind to, using Gulp. • Before Build,,,, • After Build,,,, • Clean,,,, • and, Project Opens,,,, Many Microsoft developers have switched over to a Git repository for source control. Visual Studio can use Git Hooks to trigger executing custom code, which can do about anything. You must name the file of your custom code, with a specific name that corresponds with a Git event. And, by placing your custom code in a folder named “Hooks”, in the Git folder, your custom code will execute whenever that Git event occurs. Here is a list of Git events that we can hook into. • applypatch-msg,,,, • pre-applypatch,,,, • post-applypatch,,,, • pre-commit,,,, • prepare-commit-msg,,,, • commit-msg,,,, • post-commit,,,, • pre-rebase,,,, • post-checkout,,,, • post-merge,,,, • pre-receive,,,, • update,,,, • post-receive,,,, • post-update,,,, • pre-auto-gc,,,, • post-rewrite,,,, • and, pre-push,,,, I normally like to use the “pre-commit” Git Hook to trigger the creation of a Release build, because I always do a commit before I publish to the server. Task Runner Explorer You can launch the Task Runner Explorer by doing a right mouse click on the gulpfile.js and choosing Task Runner Explorer from the context menu. Within the Task Runner Explorer you will see all the Gulp tasks. Many of the task are dependencies used by other tasks, but many are stand alone. Here is a list of the stand-alone gulp tasks used to prepare the application for development and deployment. • bundle-css-dev,,,, • concat-libraries,,,, • bundle-js,,,, • and, bundle-app-release,,,, After running these 4 gulp task, you will have created all the bundles. The last one, “bundle-app-release”, is only necessary for a release build, so you must run it before publishing the application to the server, but it is not necessary for the debug mode. By the way, you have probably figured this out by now, but if not, when I mention the Debug mode, I mean when your project is under development, before publishing to the server. Release Bundle Quick Look Let’s quickly look at the task “bundle-app-release”. You should notice that it has a dependency, which is the “increment-project-version” task. What this means is before we run the task “bundle-app-release”, we will run the task “increment-project-version”. You can also run this task, and other tasks by simply doing a right mouse click on the task name in the Task Runner Explorer, and choosing “Run”, or you can just double click on the task name. Publishing Gulpfiles Another Gulp task that is a stand-alone gulp task is titled “npm-publish-promatrix-gulpfile”. This task has a dependency that will bump up the version number, before it publishes the gulp task files to NPM. By doing this task, I will publish the gulp files to the Node Package Manager, then I can reuse the gulp files on all my projects. Another huge productivity gain! One interesting thing to note about publishing libraries to NPM. You can’t upload my libraries to my NPM repository, however, you can download and use my libraries. And, you can create your own libraries and publish to NPM, then I can download and use your libraries. I’m explaining this so that you understand why the Gulp tasks that are publishing my libraries won’t work for you. However, you will be able to use the methodology to publish your own libraries. I created an Animation library for you to use with your applications, and the gulp task to publish the Animation library is titled “npm-publish-ng2-animation”. Again, this gulp task won’t work for you, but you can see how to use this methodology. Watching for Changes in Source Code Let’s take a quick look at the gulp task titled “watch-source-debug”. Notice that it contains a gulp watch method. What’s happening here, is that gulp is watching for a change with any file in the app folder, and when there is a change, gulp will execute the “reload-application” Gulp task. I mention this here, because using the Gulp watch is just another way you can trigger the execution of another Gulp task. Code behind the Gulp Task Let’s take a deep dive into the code behind the “bundle-app-release” gulp task. But first, I should mention that the gulp files are located in the node modules folder. As I mentioned earlier, by publishing the gulp files to NPM, I can use these in many projects, and so I do. Let’s expand the promatrix-gulpfile library folder. Here you see the JavaScript files that contain the gulp tasks, then when you expand the exports folder, you will see the corresponding JavaScript files with the actual code that is behind the gulp task. There are several advantages to arranging your files like this. One advantage is that you now have more encapsulated and easier to manage gulp tasks. Also, since you have exported methods, it’s much easier to debug the gulp tasks. More on that subject later in this course. OK, now let’s take that deep dive into the code behind the gulp task “bundle-app-release”. Deep Dive 1 Notice that we have a dependency for the gulp task “bundle-app-release”. The “increment-project-version”, runs first, then it runs the code behind the gulp task. Here is the code behind the gulp task “bundle-app-release”.,,,,,, There is a lot going on in this code, and this code can run stand-alone, however, I am using the pre-commit Git hook to automate this process. So here is what’s going on. Deep Dive 2 First, we add a line of code in the bootstrap.js file that will enable the prod mode.,,,,,, Then we squash the html and css files into the Angular components.,,,,,, Next, we separate the framework code and the application code into two bundles.,,,,,,,,,,,, We minify here.,,,,,, We remove the “enable prod mode”.,,,,,, We unsquash the components.,,,,,, And lastly, we create an application manifest so that the application can run disconnected from the Internet. Versioning the Project 1 Versioning the Project can have some interesting challenges. One of the challenges is to get the version number, as well as other information to the client-side code. I have found this method to be the most reliable and easiest to implement. And, normally I bind the “Increment Project Version” to a pre-commit git hook. But you could bind it to a build event as well.,,,,,, Here are the key components for this process. First and foremost is the “appsetting.json” file that contains the version number. It will contain other information that will eventually get propagated to the server, such as the database connection string. Versioning the Project 2 Then from within the ever so useful and accommodating “startup.cs” file, I have created a C# class that I call “Application Configuration”. Clever name huh? Anyway, this class contains 3 properties, the connection string, the version number, and the Splash Time in milliseconds.,,,,,, The connection string is unnecessary for this application, since I am not using a database, but I put it here for demonstration purposes, to show you how you can abstract it from the rest of the code. Versioning the Project 3 OK. Here is an interesting difference from older versions of ASP.Net. In older versions we used the web.config for abstracting the application settings, such as the connection string. Now, we use the appsetting.json file. And these parameters will eventually get compiled into the ASP.Net application code. Now, when we want to bump the version number to the next increment, we run the gulp task “increment-project-version”. This works great to incrementing and integrating the version number with the app, but how do we display this information to the end-user? We simply call a server-side WebAPI endpoint, which will return these values to the client in the object, DevConfig.,,, Let’s take a look at that class.,,,,,, I recommend that you set a breakpoint in the Http Get method of the SysInfoController.cs, and see that you can return the version number to the client to display in the “About”, dialog box. Code Separation before Bundling There are several bundling techniques which can reduce the download payload which in turn will increase the performance of an application. The one I like to use has a completely different concept that is closer to how a desktop application works. The simple explanation is that there are 2 bundles. One for the Angular framework and 3rd party libraries that will seldom change, and the other for the application, which will probably change frequently. This approach gives favor to the user that is returning to the application, and does not favor the first time user. The concept is that the application, which is always changing, is in a much smaller bundle, and will only take a fraction of the amount of time to download, than it would take to download 1 big bundle. Here is how this type of bundling works. Code Separation 2 You supply the entry points for two files.,,, One entry point is for the application which is the bootstrap.js, and the other entry point is the imports.js. The import.js file contains the required modules and libraries. Let’s take a look at the import.js file.,,, Here you will see listed all the Angular framework and 3rd party libraries. So, what is actually happening here? Well, the bundler will create two different bundles.,,, It will extract all the code that is common to both entry points to create the bundle.js. And, again, the bundle.js will contain the Angular framework and the 3rd party libraries. The other bundle, the application.js, will contain only the application, and not the Angular framework or the 3rd party libraries.,,, The import.js is only used during the bundling process. It’s not used in the application in any way except giving us a way to separate the application code from the framework.,,, By utilizing this approach to bundling, the Angular.Net starter application bundle went from 2 megabytes, to 60k bytes. Sure. This seems a little over the top, but that’s what it takes to create a very performant web app that favors the returning user. Now, when the application changes, and a user returns to the application, the application will receive the smallest payload possible. A huge performance gain! Adding Angular Modules and 3rd Party Libraries Adding modules and libraries is something you will eventually need to know how to do. There are a few files that will need to be modified. Let’s use as an example a scenario where you want to add the Animation module. In this scenario, we import the BrowserAnimationsModule into our AppModule,,,, here,,,, This is in the TypeScript file mainFrame.ts. Next, add a reference to the module in the systemjs.config.js.,,, Add, lastly, add a reference to the module in the import.js.,,, Now, after the bundling process, the BrowserAnimationsModule will be bundled with the rest of the Angular framework. Publishing the Animation Library One of the most productive things that you can learn as an application developer, is how to create a library that you can reuse in other applications.,,, This used to be more difficult, but now it is easy.,,, All you need to do is obtain a free NPM account, create and publish your library, then you can use the same library in all your applications.,,, After making changes to your library, the only thing that you need to be concerned about is updating the version number before republishing your library. I created an animation library that will demonstrate how this all works.,,, Please look at the package.json file within the animation folder, “ng2-animation”.,,,,,, The only requirements in this file, to publish the library, are the name of the library and the version number.,,, When you publish, or, upload your library, you will publish everything in the ng2-animation folder.,,, Let’s take a quick look at the 2 Gulp tasks that will be used to publish this library. First, take a look at this task, npm-bump-ng2-animation.,,, This gulp task is responsible to increment the version number.,,, Next, let’s look at the gulp task, npm-publish-ng2-animation. This one is responsible for publishing the animation library.,,, Now that I have published my animation library to my npm repo, I can reuse it across all my applications. Huge productivity gain.,,, I’m not quite sure if I mentioned it earlier in the course, but it is important to know if you are collaborating with your team to publish a library, then it will be necessary to get a paid account.,,, A single user publishing to npm is free, but a team publishing is not free. Reusing the Animation Library Previously, I was talking about uploading the animation library. Now, I’ll talk about downloading and reusing the animation library in your projects. In the common folder, I keep services and libraries that are common to all the components in the application. This is a good place to keep all the libraries that your team may want to share with other projects. Please notice the package.json file in this folder. A little confusing I know, because there is one package.json file assisting with upload, and this one is assisting with download.,,, But try to understand that this file is responsible for determining what libraries are downloaded as part of this application.,,, Notice the dependencies object in the package.json file.,,, This will be used to retrieve, or download, the “ng2-animation” library, that I was talking about in the previous video.,,, If you examine the gulp task titled “update-app-packages”, you will see how you can bind to the “Project Open” event to update the Animation library to the latest version.,,, This way, all you need to do is to open your project, and your libraries will immediately be updated to the latest version. It may seem unconventional to have a node modules folder away from the project root folder, but by doing it this way, you have the advantage of being able to make updates to your libraries and publish the libraries to npm. Just like any other library that you are going to publish, you should test it well before publishing it.,,, And why is that?,,, Well, you tell me!,,, Squashing HTML into your Components Once you start developing components for your Angular application, you will need to create html and CSS files that support your components.,,, First, let’s look at a TypeScript file which references an html template URL and a CSS style URL.,,, Let’s take a quick look at html file that is referenced within the “settings” component.,,,,,, You can put the html directly into your components at design time, however, if you do that, you will not be able to benefit from using an html editor.,,, So I like to use a separate html file, and then reference it within my component.,,, This works great running locally in Debug mode, but before bundling and preparing for deployment, it is a good idea to squash the html and CSS into the components.,,, Let’s take a look at the JavaScript file generated from the TypeScript file.,,,,,, Here is how it looks before we squash it.,,,,,, Now I will squash it. I’ll squash it by double clicking on the squash Gulp task, but this can be done automatically by running the “bundle-app-release” Gulp task.,,, ,,,,,, And, this is how it looks after I squash it.,,, We just squashed both the html and the CSS into the component.,,, And we did the same for all the components.,,, What does this do for us? It reduces the number of files downloaded which decreases the time to launch the application, which increases the performance.,,, Big performance gain! Debugging Gulp Demo 1 Debugging your Gulp tasks can be an interesting challenge. I struggled with this one until one day, I came up with what turns out to be an easy solution.,,, It’s really quite simple, but it involves creating another project, which is a NodeJS Console Application. Here is a quick demo, then I’ll explain how it works. Debugging Gulp Demo 2 First, set the DebugGulpfile project as the startup project.,,,,,,,,,,,, Next, select the DebugGulpfile in the Task Runner Explorer.,,,,,,,,,,,, Open the tasklist.js file.,,,,,, Set a breakpoint on line 49 of the tasklist execute method.,,,,,,,,,,,, Now start the application but hitting F5.,,,,,,,,,,,, Then double click on any task in the Task Runner Explorer. For now, I will double click on the print-time task.,,,,,, Notice how I am able to step right into my code.,,,,,,,,,,,, Keep in mind that we are stepping into the code of the other project, the Angular.Net Starter App project.,,, So, what’s going on and how does it work?,,, The secret is to export the methods that you want exposed, and then import them into the JavaScript file that will step into the code.,,, Pretty basic after you learn the power of Node and how to use JavaScript during development. Debugging a Git Hook Overview I prefer to use NodeJS as my scripting language for a Git Hook, but as I understand, you can use Shell scripts, Bash and others. Not wanting to learn yet another technology, I went with NodeJS which of course, is just JavaScript on steroids.,,, Before doing this, let me point out one serious Gotcha that you will want to keep in mind whenever you are referencing code in another project’s folder.,,, The executing code, will assume the path of the startup project, as being the root directory, so it is necessary to pass in the path of the target project to use as the root directory. In the case of the Git Hooks, they are in a more difficult folder to find.,,,,,, Do a right mouse on the solution,,,, then choose “Open Folder in File Explorer”.,,,,,, Drill into the Git folder,,,, then the Hooks folder.,,,,,, Here is where the Git hooks are kept.,,,,,, Also, while we are here, notice that the implementation of the Git hook is in a different file which makes it easier to step into.,,,,,, The bad news is, that maybe it’s not so simple to debug a Git hook, but the good news is that you should be able to set breakpoints, and step into the code to learn for yourself.,,,,,, Let’s do that now. Debugging Git Hook Demo Just as before, we make the DebugGulpfile project the startup project.,,, Also as before, we select the DebugGulpfile in the Task Runner Explorer.,,, Let’s set a breakpoint on line 76 of the tasklist.js.,,, Next, hit F5 to begin execution.,,,,,, Let’s double-click on the “pre-commit” Gulp task, in the debug project, and step into that code.,,,,,, You see! That wasn’t so bad.,,, Also, while we are here, notice that I passed in the path for the target folder, since it is in a different project.,,, For an exercise, try stepping into some of the other tasks. Keep in mind what I explained about referencing code in other folders and executing the code originating from different execution points. Creating the Application Cache Manifest Creating the application cache manifest is another process that is performed at the time of creating a Release build. With an application cache manifest, your web applications can run completely offline. And here is how it works.,,, During the bundling process, a call is made to the “createAppManifest” method.,,, This method traverses through the “dist” folder and creates the application cache manifest based on the names of all of the files in the “dist” folder.,,, Take a look at the application cache manifest that was created at the time of bundling.,,,,,,,,,,,, OK! Let’s give it a try. Why not use Google Chrome since it performs well with the application cache.,,,,,, AppCache 2 After deploying the application, you can start the application and then once the application is loaded, click on the appcache button.,,,,,, This will navigate to the appcache.html that will reference the application cache manifest file.,,,,,,,,, Make sure that you don’t have Developer Tools open when you do this, because it will inadvertently clear the application cache.,,,,,, Before disconnecting from the Internet, let’s take a quick look at the app cache and make sure everything is cached as expected. One thing that I really like about Google Chrome is that you can see what is being cache. You can get to this internal URL to see all the applications that are currently cached. Let’s click on the manifest and take a look. There she is. Just as expected! It’s important to point out that the main html file, the appcache.html file, is also in the manifest.,,, Ok, Great! Now let’s see if we can perform off-line, disconnected from the Internet.,,, I’m doing that now.,,, I’m pulling the plug. You might say “I’m pulling the plug on this project”.,,, I’m going to close the application, then restart my browser, and make sure that we are offline.,,, Let’s try some of my favorite websites to make sure that we are truly disconnected.,,,,,,,,, Yep.,,,,,, We are off-line. So let’s see how our application will perform disconnected from the Internet.,,,,,, The important thing here is to navigate to the appcache.html file.,,, But, before that, let’s try going to the index.html file, which, by the way, is not cached.,,,,,, No big surprise I guess. What about navigating to the appcache.html.,,,,,, Will you look at that? We see the toastr message that is warning us that we are offline. Huh? Well, let’s see if the other features are working. Let’s click around a little bit.,,,,,,,,,,,, Yay! It’s working as expected!,,,,,, Coming Up This was a busy module. In fact, I thought I would never be finished with it.,,, Lots of fun though! Let’s take a snapshot of all the things covered in this module.,,, Here is my list, to compare with yours.,,, We went through, • Binding with the project events and Git hooks,,, • Publishing gulpfiles,,, • Watching for Changes in source code,,, • The Code Behind the Release build,,, • Versioning the project,,, • Code separation before bundling,,, • Adding Angular modules and 3rd party libraries,,, • Publishing the Animation Library,,, • Reusing the Animation Library,,, • Squashing Html into your Components,,, • Debugging Gulp files,,, • Debugging a Git hook,,, • And, Creating the Application Cache Manifest,,, In the next few videos, we are going to explore how to more tightly integrate the client-side code, with the server-side code. We will also learn how to take full advantage of Visual Studio, and all it has to offer to create awesome solutions. Welcome Welcome to the final module for this ProMatrix course titled, “Angular and ASP.Net Core”. In this module we will concentrate more on productivity by using Visual Studio, integrating with the ASP.Net Core framework, many debugging techniques, such as concurrent debugging, performance analytics, and TypeScript OO techniques, such as inheritance. We will cover these things, and more, in this final module. Development Configuration 1 The Development Configuration object, can contain any parameters that you would want to pass to the client. These parameters can assist with development, or just be useful information such as the current version number of the running application. This object is requested at the startup of the application. I was happy to learn that calling a WebAPI endpoint, with the Angular HTTP service, is a piece of cake. Let’s take a look at the fundamentals. First, let’s have a look at the server-side view model for the Development Configuration object.,,, The DevConfig class has 6 parameters. The “Debug” parameter will indicate to the client whether we are in Debug mode or Release mode.,,, The “Testing” parameter is a software switch to facilitate testing. More on that later.,,, The “Splash Time” parameter is used for timing the Splash view.,,, The “Version Number” parameter comes from the appsetting.json file which is manipulated by the pre-commit git hook and the build event.,,, The “Online Status” parameter indicates whether the application is online, or disconnected from the Internet.,,, And finally the “App Cached” parameter indicates that the application has been cached and is ready to perform offline.,,, Development Configuration 2 Next, let’s take a look at the client-side view model for the DevConfig object.,,, Notice the similarity with the server-side view model. Yes, the only difference is the naming convention.,,, Don’t worry about the parameters name’s starting with lowercase, because the HTTP service will provide the mapping for this automagically. Why not set a breakpoint to see this in action.,,, But first, I want to go into detail about a subject that is mostly ignored when exploring client-side code.,,, This subject can make your code much easier to maintain, and to make your code reusable. The subject is TypeScript inheritance.,,, Oh yes! We are going to talk about another subject that will make us even more productive! Inheritance for Angular Services Most Microsoft developers understand the significance of inheritance, when writing their server-side code, but don’t really understand how to make this object oriented principal useful in the client-side code.,,, The principal is the same on the client-side, and it gives you the same benefits. The Angular.Net Starter App has an Angular service which all other services are derived from. This is a TypeScript file called “baseServices.ts”. This class contains the logic for making the restful calls to the server. It contains a “Get”, “Put”, “Post” and “Delete” method.,,, It also contains the logic to log any errors, and maintains caching objects in the local storage for the “Analytics”. You do understand why you want to be able to reuse this kind of logic throughout your application’s services? And have it only in one place? You do. Don’t you? Setting TypeScript Breakpoints in Visual Studio 1 At some point, you are going to want to know how to set a breakpoint in a TypeScript file within Visual Studio. By using Visual Studio to debug TypeScript, you can much easier debug both client-side, and server-side code all from within the IDE. Make sure you enable the integrated debugging of Chrome and IE, and here is how you do that… Go to Tools,,,,,,, Options,,,,,,, Debugging,,,,,,, and then scroll down to Enable JavaScript debugging for ASP.Net and check this option.,,,,,,,,, Now, when using IE as your browser, you will be able to set breakpoints within a TypeScript file and step into your code, from within Visual Studio. Setting TypeScript Breakpoints in Visual Studio 2 I have set 3 breakpoints, 1 on the client before making the call to the server, 1 on the server, and yet another on the client after returning from the server. Now I am going to launch the application and wait, wait, wait for it. Setting that Breakpoint 3 Sometime later, maybe as long as a minute, we will hit our first breakpoint, on the client, before calling the server. Hit F5 to continue, and we will hit our next breakpoint only this time we are on the server. Let’s examine the DevConfig object, then hit F5 to continue. Setting that Breakpoint 4 Now, we have reached our last breakpoint back on the client.,,, Let’s examine the DevConfig object now.,,, You’ll notice that because of the strong typing, and the internal auto-mapping, there’s nothing else to maintain, except a view model on the server and on the client.,,, Easy Peasey Lemonade Squeezy. WebAPI Exceptions 1 ASP.Net Core applications need a different method for returning exception data back to the Angular services. The Angular.Net Starter App implements a technique to return useful exception information back to the client, which is later stored on the client for analysis. Here is how it works. In the Angular.Net Starter App, all WebAPI Controllers are derived from a base controller. In this case, I didn’t need to spend a lot of time trying to think of a clever name for the base controller so I just named it “BaseController.cs”. Here is how to extend the ExceptionFilterAttribute for passing exception details back to the client. WebAPI Exceptions 2 First, create a class called “CustomExceptionFilterAttribute” which extends ExceptionFilterAttribute.,,,,,, Now override the OnException method.,,,,,, Then, decorate the base controller with the attribute CustomExceptionFilter. In the BaseController, which all controllers are derived from, implements a method called ExceptionHandler.,,, This is where you will format a message that will be sent to the client. You will be sending useful information, such as the controller and method where the exception originated. Now each WebAPI controller’s methods, the get, put, post, and delete methods, should be wrapped in a try catch where the catch calls the base controller’s ExceptionHandler. Ok, let’s give it a try… WebAPI Exceptions 3 I temporarily put a throw exception in the get method of the Sys Info controller. Please take a look. And to make the demonstration a little more self-contained, I’m going to switch to the Release mode. Now when we start the application, we should see the exception information sent from the server.,,,,,, Also, if we go to the Analytics feature, we should see the detailed exception information.,,, This is how you capture a server-side exception, then notify and log the exception information. Debugging TypeScript 1 Didn’t Complete As a Microsoft developer, you know how important it is to stay within the IDE. Not only is it faster, which is more productive, but you don’t need to keep track of which window you are working in. This allows you to just concentrate on doing development. Visual Studio allows you to debug JavaScript and more importantly TypeScript. And Visual Studio 2017 allows you to use Chrome as your browser of choice. First, as I explained earlier, you will need to enable JavaScript debugging for ASP.Net from the Tools Options, then choose Chrome as your Web browser. Now when you start debugging, by hitting F5, you will launch the debugger using Chrome as your Web browser. Using chrome for debugging within Visual Studio has the advantage of starting faster than IE. Debugging TypeScript 2 (Deprecated) Didn’t Complete Let’s put a breakpoint on line 55 of the mainFrame.ts and a debugger statement on line 56. Which should we hit first?,,, Notice that we don’t hit the initial breakpoint. However, if we restart the application, by clicking the restart button, we will hit the initial breakpoint. Probably a caching issue. OK. No big deally’O!,,, Another problem I’ve found when debugging with Chrome in Visual Studio, is that sometimes it hangs when you try to stop debugging, or try to restart debugging. I’m not sure what is going on there and I haven’t found a workaround for that one.,,, Debugging TypeScript 3 Didn’t Complete An issue you are going to run into is when you examine the “this” pointer after returning from executing an asynchronous function.,,, I understand why this is, but you can get a proper reference to your components’, this pointer if you use Chrome’s Developer Tools.,,, The workaround is to use this “_this” instead. Ha… play on words.,,, Even though IE starts a lot slower than Chrome, there are a few tricks you can play using IE, and here is one.,,, Once I hit this breakpoint, I can use F10 to step over, then I can drag and drop the current execution point back to line 59 to run that line of code again.,,, Debugging TypeScript 4 Didn’t Complete Using Visual Studio’s integrated TypeScript debugging, has some advantages, however, I would still recommend using Chrome’s Developer Tools for debugging. Now since we can reload our application automatically after changing a file, it really is the most productive way to develop a Web application.,,, The only issue is that Chrome’s Developer Tools is not integrated with Visual Studio, which means that you need to do your debugging in Chrome and your editing in Visual Studio. Oh well… Now, let me show you how to launch Chrome, more quickly for development. Opening Developer Tools Automatically It took me a while before I learned how to clear the cache, and open Chrome’s developer tools automatically, when starting to debug from within Visual Studio. This has the advantage of capturing the performance data from the beginning point of launching the application. Let me show you how to do this.,,, First, within the Tools Options, disable JavaScript debugging for ASP.Net.,,,,,, Next, click on the “Browse With…” selection.",,,,,, Then, select Google Chrome, because we are going to copy the program path.,,,,,, Highlight it and copy it to the clipboard by hitting a control-c.,,,,,, Now, click the “Add” button.,,,,,, Next, paste the program path into the program text box. Type this into the “Arguments” text box:,,,,,, --auto-open-devtools-for-tabs --disk-cache-dir=null Then for the Friendly name, enter “Chrome for Development”.,,,,,, Now if you choose “Chrome for Development” as your browser, then hit F5 you will launch Chrome with the Developer’s tools and clear the cache all at the same time. Another huge productivity gain. Another quick point. You may also want to select “Disable Cache” on the Network tab. Software Switches Software switches can expedite the development process. For one thing, they can determine if you are in Debug or Release mode. Maybe you want to run slightly different code if you are in Debug mode, or log errors. But how can I prevent my test code from running when I deploy my application to a production server? Here’s how! First, notice on the “Settings” feature that we are currently in the Debug mode. Also, while we are here, allow me to show you how I can detect whether or not I am in Debug mode. Notice what happens when I change to the Release mode.,,,,,, Then launch the app.,,,,,, And finally go to the “Settings”.,,,,,, Now your client-side code can detect whether you are in Debug or Release mode. Performance Markers 1 Performance markers are a great way to gather timing information, and Microsoft Edge allows you to view this information for analysis. The JavaScript Performance interface has been a part of JavaScript for quite some time. However, very few actually know how to use this interface. Allow me to demonstrate using Microsoft Edge. The latest Microsoft browser comes with a host of new features not available on other Microsoft browsers. The one that I use frequently for performance analytics is the Performance tab in Edge Developer Tools. Entering into this tab allows you to gather specific timing information. It reminds me of the data scopes, and logic analyzers that I used in my younger years. Here you start a recording, do something, then stop the recording for analysis. Please allow me to demonstrate.,,, First, take a look at how I added performance markers that will later be used for analysis.,,,,,, Notice the “BEGIN REQUEST” performance marker, then the “REQUEST ENDED” performance marker. Performance Markers 2 Once the application is loaded, open Developer Tools, and then open the Performance tab.,,,,,, When you are ready to record the application’s performance, click the “Start profiling session”, or Control E. This will start recording your session for analysis. Once the recording starts, click the “Restart” button to reload the application. As soon as the application is loaded, you can click the “Stop profiling session”, or Control E.,,,,,, Now you should see the events on a timeline. To locate the performance markers that we embedded into our code, look for the down arrows. Performance Markers 3 First, notice the “BEGIN REQUEST” performance marker, then the “REQUEST ENDED” performance marker.,,,,,, Now, let’s go even further to see how long it took to make that request to the server. Easy enough just to take these 2 handles and frame these 2 events.,,,,,, Then over here, look at this donut. Yum, donut… The selection duration indicates how long it took.,,, From beginning the request to the server, until receiving a response from the server, took about a third of a second.,,, Microsoft edge is a great tool for gathering timing and performance information. Starting without Building You get to the point where you realize that your current development is all client-side. You can use this technique to start the application much quicker. However this one can trip you up if you forget you have altered your configuration.,,,,,, Ah, I’ll show you anyway, then you decide.,,, Stop any debugging that you may have in session, then right-mouse on the solution and choose the “Configuration Manager”. Here you can disable the projects from building. Once you have done that, your application will launch much quicker because it is avoiding the build process. Just remember to turn it back on, or do a right-mouse on the solution, and choose build. Concurrent Debugging If you want to be really productive, you can debug several projects at the same time. As an example, maybe one of your projects is relying on another project. Here is how to start a debug session with 2 concurrent projects. First stop your current debug session, select the solution and do a “right mouse”.,,,,,, Then click “Set Startup Projects”.,,,,,, Next, click on the radio button for “Multiple startup projects”.,,,,,, This will allow you to choose what each project does when you start the project.,,,,,, Choose from both dropdowns, “Start”.,,,,,, This will start both applications debugging concurrently.,,,,,, Would you like to see a demo of concurrent debugging? Well of course you would! Concurrent Debugging Demo 1 Before we start debugging, let’s set the first breakpoint that we will hit during this demo. Let’s set a breakpoint on line 46 of the tasklist.js file in the DebugGulpFile project.,,,,,, Let’s also set a breakpoint in the WebAPI controller file SyncController.cs on line 35.,,,,,, Concurrent Debugging Demo 2 Let’s start the debug session, and make sure that the Node console app and the Angular.Net Starter App launches.,,,,,, Yep! Both projects are loaded. Also, make sure to select the DebugGulpFile from the dropdown in the Task Runner Explorer.,,,,,, Now, I’m going to execute the reloadApplication task, by double clicking on the name in the Task Runner Explorer.,,,,,, You should see that we have hit our first breakpoint which is in the DebugGulpfile project.,,,,,, Now when I hit F5 to continue, I should hit my other breakpoint, which is in the AngularStarter project. A completely different project.,,,,,, Now when I hit F5, I should see the Angular.Net Starter Application reload.,,,,,, I hope you understand the benefits of being able to debug several projects at the same time.,,,,,, Course Conclusion We have just concluded this course titled “Angular and ASP.Net Core”. I know we went kind of fast through these topics. And, maybe you are used to a slower, more thorough approach to learning. With the information provided in this course, you should be able to pick it up from here. If you are just beginning to learn Angular, I suggest Deborah Kurata’s PluralSight course titled “Angular 2: Getting Started”. As a Microsoft developer, you already know the advantages of choosing ASP.Net Core for the back-end, but now you should know how to integrate with Angular, the most powerful front-end technology to create rich, robust, web applications. By using these 2 powerful frameworks, and by using the productivity tips and tricks demonstrated in this course, your projects will be months ahead of schedule, with applications that are built for the future, and run on multiple platforms. If you are looking for a consultant to help you integrate Angular with ASP.Net Core, I would like to invite you to contact me at this address. Thanks for watching!