 Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green. Joining me today is Ed Sharbano. Thanks for having me. Thanks for coming on. Ed's going to show us a couple ways that you can using ASP.NET Core from inside Visual Studio of course, take advantage of Angular. So the marrying of Angular and ASP.NET Core. Right. So when you think of JavaScript frameworks, the first thing that might not come to mind is Visual Studio, right? We're not used to developing JavaScript applications in Visual Studio. We're used to C-Sharp and F-Sharp and XAML applications. But the JavaScript frameworks that are out today like Angular are very popular and they work really well with a.NET back-end. Cool. So we're going to look at three scenarios. First, we're going to look at how to create an Angular application in Visual Studio using the new templates that the Visual Studio or the.NET team is releasing with ASP.NET Core 2.0. Then we're going to look at how you would create an Angular application using a web API back-end with an Angular front-end without that templating. Okay. Then we'll look at how to use the template with an open-source framework called NativeScript. So we'll use the template to build an Angular web application and then we'll use Angular to build a native iOS and Android application. Cool. Using JavaScript code that we're sharing between the native application and the web application. So these three interesting scenarios, and they're all just a little bit different. Right. They fit different development types or different team types. Depending on how friendly your team is with front-end development, you may want to choose one scenario over the other. All right. Cool. So let's look at the first way to do this. I've already generated the project, but I want to walk through the steps of how it's done. I won't do it live here because it takes quite a while to pull in all those dependencies. But what we do is go to File, New Project. When we do File, New Project in the latest bits of Visual Studio. Now, by latest, do you mean? I am on Visual Studio Preview for ASP.NET Core 2.0. Okay. So by the time people watch this, it will have released. So you'll be using Visual Studio 2017 15.3 and ASP.NET Core 2.0, right? Yes. Okay. This tooling should be available and when you go to ASP.NET Core web application and click Okay. Normally, we see web API and web application. This would get our MVC application going. Now we have these JavaScript applications in here. So we have Angular, React. In this case, we choose Angular. Okay. This is going to spin up a brand new project for us that is an all-in-one application. So we're essentially removing the view from MVC and replacing that view with Angular. Okay. So we still have models and still have controllers. We still have models, we still have controllers. And you'll see just a little bit of view in there. And that's just to bootstrap up the application. We're not going to be writing any razor. So if you're a big fan of razor, like I said, depends on what your team is like. If you're a big fan of razor, it's probably isn't the approach that you want to go. Okay. Angular is probably not the approach you want to go. So with that said, we'd go ahead and click OK. This would pull all of our dependencies in. We don't want to do that for a live audience here. But what we'll do is show a project that I already have created. So we'll go ahead and open this project up. And you can see here, let me collapse this down. We'll start from the beginning. We open this up and you'll see controllers and views in here. We don't have any models yet because we haven't gone to any databases or anything in this template. But you would normally see models in here if you're connecting to a data on a back end. So we have our controllers and our views. If we go into our views, I'm just going to go into the shared layout here. And we'll notice there's just a little bit of code in here and stuff that we're used to like render body. And if we go into the index, this is just the bootstrapper for Angular. So we're not going to write any views into this folder at all with this approach. We could potentially use some views if we had things that weren't going to apply Angular. But for the sake of the conversation, we're talking about Angular development. So let's close this up and look where the actual client side of the application lives. Since we're at this point, you've brought down a whole bunch of Angular code, JavaScript code, and it's got to be sitting somewhere, right? Right, absolutely. So if we go into our client app, here's where you'll find all of the TypeScript for the application. Now it's important that I said TypeScript because Angular is actually built on TypeScript. And we have to compile that TypeScript down to JavaScript and then use it that way. So I'll get to that more in a moment, but let's look at some of the files that we have in here. The main one I want to dig into here is the app folder and then the components. When we spin up this application, this is the views that you're going to see in the application. So mainly we'll look at fetch data here in this counter component. So let's give this guy a run. And then we'll kind of go back and forth between the running application and look at the code. So Visual Studio now is booting up the server and loading the application in. And there's a lot of magic going in behind the scenes. So we'll talk about that in a second. But when this application loads up, we'll have a counter view where we can press a button in increment a counter and then we'll have a fetch data component where we can fetch some weather. Okay, so here's the application. All right, this is out of the box what you get with the template. I haven't modified it in any way. First we have this incremental counter. We can click on a button and just increments a counter for us. Very simple. That's just as exciting the hundredth of times it was the first. What we're demonstrating here though is the model binding in Angular. And the ability to click on a button and not have a full page refresh just to increment a piece of user interface. And then we have our weather forecast. This is actually going back to a web API endpoint. Wow, I don't live there. 76, 24, 37, 7, 84, holy cow. 76 is sweltering for some reason. And 7 is chilly. But it's going to be from like the Arctic or something. So we're generating some random data in a web API controller and passing Jason back to Angular and then Angular populates the view for us. So this is again all being done as a single page style application. So let's go look at the code that's running this view. First let's look at the counter component. So again, this is TypeScript. It's written in Angular so you'll see a lot of Angular syntax around this component, and it's just as simple as it looks. So TypeScript written in Angular. TypeScript and we're writing Angular specific syntax. Okay. So you'll see the component directive, the component directive is wiring up the tag that is going to be output from this component, the HTML tag. And then it's specifying the view or the HTML template. You also see things in here like CSS and you'll see dependency injection and things like that being introduced here as well. So a lot of Angular workflows you'll see in here. But for the most part this is TypeScript and all we're doing is incrementing this value and this value updates this field. And then the field is bound to the HTML. So if we look at this current count right here, this binds to our backing field that is right here being exposed. So it's very, very simple stuff. But let's actually take a look at something that's going on here. So if we increment this counter, you see it goes up and our application is running. It's already, the TypeScript's already been compiled and the application is being served. If we go back here and we change this to decrement instead of increment and I save that and we'll give this a second cuz what it's actually gonna do is it's gonna compile that behind the scenes and then re-update this view with the new code and you'll see the counters actually reset. That's because our counter component initializes at zero. So when it sent the JavaScript back to the web page and it updated the code base, it reset that counter to zero. But now when I hit increment, it's gone down. I didn't have to recompile, I didn't have to refresh the page. So what's happening? And what is that a function of? Is that a ASB core thing? Is that an Angular thing? Is that a Visual Studio 2017 thing? So Steve Sanderson, part of the.NET team, he's built what is called JavaScript services, which a subset of that is something called node services. With node services, we can actually run from within Visual Studio, within C-sharp code, a JavaScript library that's running in node. So we can call out to Node.js and call a function in JavaScript and get the return values from JavaScript in our C-sharp code. And then we can utilize that. So we can do things like kick off Webpack, which is a bundling minification compiler like JavaScript tool. So that's exactly what it's doing. When I save that file, there's a watch in the background that picks up the save. It recompiles that JavaScript and Node.js is actually running in the background and it's recreating that view using the Angular server side rendering and everything, sending that back to the view. Okay, so is that a Visual Studio feature? Or is it a feature, if we were doing this in Visual Studio code, could we get the same behavior? Yes, okay. So this is a feature of the code that's running on the server. Okay. So this is a piece of middleware that's running as a service and it's called node services. And that's the ability to talk to Node.js from within our code. Okay. So we have the best of both worlds. I thought we were doing Angular. Are we using Node? So Angular uses Node.js. Got it, okay. To create server side rendering. So we're used to doing server side rendering at .NET through Razr. And the HTML is built up on the server and sent down to the client. With Angular, the same thing is happening with JavaScript and HTML and Angular components. But when it's happening on the server, it's happening in Node.js. Okay, cool. Got it. So with that piece of middleware we're able to talk to a Node.js instance without having to serve directly to the client through Node.js. So we can still serve through our application, all right? So that's the magic that's happening under the hood there. I can actually demo that in a minute. But let's walk through the rest of this template first. So we have the counter component and you saw how I can update that code in real time. And if we go back and look at our application here with the type script for the fetch data component, this is going out to our API. And it's calling API, sample data, weather forecast. So this endpoint actually exists in the same project in our controller. So if we go to controller and look at sample data, this is where that fun weather data that you're having some fun with. This is where that's generated. Got it. So if we look at our API route here, we have our API slash controller. So it grabs the controller name, which is sample data controller. Wax the controller name off the end so we get sample data. And then our action is weather forecast. So that's where you see that API on the fetch data component. So this is actually going out to a C sharp back end web API call. Jason is returned from it and then Angular parses that and repopulates the web page with the appropriate HTML and data that's being bound. So this JavaScript services component that I was talking about. This is really cool stuff that's been built. And I'll just demo this really quick because it's such a neat piece of software. This project that I've just pulled up here, this is just a bare bones web app. There's nothing going on here except we're spinning it up. So you'll see we have a simple service layer being spun up. And then I'm making a call to get this node services package here. So I've got our service being registered as add node services. That's a service I talked about that goes out to Node.js and runs modules and can get back the code. And you'll see I'm invoking a JavaScript method here with node services dot invoke. And then it's going to return a string. And it's going to return other things like an integer and so on. And then the name of the script is just going to be greeter. I don't have to tack on the JS. It knows that it's understood that that's what it's going to be. And if you look in the root of the application, I have a greeter.js file. So let's open this guy up. So this is just using module syntax and it's saying we have a function and it's going to take a parameter of a callback and a parameter of a name. And we're going to just concatenate something onto hello from node. And then our callback will be received in our C sharp code here. And we can use that. And we're just going to write that out to the web application. So when I run this, you can see I'm calling invoke async greeter with visual studio toolbox as the parameter. When the application spins up, we should get hello from node visual studio toolbox. So we actually ran node.js code from within our C sharp application. This is very cool stuff. And that's how that template works is it's got that built in behind the scenes. Very nice, very nice. So this is actually a really good starting point for most people. The knowledge of web and C sharp seems to be very interesting. Does it kind of lead into the WebAssembly conversation? They're related. WebAssembly is kind of different. WebAssembly we're talking about running the app, compiling the code onto something that the browser can understand directly on the browser. This is kind of more magic. We're running node.js in the background. Node already understands JavaScript and we're just calling out to that and getting the results back from it. So it's a little bit different and it's actually running, that instance is running on the server, not on a browser anymore. So we're actually running server side JavaScript code through C sharp. So this template that I showed you to be in with, it's a very good starting point for most people. You don't have to know all of the bits and pieces that are working behind the scenes. You can learn those gradually as you need to add more functionality to the application. So where I work, I'm a developer advocate for progress. We make the Telerik UI components. We are keeping very close eye on this because it lets our customers get up to speed on using our UI tools much more quickly. We have a brand new package called Kendo UI for Angular. So we have charts and graphs and grids and all those rich UI controls that are built for Angular applications. So in .NET 2.0, .NET Core 2.0, there's a new templating system. So we can easily generate templates based on existing projects. So what we're doing is we're going to piggyback off of the template that already exists here. And we have a similar startup experience. So this is something that we're working on. It's not quite released yet. And we hope to offer this pretty soon, waiting for those final bits of .NET to be released. There's still some things with the templating system that are being worked out before the release. So we're watching that very closely. But the startup experience here will be almost identical except the components that are generated in the application will be our UI components. And we have rich charting UIs that are friendly at any resolutions. You can pull them up on a mobile phone and you can have that responsive behavior on your devices without any additional coding and stuff like that. So this is the project template that we're working on. And you see very familiar, we have a counter component. We have our themed button in here. We have our fetch data component. And this is using our Kendo UI grid. And then we've added additional components in here like a chart. And we're still loading some things here in the background. So there we go. Nice, beautiful chart there. We can hover over the different data points. And then we even have additional drop-down components where we can create tag-like interfaces and things like that. So that's what we're taking. The new templating system in .NET Core is really cool. Essentially, you can just target a piece of code, package it up with NuGet, and then you can go to the command line and run .NET new. In our case, it would be like Angular-NG. You get a whole new Angular application with our stuff built in. Nice. So that was scenario one. So we've got an all-in-one package, one server that's doing everything, serving the views from both Angular client-side rendering and Visual Studio, or sorry, and ASP.NET. It's doing that little bootstrapping piece of razor markup that gives us the introduction into Angular on the client-side. Next, we're going to look at the scenario of what if we don't use a template. So there's a lot of people that like using the Angular command line tools. So we can actually use the Angular command line tools to generate the front-side of the application. Then that changes how our back-side of the application works. And we're actually going to need two server instances to deliver all of the content to the client. One piece of it will deliver the UI, and then the UI will talk to a Web API server on the back end. So again, to keep this brief, we'll just kind of walk through the steps of spinning this up. Let me stop this previous demo from rolling, and we'll get into the final new project again. So we'll do a final new project Web API, and then once we've created that application, we'll do Angular command line, NG init, and start up a new application in the command line, and then we just pull those projects together. And our debugging process is misbehaving. So it's giving us a little struggle shutting down here, but we'll spin this guy up here shortly. Okay, here we go. File, new project, ASP.NET Core Web Application, and then instead of choosing Angular, this time we would choose Web API. Okay. So that gives us our back end. Once we hit OK, we'd generate that back end, and we'd go into our application. And we would go into the command line, we would do a new Angular project, and then we'd add that project, and I've put up the wrong one here. Let's go back to this guy and do our back end for Angular project. Loading all the dependencies in on these is pretty lengthy over Wi-Fi even. So it's easier just to show you projects that have set up already. So the file new Web API would be this project here. This is our Web API controller. We have controllers, and I've recreated that sample data controller. Okay. So this is our fun weather service again. And then to add the client app, the Angular client app into Visual Studio here, we would just right-click into Add Existing Website. So... Because you created it in the command line first. Yes, you create that in the command line using the NG init, or NG, I think it's NG init. If I remember correctly, to generate that template for an Angular application. Once we do that, we can do Add Existing Website, and because it's all web code, Visual Studio understands that perfectly. So there's no additional steps to configure anything once it's in Visual Studio. And again, I've rebuilt the same type of application. Now, when I say rebuilt, I've modified this because the initial Angular application is very bare bones. You get almost nothing. So remember that first experience, you get at least some template code to click a button and see how things bind together and call a web service. With this approach, you get nothing. You're starting from scratch. Now, some people like that, that's fine. It gives you the opportunity to make choices and build what you need to build and not have to take anything out that's been added previously for you. So there's pros and cons to each approach. If we run this application, the experience of running it's going to be slightly different. So we don't have that all-in-one approach. When we run the application from Visual Studio, we're running a web API application. So notice we get just data dumped to the screen. So this is just JSON data. Now, to run the Angular portion, the client side of the application, we need to call on the command line. Now, I'm not going to step out of the command line. I like to be in Visual Studio. It's a preference of mine. You could use this in tandem with the command line if that's how you choose to operate it. Instead, I've installed a plugin for Visual Studio called NPM Task Runner. Now, in the latest versions of Visual Studio, we have a Task Runner Explorer. And Task Runner Explorer basically takes anything that is in this project.json file in a node application or package.json file. Any of these scripts that you see here in the package.json file, you'll notice are in the Task Runner Explorer window. So to start my web client experience, I can just double-click right here. So normally I'd go out to the command line, and you can see it actually running it in here. ng serve, and then I'll explain this proxy config here in just a second. So it's something I've had to modify to make it work with the web API back in. So let's go into the browser, and it's on local host 4,200. Now, let me hit this 5,000 here real quick again. So when we spun up our ASP.NET web API, we had api backslash. Let's see here. Let me actually restart this. It'll pull it back up. Then we can come into it from this way. So when we started up our web API project, we're hitting that raw endpoint. There it is. Local host 5,000. And then our api endpoint. It's important to note that because our client app is running on a different port. So when we spun up the client app in the console here, it says go to the browser on local host 4,200. So if I go to local host 4,200, I've got hello world, and I can click on fetch data. Notice not beautiful like the last app. Again, I had to start from scratch, so I just did the bare minimum to get this going. Now, like I said, local host 4,200, the code is going to be looking for an api on local host 4,200. Our api is actually on 5,000. So what we have to do in this situation is we have to create a file called proxy config. So this is port forwarding for Angular. So it's telling the Angular application, our api is actually on a different port. So when you see this slash api path come through, we're going to forward that request over to local host 5,000. That ties the two together for our development experience. So it's a little more ceremony here to get started. But there's teams that work separately building the api infrastructure, and then you have your front-end developers that are building Angular. They might use Visual Studio Code, they might use Vim, some other thing, but this lets you have that scenario where you can work with both. So just different approaches for different teams with different skill sets so far. The next thing I want to show is an application that's actually sharing some code with a native application. So we're still using Angular, but we're building a native application. There's no web views, there's no magic. We're taking an Angular application with TypeScript, and it's compiling down to JavaScript. That's being translated to native api calls on the devices. We're using an open source framework called native script for that. So let's take a look at how that operates. Again, I'm going to use all Visual Studio tools. Native script? Native script is by progress, the company that I work for. So again, we're in Visual Studio, and to get this project up and running, I would do a file new project, and then click on the Angular template that we originally looked at. So that gives us our all-in-one Angular application with our counter and our fetch data component. I've modified it slightly. You'll also notice another solution in here called native application. Now they're all web technologies that are being used to create these native Android and iOS applications. Since they're all web-based pieces of code, we can come in and do file add existing website, even though it's a native application. So the native application is done in what? It's Angular, TypeScript, CSS, and XML. Okay, that's the native application. Yes. Okay. So they're all web-based pieces of technology. Okay. So we can do file add existing website, and it works just fine in Visual Studio. Got it. Okay. So in this scenario, I've got, again, this application, I'll run it, and we have our counter component and our fetch data component. And all of that code is very similar to what we saw initially, except for one thing. The ability to run Angular on a native application means I can share some code between the two applications. They're both using Angular. They're both using TypeScript. So I can come in to my application and open up this client app. And I still have my same folders as before. I have components, fetch data, and counter. If I open up my counter, there's actually not a lot of code in here. So if I look at this, I have exports class counter component extends counter component base. So what I'm doing here is I'm using inheritance. So I'm inheriting from counter component base, and that's coming from my shared library counter component base. So in this project, I have a counter component base class. And that has my ability to increment this counter variable. And if I look in my native application under app shared libraries, you'll notice I have the counter component base in there as well. And it's the exact same code as the Angular web application. Now, for this simple demo, I'm just using a copy script. So it's an x copy. It just goes out to my web application, copies the shared library over to my native application. So I can use it there. In a more advanced scenario, I could use NPM packages or advanced CI CD pipelines or whatever to share code that way. But just to keep things simple, I just have a script that I run. And again, I'm using the NPM task runner for that. So if you look down here, I have this shared Libs script. If I double click on that, it just pulls that new code from my web application to my native app. So this application should be running. You can see that I'm pulling it up on this IP address here. The reason I'm pulling it up on an IP address and not local host. So the native part of the application needs to talk to the back end. If I'm on an emulator or another device, it doesn't know what local host is. So I need to have an IP address and some firewall ports need to be open. Now I can go into my counter component. You can see I can count like I could before. And then also fetch data works the same way. However, the fetch data code has been abstracted a little bit. So if I look at my fetch data component, instead of just going directly out to the web and hitting that endpoint, I'm using a service. And I can share that service between both the native and the web application. So in my shared code, if I go into shared, you'll see I have a weather forecast interface that's shared between both apps and I have my weather service that's shared between both apps. So this is the same code both apps on the right at once. So now another handy Visual Studio tool is I can come in to tools and I can add this Visual Studio emulator for Android. This is something that you have to add on. It's a free component to Visual Studio and it works very well with this. So I have my devices here and I've already spun up an emulator. The next thing I want to do is run my new native app that I built. So again, use my NPM task runner and I'm going to click on Live Sync. Live Sync is going to call TNS run Android. That's the command line operator to kick off the build process for my native application and it's going to load it on to the emulator. And then it's going to create what's called a Live Sync connection with the device. You remember that experience I had on the web where I can update the increment counter and decrement instead? I can do the same thing with a native application. I can update that code. It'll recompile from a native script and it will send that new compiled code up to the device and swap that out for me. So I don't have to recompile manually and go through that process. And there's my native application and I have my counter component and I have my fetch data component. Now the parts that I can't share between the two pieces, native script runs XML, not HTML. So the actual view code, the view markup can't be shared. There's some similarities. We're using angular directives. So if you're writing angular, some of the things like creating templates and looping over objects is the same in the view code. But it is XML markup. It is nothing like HTML. Right. And then if you need some code that is custom to iOS and Android, that's possible as well. So if I wanted to have a view for iOS, I could name that view whatever the view is.ios.xml and it would compile only for iOS. So I can target specifically if I want to. Otherwise it's shared between the two operating systems. And those are native views as well. So when we write an XML component, let's pull one up. The extension I'm using is HTML because it's more friendly with Visual Studio and Visual Studio Code. Otherwise you get a lot of red squiggly underlines if you just try XML. It looks for namespaces and things and it gets kind of crazy. But you'll see I have a label. It's not like an HTML label, but it's a label. When I write label in this XML format, it maps to the native label control that's on iOS and the native label control on Android. So it's pulling up native view code on those devices. So there's no web view being run in the browser module or anything like that. It's not Apache Cordova. This is actual native development. Got it. So that's another scenario where you can reuse web skills. If you have a strong web team, they have limited native experience. This is a way to get started building a native application using Angular in Visual Studio with a C-Sharp web API backend. Very nice. Cool. Cool stuff. Thank you. All right. It's a lot to take in, but it's a new way. So it's a couple pointers as to where people can go to learn more about this. We'll put some stuff in the show notes, but if they're new to Angular or new to native, new to matching, to mixing and matching native with web. So if you want to learn more about native script, go to nativescript.org. If you want to learn more about the template that I showed you and how to integrate that with our UI controls, go to blogs at teller.com. Search for cooking with Angular. That's an easy one to remember. Just put that in Google or Bing and do cooking for Angular. You should find an article that I wrote all about the template and how to add components to it. It should get you familiar with the processes that are involved there. All right. Cool. Thanks for coming on. Absolutely. Thanks for having me. All right. Hope you enjoyed that. And we will see you next time on Visual Studio Toolbox.