Build triple A games with C++ in Visual Studio 2022

[MUSIC] >> Hi, folks. My name is David Li. I am the C++ Game Dev PM at Visual Studio. I'm here to talk to you about some new and exciting changes in Visual Studio 2022. Recently, our CEO, Satya Nadella, has said, as a company, Microsoft's all-in on gaming. At Visual Studio, we're all-in on gaming too. We have been creating new and exciting experiences for Visual Studio based on your feedback. Whether your Unreal developer, an indie game developer, whether you make your game on our proprietary engine or work on AAA game studio, let me show you why VS 2022 is the IDE for you. First, let me get started with the demo on Hot Reload. Now for game developers, this might sound familiar to you. Have you ever spend 30 minutes playing your game just to get to a specific state? Spend all those minutes and hours getting to that state just to find out your bug fix didn't work? Or if you're a technical artist. If you repeatedly have to restart a game just to see your [inaudible] iterations, Hot Reload is a feature for you. Let me show you how Hot Reload works. Imagine you're building an open source, cross-platform [inaudible] project like Bitfighter here. In Bitfighter, you have a ship that has a red round shield. You can activate the shield with a press of a button. Now what if you want to make the shield a little bit more exciting? Let's do that in Visual Studio. Here, instead of the color red, I'm going to make it cyan, and instead of a circle, I'm going to draw a star. Normally, without Hot Reload, you will have to close down the game, rebuild it, and click through the menus just to get to the same state. With Hot Reload, all you have to do is to press the "Hot Reload" button. It takes a few seconds for Hot Reload to run. Let's see here, a giant 10-point blue star. Isn't that crazy? Oh, okay. Maybe that's a little bit too exciting. Let's change it back to something a little bit more reasonable. Instead of the star, I'm going to go back to the circle. But this time, instead of red, I'm going to change the color to gold. Instead of pressing the "Hot Reload" button, you can also activate Hot Reload on File Save. To enable that, go to the dropdown next to the Hot Reload button. Click "Hot Reload on File Save". Once that is enabled, every time you save the game through Ctrl +S or the Save button, the change are automatically applied. Here, a gold round shield. Hot Reload supports any changes that are currently supported by Edit and Continue, and is not limited to only game developers. With Hot Reload, you no longer have to close your application, recompile it, get the application back to the same state, only to find out your fix doesn't work. Instead of spending minutes and hours getting to the same state when debugging, take those precious minutes back with Hot Reload for C++. Next, let me show you a demo with Intellicode for Unreal Engine. We build Intellicode for Unreal Engine by parsing many Unreal Engine databases and making an AI model. When enabled, Intellicode for Unreal Engine shows up in Unreal projects. For established developers, Intellicode saves time by suggesting the most common suggestions and sorting them to the top of the member list. For new developers, Intellicode suggests the right APIs in the right place. For Teams, you can train custom team models over your codebase, which makes the effects of Intellicode even more powerful, but providing suggestions on internal types as well as more specified suggestions based on your Team's coding patterns. This also makes it easier to onboard new developers as it help suggest things the Team is using elsewhere. Here, let me demonstrate how Intellicode works with member access. When you press a "Dot", Intellicode suggestions will show up with a star. The star denotes that this suggestion is from Intellicode. Similar down here, when you press the "Dot" operator, you'll get another Intellicode base suggestion. Down below, the Arrow operator also brings up a list of Intellicode suggested suggestions denoted by the stars. In this case, the top suggestion is GetController. With Intellicode for Unreal Engine, power up your experience of developing Unreal Engine games in Visual Studio. We have been working closely with Epic Games to make a great experience of developing Unreal Engine games in Visual Studio. Haven't tried the Unreal Engine? You can check it out under the game development with C++ workload in the Visual Studio Installer. One of the things that we have been working with Epic Games is increasing the responsiveness of IntelliSense. IntelliSense for UE projects is now significantly more responsive due to utilizing PCH when generating VS project files. Look for this new updates in a new version of Unreal Engine 4.27 coming soon. Similarly, Intellicode for Unreal Engine 5 is coming in an upcoming release. What do you want as an Unreal Engine developer in Visual Studio? We want to know. Connect with us on Twitter, and leave us your feedback. Aside from making Unreal Engine IntelliSense improvements, we have also been making core performance in C++ IntelliSense improvements in Visual Studio 2022. We have made a test based on Unreal Engine 4.27, a large project, and benchmarked it with VS2019 against the VS2022. The timings we're taking when VS opens a project for the first time and subsequent times average over three runs. Visual Studio 2022 feels faster when getting to code. You can get to code quicker in Visual Studio 2022 and open the file twice as fast. You can also wait less time for IntelliSense ready. Get the syntactic highlighting and code changes to appear in member list twice as fast. With the new improved IntelliSense performance in Visual Studio 2022, you can save seconds each time you open a file. We hear pain about IntelliSense performance with game developers. Now these are only few seconds each action. But imagine, how many times are you opening a file every day? How many times are you waiting for IntelliSense to open every time you open a new file? These are only a few seconds but add up over time. Especially for bigger projects, this will scale. These are small numbers, but they add up. We want more feedback because we aren't done making improvements. Install Visual Studio 2022 side-by-side with VS2019. We want to make it easy. VS2022 is binary compatible with previous C++ two sets in 2019 or older. If you are coming from VS2019, you may be familiar with our built throughput improvements. Let me briefly tell you what you'll gain from upgrading to the latest tools. Using the latest tools, the Gears 5 team at The Coalition saw a 2.6. seven times faster end-to-end build time and 2.8 faster link time compared to VS2017. Similarly, at Turn 10 Studios, they saw a five times improvement and link times for Forza Motorsports. For Forza Horizon 4, the link times are now 18 times faster than in Visual Studio 2017. The decrease in build time enabled Playground Games to switch from /DEBUG:FASTLINK to /DEBUG:FULL. You can enjoy all the benefits of the latest toolsets by upgrading VS2022. When you load your projects, you'll be prompted to upgrade, but you don't have to. You can still use the old compilers and the older toolsets and they will still work. You can enjoy the IDE experience of Visual Studio 2022 that way. Third-party libraries that will also work. Don't have a package manager? Try vcpkg. Download Visual Studio 2022 today, and try out all the new and exciting features we have in store for you.

Build and deploy Node.js and React apps with Visual Studio Code, Azure App Service and Cosmos DB

>> Hi I'm Matt. I'm a program manager on the Azure tools for Visual Studio Code Team and I'd like to welcome you to Microsoft Connect. I'd like to show you some stuff today that my team has been working on to help you be more productive, building your apps locally, and then extend that productivity to the cloud as you deploy your apps and adopt Azure App Service in Cosmos DB. We'll start with this app here which is an Express app built with React and uses a Mongo database on the backend. I'll start this app in debugging mode just to give you an idea of what it looks like. You can see it's a sticker app with no stickers. This will let customers come and browse and order stickers and customize them, but again, there's no data. So let's populate our database with some data. So the first thing that I want to show you is the Cosmos DB extension that I'll actually let you work with your database is locally as well as on Azure. In this case I'm connected to a Mongo database that's running locally on my machine and this app is configured to use a stickers database on localhost. So let's go ahead and create the database that we need and the collection which is just called stickers. There we go now we have a database and a collection with no data. So, I have some initial data that we can use. I'll copy this entire array of sticker objects, and I'll open up what's called a scrapbook. So this is a fairly unique concept to the Cosmos extension. What a scrap book because is, is a way to write your Mongo queries and get IntelliSense for the database that you're actively connected to. I'm already connected to the stickers database, but to do that what you would do is click on the "Connect" button. Choose my attached accounts, my local database, and the database we just connected to or we just created. Again, you will get some intelliSense on here so when I type Db, you'll see the stickers collection is automatically recognized as available and we're going to do an insert mini. I'll paste the array of sticker objects I just took from my initial data and we'll execute this command. As you can see, 15 stickers were added, we can expand the collection and actually see those collections or those documents within the collection, and I can actually click on these documents and make changes to them directly in the editor. Saving will upload the changes to database. But for now let's just go back to our app and make sure that the data works. Okay. Cool. So this is what it's supposed to look like and it's working on our local machine and let's go ahead and deploy that to Azure. To do that I'm going to use the Azure App Service extension which is our platform as a service offering that lets you deploy your applications and scale them as the demand arises. This all starts with the blue up arrow which is the deploy button. I'll create a new app, let's give it a name and I'll pick my node version. So what this is going to do it's going to call out to the Azure APIs to create an App Service plan which is basically a VM where the app instance will run. You can have multiple app instances running on an App Service plan. It will also create a resource group which is a logical grouping of Azure resources that you can use to manage various pieces, and it will create the app instance itself where the app will be deployed. Now that the app is created, I'm prompted to choose the directory that I want to deploy it to the app instance. We'll skip this part for now but if you wanted to you can actually let the App Service extension remember which app was deployed to this particular app instance so that in the future you aren't prompted for which app you want to deploy to. So at this point it's going to package up the app. Since we're in the default configuration it's just going to use a zip archive It's gonna take all of your code. Put it in the zip archive push it over to the Azure API where Azure is going to take over extract all of the code, run NPM install in the root of the project, and then start the application. So now that our app has been deployed we get notification letting us know that we can connect to the log stream or we can just go ahead and browse to the site. So let's do that and get an idea of how it's working. Again, we have the same problem with no data, but in this case I've actually created a database out on Cosmos that we can connect to. To do that, let's go into the App Service extension here expand the node for the app and choose connections. This will let us connect to a MongoDB instance that's running on Cosmos or in Azure. Choose connect or pick from my subscription. Again, I've already created a database for this, and it's going to automatically create the environment variable that we need on Azure to connect to the database. I'll use the default value of Mongo URL because that's what this app is looking for. Now that it's connected we can actually reveal this database in the Explorer which will take us directly to the Cosmos extension. We can expand this and the same functionality that we had on the local environment we have again here in the production environment on Azure. So, I can do something like make a change here. When I click "Save" prompt it to upload and refresh the page and take a second for our environment to be reset to use the correct environment variable. Now our stickers are loading. You saw that I made a quick edit to the markdown sticker and that did show up right here in the production version running on Azure. Okay. So now we have our app running it's connected to the database but deploying from the editor's a little strange. So what we're going to do is we're going to set this up to automatically deploy from our GitHub repository and we'll do that from the deployments node. I'm prompted automatically to connect to a GitHub repository. I'll click that, choose my username, pick my sticker app project and we'll choose the master branch. So what this will do is set up all the hooks out on GitHub to automatically pick up pushes to the master branch. This also includes things like pull requests that are merged into master, and then anytime that happens the code will automatically be synchronized over to Azure and it'll be running just automatically as we develop our app. This step takes a little bit of time because it is actually setting up the hooks and that it's going to do a sync or deploy, and get all of your all of your assets out on the worker and running. Okay now the application is connected to the GitHub repo. You can see the commits that have been deployed to this app before. At any point in time I can actually right-click these and redeploy to revert changes if I find that they aren't quite working as expected. So we have our app now configured to deploy automatically but the App Service Extension will let you do other things as well such as manage the state of the app. You can browse directly to the website, stop-start restart. You can actually set up your continuous delivery here as well. Your next step would be to set up continuous integration on your GitHub repository using something like Azure pipelines, and this will run your lint and unit tests tasks as you validate PR's and you do your code reviews. Once you merge those items into Master they'll automatically be deployed to App Service. For more information or to run through these things on your own, you're welcome to visit us at any of these resources, visit our docs page, there are specific tutorials that walks through the steps that I just showed you. Also please reach out to us if you have feedback about any of these features. I'd like to thank you for your time. Enjoy the rest of Connect and happy coding.

Build a Custom ML Model Using Model Builder

>> In today's Visual Studio Toolbox, we're going to continue our look at machine learning. Veronika's going to show us how easy it is to create and use a model inside Visual Studio. [MUSIC] >> Hi welcome to Visual Studio Toolbox. I'm your host Robert Green and today we are continuing our discussion of ML.net this is part 2 of a three-part series featuring Veronika Kolesnikova. There she is. Hey Veronika. >> Hey Robert. Good to see you. >> Good to see you again. In the previous episode, we did a high-level overview. We didn't really get into Visual Studio yet but I think it was very good to set the stage what is machine learning? Where does it fit into artificial intelligence? Today we're ready to dive in, fire up Visual Studio and start building a model and then seeing how we can use it. >> Yeah that's right. Let me share my screen and show my Visual Studio. >> Which Visual Studio is this? Is this the old Visual Studio 2019 or the brand new just released Visual Studio 2022? >> That's the brand new Visual Studio 2022. >> Good answer. >> I've been using the old one and new one in parallel for some time, but now I fully switch to 2022. >> Excellent. >> Here I want to create just a simple empty console application. Creating new project window and choosing just a console app. I have a bunch of them so it's number two. I'm using C-sharp here and then creating a new solution. You can always name it something more meaningful. I think I'll just keep it as ConsoleApp2. >> Next one. Then here you can choose framework. I'm sure .Net developers have seen that window and they can choose the right .Net version that they prefer. >> It's in all about .Net 6, they can go back and watch .Net conferences a couple of weeks ago where it was talked about in great detail. >> Exactly. I will choose .Net 6 and create a new app. It is empty. Doesn't have anything, just Hello world. >> We actually recorded this before the launch so that's why it says Preview and it says watch the .Net launched on November eighth which I said we published this will have already happened. Not that anybody is surprised that when we recorded an episode at a time we actually did it ahead of time. >> So maybe we can cut out that yellow notification but then it still assess preview here. >> Leave it in. >> You can see in the Solution Explorer at the ConsoleApp, doesn't have anything other than ProgramCS file and now I'll be adding machine learning magic here. Click on "Add" and then add machine learning model. >> Now did you have to install? Did you have to select a particular workload or add a specific component to get that or does it come by default? >> ML.Net ModelBuilder is available inside Visual Studio you just need to make sure that when you are installing it this component is checked. >> It's not a workload, it's one of the components? >> Yes. Or you can install it later if for some reason it's not there you can always go back and add it to your installation. Here when we are adding that ML.Net ModelBuilder we are able to change the name. I'm not going to change name just leave it by default since it's not the main goal of this demo but when you're working with production code working on your glam project, definitely don't forget to update the names. It just takes a couple of seconds and then you can see that beautiful UI that is ML.Net ModelBuilder. Now you can see the scenarios available data classification, value prediction and limited scenarios that I mentioned in our previous episode like anomaly detection, forecasting, and clustering. I want you to pay attention to those little labels here. It says locals for some of them and then Azure and local. For example, for image classification, you might not have enough compute power on your local machine in order to perform that model training and model creation so if that's the case then you can always connect to Azure and use that Azure magic. But today I want to start with the most basic, in my opinion, scenario. It is widely used in all applications, so I'll start with the data classification. >> This would be a good place for people new to this to start out and learn how this stuff works? >> Yes. You can use your local processor and the memory you have, you even need to connect to Azure you'll be using just text data so nothing too complex there or no heavy data is involved usually. Before moving forward you can see on that screen that it shows my local CPU environment just to make sure that that is working correctly, that I have enough computer power to actually move forward with that scenario. Then for next step, I have two options here connect to a file uploaded here or connect to SQL server. I have all the data inside ATSV file, so let me actually find it. I have a couple of options available I just want to use an option with less data so it is not taking too long. >> Did you create that data? Is it from a sample? >> It's a sample data. You can find it on GitHub there are also lots of third party tools and datasets that are available. I chose that Wikipedia detox file with only 250 lines. That is not enough for a production model but for demo purposes that's good enough, it will run through it faster. I will save a little bit of time and I got that data from GitHub but they are also online for those with datasets so you have lots of options for demo purposes. Here you can see data preview or what's happening in the dataset. It's not going to show you the whole dataset obviously because it might be too long. But just 10 rows out of 250. Then here we need to choose column to predict and we'll be predicting sentiment based on the text we are trying to figure out if it's a rude comment or non-rude comment, non-toxic comment. Also, you have that advanced data options. I have only two columns herein the dataset but if you have more then you can pick and choose what columns you're going to use and other data options that might be needed before that actual training. Now we need to move to next step and next step is training. Here is that higher tricky part where you need to choose how many seconds you want to train it. Out of the box and by default it tries to estimate the amount of time you might need but also they have that link to documentation so you can read more about training time and figure out what is better for your data set. Here I can start the training. In the output window I see what's happening there. It actually checks different model types and tries to figure out the best and the best model that was selected is that model here. I'm not going to try to pronounce it but again you can read a lot about types of models for all data that documentation. You can see that actually went only through two types because we had only 10 seconds but usually if you have more time to train it, then it will go through more types of models and pick the best one for your data. Also a good thing that you can see here on the screen is the accuracy. You can see that the accuracy's pretty low. I won't to recommend using the model with that accuracy unless you're building something not important at all. >> But then what would happen if you trained it for longer? >> That's a good question. >> Does it depend on the data? >> It depends on a data, we can definitely try to train it longer and just check if that accuracy increases. It might increase a little bit. I'm just saying that based on my experience but it's not going to increase a lot because of a pretty small dataset and you can see the same output but now because we have more time it went to three types. >> Interesting. >> It increased a little bit but still not production grade accuracy but that's okay we are using it just for demo purposes so I'm going to go to next step. Next step is evaluation. Here by default it's just picking out the first row and it gets that sentiment text from there. Ideally in the real world case, I wouldn't recommend just using the first row. Usually what data scientists do, they split the dataset into two parts, one they're using for building the model and the second one they using for evaluation or you need to have at least a couple of options for evaluations that were not part of that training dataset. But here I'm going to use just the default option click on "Predict". It is toxic. Its pretty sure 99 percent so that's pretty good. We can move to next step. Next step is consume. There are really good options here if you already have your application built up and you are just waiting for that machine learning parts then you can just copy that snippet that they are providing and start using the model. But if you want to play a little more with the model, see how it works, see a good example of usage and you don't mind creating a separate app that you will delete later most likely, then you can just add a ConsoleApp or a web API. I'm going to use the ConsoleApp here, and again you can rename it here. I'm not going to do that. Here you are getting basically the whole console app which is connected to ML. Net model. It is already using it so we can just run that console application and see how it actually worked. Let's go. Here, I'm going to close that and this part 2. You can see in the program file it is automatically passing that first line so whatever we did during that evaluation step it is trying to do the same thing here. It is using the text to predict and passing it to the model than some writelines in the console so they are helping to understand what's happening there. It provides them sentiment. Also repeats the sentiment texts and then provides their prediction. It's a good way to understand how you can use the model but you definitely don't have to include a console application in your solution. If you know what you're doing you just grabbed in that snippet that was there and then connect the ML.Net model. The model itself is here. It's that MLmodel1.zip. Can see it in both applications. I think I can just run it and make sure it is working. >> We basically created a model and then we're using that model in a couple lines of code and we're just passing in some text which could be read from a file or picked off a entry in a form or on the screen and then we're applying it against the model and coming back and saying that's rude. That's it? It's that easy? >> Yeah. That's it. >> That's amazing. Then of course all the difficulty comes in obviously the dataset and then somebody ahead of time needed to decide for all of this whether, what is a rude statement, what's not a root statement? What the values are, so the initial dataset initially this might be a manual process. Somebody just has a quick screen, brings all the comments and they say negative, positive, neutral? Then just go through that and eventually you'd have enough of that data in there to create an accurate model. You can create a model from any amount of data but the more data you have, the more good data you have, the better your model so then you replace that manual process with your ML model, review it to keep training the data and training the model and eventually whether it's a week, a month, a year who knows, hopefully sooner rather than later, you'd have a model that's good enough that you don't need to do that manual process anymore. You probably just on a regular basis check it to keep training of the model but eventually, you've automated this process. >> You need to keep logs as for any software for machine learning, you need to have logs to make sure that the predictions are accurate or maybe user feedback if you're especially building bots then usually people need to have that opportunity to complain or maybe say that something didn't work correctly and then you are keeping those logs. They can be automatic. They don't have to manually type anything but based on those logs, you can actually provide more data and retrain your model with that new data and make it more accurate and just overall better. >> That's basically all it takes to get started doing this with a very simple model very simple scenario but the key takeaway is about ModelBuilder which is part of Visual Studio you just have to make sure it gets installed. There is an amazing amount of power in there and of course, it gets better and better and better as the team behind it who knows an awful lot about this subject continues to improve it. >> I started using the ModelBuilder may be just as they released it a couple of years ago and I can see big changes definitely gets more convenient. Better faster, more convenient to use and I'm really impressed with the work amount that that team is putting on. >> What are some of the other basic scenarios that people could look into or that or that you've seen? Here we just did sentiment analysis. I know we've seen image classification. Is this a dog? Is this a cat? What type of cars is? But what are some of the other things that you've seen people be pretty successful with? >> I think all scenarios are definitely a popular that's why they decided to include them all here. Value prediction is popular. You can predict the value of your house if you're trying to sell your house or maybe buy a house. Data classification is simple and powerful and it is easy to set up, maintained with image classification and there are lots of tools that are available so you can mix and match maybe you are creating some parts using the model builder and then you can add cognitive services on top of it, doing speech recognition or something like that. >> If you wanted to do something with image classification you just need to know what the categories are ahead of time and then have enough images and identify that this type of images, this category and the more images you have ahead of time to go into each category, the better job the model would be able to do to figure things out? Then it's just a question of constantly monitoring how good your data is and how good your model is and your model is only going to be as good as the data you put into it, so it becomes this feedback loop of my models no good that's because my data is no good so you got to get better data which leads to a better model which leads to better data leads to better model and you get this virtuous cycle I would imagine. >> Yeah, data is constantly changing so we need to make sure that you're staying up to date. >> This would be a good place to wrap up this episode and what are we going to see next week? >> Next week we'll see a more advanced scenario. I want to show image classification. >> Hope you join us for that. We will see you next time on Visual Studio Toolbox. [MUSIC]

Bridge to Kubernetes

>> Don't you wish you could just focus on one micro-service instead of having to drag in the whole set of micro-services, and all of those related dependencies in Kubernetes? Well, it turns out you can. So join me and Nick Greenfield on this episode of Visual Studio Toolbox. [MUSIC] Hey everyone. Welcome to Visual Studio Toolbox. I'm your host, Leslie Richardson. Today, I'm joined by Nick Greenfield, who is a Program Manager on the Bridge to Kubernetes team. Welcome Nick. >> Hey, how's [inaudible] going? Thanks for having me. >> Yeah. Thanks to be here. It's a very smoky day out, but enough about that. The cool thing is that I hear there's this new feature available as part of Kubernetes called Bridge to Kubernetes. Can you tell us a little bit about what that is? >> Sure. Bridge to Kubernetes is an iterative development tool for developers that are authoring micro-service applications that target Kubernetes. It's offered as a client experience in both Visual Studio and Visual Studio Code through extensions that you can pick up in the marketplace. >> So what are some of the existing approaches that are kind of similar to Bridge to Kubernetes that can help address that issue? >> That's a good segue to this next slide that I have here. There's a lot of different tools and methods for solving these kind of challenges where you're working on a single micro-service in the context of a larger application. We've kind of categorized all those different methods and tools into three main buckets. There's the local approach, the remote approach, and then the hybrid approach. So like these columns that I'm showing here. The rows are key characteristics that we've learned are really important to developers when trying to be successful in their day-to-day task of developing their micro-service code. To go through these quickly, and I'll talk about where Bridge to Kubernetes falls into one of these categories. But starting with the local approach, the local approach really revolves around. I'm reading my code locally and I'm satisfying all those external dependencies on my local development machine. Whether I'm using stubs or mocks to fulfill those external dependencies, or if I'm actually running all those external dependencies on my development machine and configuring, and connected to them manually. Or if I'm even using a system like Docker Compose to run those dependencies and containers. Ultimately, what this approach does, is it allows me to work on my dev machine where everything was running on that workstation. This has a lot of great benefits as in everything's local so I get a really speedy developer inner loop experience. But it does lack in that, my dev machine is most likely going to be drastically different to the deployment environment where this code is ultimately going to be running in Kubernetes within Azure. The extreme of the local approach is moving into this remote approach. There's tools that basically allow you to write your code on your local machine. But then when it comes time to debug and test end-to-end, you take those changes and deploy them, and sync them into that deployment environment. So into Kubernetes that might be running in Azure. This plays off the weakness of local approaches that I get that fidelity to a deployed environment. Because I'm testing and debugging where this thing is ultimately going to be running. But now, I have these extra steps in my developer inner loop cycle of having to build and deploy my code. I think, working in the space for a little bit, the biggest learning that we've heard from customers, specific to this approach, is that it does add some extra friction onto a developer's workflow. Because now they have to have these operational concepts of how having to bundle their code, and build an image of their code and deploy that image into Kubernetes. What we've learned is that not all developers are accustomed to those sort of concepts and complexities. >> Yeah. >> The last approach, and this is where Bridge to Kubernetes falls in, is the hybrid approach where it's kind of the best of both worlds. Ultimately with this approach, allows you to do is write your code on your development workstation, but connect to external dependencies that are running in some remote environment. So I'm actually fulfilling all those external dependencies by connecting to my Kubernetes cluster, let's say running in Azure so that I can leverage the whole end-to-end workflow. But the only thing I'm running on my developer workstation is the code that I'm working on. Diving into that approach, this is really where we feel is like the best of both worlds, and we're seeing this resonate with customers quite well. If you're interested, I'll show you an example of how this works given that simple application that we were just talking about. >> Yeah, I do like demos. >> Cool. At a high level, when you are using the Bridge to Kubernetes, like I said, you are only responsible for running the one micro-service on your development workstation. So taking that example that I had earlier, where I have that bikes micro-service open here, which is one of these back-end APIs. The first thing you would do with Bridge to Kubernetes is create a connection to your clusters. In this case, I've created this bridge to my deployment environment. Once this connection has been made, I can actually pick from all the available services running in the cluster, which of these I want to work on locally. In this case, inside the bikes open, I would actually select the bikes micro-service. >> So can I pick multiple micro-services if I wanted to? >> Yeah. >> Or one at a time? >> No, you can pick multiple. So you'd have to have different instances of VS or VS Code open, but this can allow you to redirect multiple outlets. >> Got you. >> When I select, in this case, the bikes micro-service, we're actually putting this re-director in place. So that when I make a request that goes into the front-end of my application running in AKS, it will continue to hit all the services running in my cluster until that bikes service is called. At that point, that request will be routed to my development workstation where the Bridge that I'm running locally from here [inaudible]. >> That's really cool. It's kind of like you finish the jigsaw puzzle, and you're just kind of sticking in the missing piece when she go to run, test, deploy, all that jazz. >> Exactly. >> Nice. >> This is at a high level how Bridge to Kubernetes works. I love to show you an example of our Visual Studio experience, working on this exact application, and how you could go from zero to using Kubernetes on a project that you have of your own. >> Yeah, let's check it out. >> The first thing that I want to show you, is that application running in AKS. Is that bike renting application, where as I mentioned before, you can log in as a customer, and you can have a list of available bikes that you could reserve for a period of time. In this case, I would see the men's cruiser. Looks good. I can rent this bike. Then when I'm done using this bike, I can return this bike. It's returned back to the list of available bikes to rent. Just really simple application, just for demo purposes, right? >> Yeah. >> What I want to do is I actually want to work on one of these services. Since I'm going to show you the VS experience, it's probably appropriate that I show you the reservation engine, which is a micro-service that is written in.NET Core. >> Sounds good. >> Since you're over to VS, I have Visual Studio 2019 open. You'll notice that I have a solution that has one project open, and this is that reservation engine; that micro-service, that's responsible for actually reserving the bike. You'll notice that, over here, this is just the source code for that micro-service. There's no Docker file, there's no Kubernetes configuration, it's just that source code. >> So you don't have to sit through opening up the giant project, contain all the solutions you don't need, except for the one, right? >> Right. So it's just that one micro-service, nothing else. >> Cool. >> Now, since I have this open, and if I go to the VS marketplace and I installed the Bridge to Kubernetes extension, what will happen is I'll have this new launch profile that's available for me to use up in this list of launch profiles that I can select from. When you select the Bridge to Kubernetes launch profile, the very first time you'll be presented with this dialogue that I have open here. What this dialog allows you to do, is define the connection from your development machine to your target AKS cluster, or you can select that service that you want to redirect to your local running version. So just to quickly walk-through what's required here, [inaudible]. A subscription is required, and within that subscription, I have available clusters that I could select from. In this case, it's your Azure Kubernetes clusters. Then I have filter because I have different namespaces within that cluster, so I'm going to select the namespace that's running this application that I want to start debugging. My bicycle application is running in the bike app namespace. Within this namespace, I have a list of all those services that I saw from that diagram earlier. I want to select one of these that I want to redirect my locally running version. As I mentioned, I have the reservation engine open, so I'm going to select the reservation engine here. This next dialog here are the drop-down, basically it's asking me to select a launch profile that we want to clone. This app is a launch profile that I am familiar using with this micro-service. What we'll do is we'll clone this launch profile with some extra configuration that's taken from the Kubernetes cluster. >> Okay. Is that just to make sure that your local content is in sync with the rest of? >> Yeah, so the reason why we clone is we want to tap into how you're familiar with developing. If I'm used to developing this application locally, however that may be or whoever profile that I have set up and configured, we want to allow you to continue using that, except we'll add some additional configuration into that launch profile. That is from the Kubernetes environment that allows you to talk to those other services. It basically continues doing what you were doing before, but we'll throw in some extra configuration for you to use the Bridge to Kubernetes' functionality. >> Neat. >> Yeah. This is actually a really neat feature that we just released, I'm a little excited about. I don't know if you picked up on how we're redirecting traffic to your development machine, but that also become problematic when you're working in a shared environment. If I have other developers that are working in that same namespace on other microservices or the same one that I'm working on. Potentially we'll step on each others toes because their traffic will get sent to my machine environment. We have this isolation mode which allows you to work in isolation where only your requests that are being set will get redirected to your machine. We do that by giving you the special URL, in this case we'll prefix your URL that you're normally using through your application with your username on your machine and then this unique hash here. So that only traffic that's using this URL don't get sent to your local running version or the normal URL that everyone else would be using will continue to run in and hit the service that's running in the cluster. >> That's really cool. Ultimately, there might reach a point of course when you do need to push changes and things so you're still going to have to fix merge conflicts in that context. But as far as running and testing with the Kubernetes Cluster, it's not going to be an issue and you're not going to bump into somebody else who's also trying to access the same cluster at the same time. >> If I was working in a shared namespace you can imagine that if my friend John who was using the same namespace and working on different microservice, he would have his own special URL and I don't have my own special URL so that our traffic isn't conflicting with each other. That only my traffic is getting redirected to my machine and his traffic is getting redirected to his machine. >> Great. If only all traffic was like that. >> At this point I have this configured. Again like I mentioned before this is a onetime configuration that you would set up when getting started to boost your Kubernetes. We persist this you can always go back and change it later. But for this case I'm happy with it, so I will hit "Okay". We'll check to make sure that we can actually isolate that service and we can redirect it to your local running version. So this usually takes us a couple seconds. Cool and that's done that check passed. Now if I want to start working on the service and hit some breakpoints let's do that. I'm going to open up a file here this is the bikehelper.cs and since I'm debugging in the reservation engine microservice, so when you reserve a bike this is the service that will get executed. I can actually put a breakpoint and let's put it in this reserve bike method that seems appropriate for this service here. Then since I'm targeting that Bridge to Kubernetes launch profile I can F5 and what it's doing is going back to that diagram that I showed you before. At this point, it's creating that bridge between my developer workstation in that Kubernetes Cluster. Would you require admin privileges on the client machine to allow that traffic to be sent back and forth. So that is one dependency that developers will have to have when working with Bridge to Kubernetes. At this point what it's doing is it's establishing that connection, it's finding that service in the cluster that I want to redirect to my machine. What it's doing it finds that service is putting that redirector in place and then it's going to make it so that any requests that hit that service will actually get sent to my machine. I just got my UAC prompts so I authorized that. It looks like that connection has been made it's starting my debug session here. As you can see that special URL that I had in that dialogue where my debug session was started it actually launched that URL. So here I am with my application and you can see I have that special URL that was provided to me when I clicked, I want to work in isolation. At this point I can chart a debug at my service and an end-to-end scenario. I'm actually hitting the services that are running in AKS at this point. So this is the front end that we'll call the user microservice here we go. Now that I have a list of bikes to choose from, I can select a bike. Again all of this traffic still happening within the cluster nothing is being redirected to my machine yet. But now when I'm actually going to reserve a bike and it's going to actually send a request to that reservation engine microserver. You'll notice that that request will get sent to my VS instance, you see VS has popped open and I'm stuck at my breakpoint where I can debug, step through the code and however my debugging practices, I'm open to using wherever debugging practices that I'm familiar with. >> Cool. It's essentially skipping over the existing microservice that's up in the cluster and just redirecting to your local machine? >> Exactly. This is right so I can iterate on my code, I can make changes, I can debug maybe potential issues. Then again the only thing here that I want to call out that for me is the most exciting thing about this feature is that I'm only running that one microservice I don't have all these other services I'm leveraging them from running in that Kubernetes environment. Again, no Docker files, no [inaudible] Kubernetes Artifacts. I'm running this natively on my machine. >> Yeah, that's so cool. Even locally sometimes when trying to look at a huge project but you only need a chunk of it. It's just like I'm spending all this time debugging this other issue that's not even my responsibility. All these other dependencies. Yeah so that's cool that you don't have to worry about that. >> Yeah. In this point as was a developer I'd step through this code and when I'm have you there I can hit "Resume" and that requests will get sent back into the cluster to be completed. The really nice thing about this is that if let's say I actually make a change as a configuration change that I would need to restart my debug session. So if I was to exit my debug session here, you'll notice that I'm no longer in that debugging mode, but I have this yellow banner up here this info bar that says, "Hey, your service reservation engine is still being redirected to your machine." Yeah, I can make a configuration change and you know I'm ready to F5 again. What's going to happen is it's actually going to skip that connection that we went to initially because we're already connected. Here I am, my application launches and I can know iterate on my code as I look. >> That's great. It's almost like it got cached someplace and so you need to use again while you are in the same VS session. >> Yeah, that is the Visual Studio experience for Bridge to Kubernetes. >> That's really exciting and I think that could save people a lot of frustration. Based off of that, are there any existing limitations that you want to tell viewers about? >> These limitations, we'll we're working with hard to unblock any limitations. We're working with developers, we're understanding the applications that they're developing and where Bridge to Kubernetes fits and really just understanding the different scenarios that we need to support. I would say the one thing that we get asked constantly and I'm really excited to announce is that people want to use Bridge to Kubernetes on Kubernetes Clusters that are not AKS clusters. So a Minikube Cluster where it's basically running your Kubernetes cluster on your development machine. We are in the process of actually enabling a public preview that would allow you to use Bridge to Kubernetes on any Kubernetes platform. So it's a really exciting announcement that will happen in a very near future. >> That is really cool. Speaking of previews, how can people access this tool. Is it available yet? >> Yeah, so we recently just went GA so that's really exciting. >> Congratulations. >> Thank you. There's some quick starts under the VS code documentation under that developed with Kubernetes and we also have some getting started material under the Visual Studio container tools documentation. I will absolutely provide us some information on how did we started with those. >> That is fantastic. You already mentioned that you're working to you expand Bridge to Kubernetes functionality out to all Kubernetes platform. So what else is next for Kubernetes? >> Again, it's really understanding what the scenarios that different development teams had to use. Actually one limitation that potentially when people are watching this video will no longer be a limitation, is only targeting the Linux containers in Kubernetes. We've heard that there are a lot of development teams that are in this hybrid scenario where they're running Windows containers as well as Linux container. We want to make sure that we cater our tools to all different situations. We're really working through having this ability where we target any of these containers. >> That is very exciting. Well, thanks for sharing that, that is a really cool tool that I think can help a lot of people out. I really like that you can just segment the microservice that you need and don't have to worry about anything else seriously. >> Focus on the business logic that Microsoft [inaudible] in front of you >> How much time gets wasted just trying to figure out how another chunk that's not really your problem connects to the piece you're working on. So super exciting. >> Yeah. Well thank you. >> Thank you. Yeah, thanks for being here Nick. So go try it out, it's GA now officially. >> Yeah, we want to know what you think so we'll provide some information on how you can get in touch with our team and we want to hear about your experiences with Bridge to Kubernetes. So absolutely reach out. >> Awesome. Until next time happy coding. [MUSIC]

Blazor Tips and Tricks

>> On today's Visual Studio Toolbox, Ed Charbeneau is going to show us how to set our Blazors to run. [MUSIC] >> Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Ed Charbeneau. Hey, Ed. >> Thanks for having me, Robert. >> Welcome back. >> It's great to be back. >> Ed's a Developer Evangelist with Progress software, and a regular guest on the show, but it's been about a year since you were last on, right? >> It has been. I've been working hard on Blazor for that entire time. >> So a year ago, you and Sam Basu did an episode on Blazor, I believe it was one of our long ones. >> It was. >> Well-received. >> An hour show cut into bite-size pieces. >> Back when we used to do hour-long shows. So it was an introduction to Blazor. Today, we're going to take a look a year later, and you're going to catch us up to speed on some of the most frequently asked questions that you hear, some tips and tricks that people doing Blazor would need to know. >> Yeah. >> But before we dive into that, let's do a brief refresher of what is Blazor. >> Yeah. So like you said, we took a look at Blazor a year ago, it was a very early beta back then. It's now rolled into the official ASP.NET Core pipeline. So Blazor is a brand new front-end development framework, so a SPA framework that uses C#, Full Stack. So we can actually write client-side application code with C# and not have to rely on JavaScript like we normally do with jQuery, React, or Angular, we now have Blazor to take place of all of that, and we have.NET end-to-end. >> Cool. >> So we saw it early last year, a lot of things have happened since then, and every time I present on Blazor, I get asked these questions that are really great questions, but just at a glance, you don't quite catch when you're talking about Blazor so I thought I'd bring some of those questions up with you today. >> Yeah, cool. Let's do it. >> All right. So I'll hit one of the ones that is the most popular question I get, and that is, does identity work with Blazor? Now, people usually frame that question, does authentication work with Blazor? Authentication is actually a browser behavior, so that's usually happening on the client, but what they usually mean is, does Microsoft Identity work with Blazor? Actually, now it does. So with server-side Blazor shipping in ASP.NET Core 3.0, Microsoft Identity will be available with the application. If you click "File New Project" just like you do with an ASP.NET MVC application or Razor Pages application, you get the dialogue in the File New Project, where you can click to change your authentication type. You get that same experience with Blazor. What you get out of the box is actually what we have running here. Just like in an MVC application, you have your login and your register links at the top of the page. So we can click "Log In" and we get prompted with the identity log in experience, and I don't have an account, so we can click "Register" and create a brand new account. Just like with MVC or Razor Pages, we can create an account here, and what I want to show if I can get a correct password through this system here, I don't remember what their requirements are. Now, we get an error screen or what looks like an error screen, but it's actually something very helpful, and MVC does this as well. It says data operation failed processing requests, it's because we haven't created a database yet. >> Okay. >> This is a brand new File New Project experience, but what's nice is we get a button on the error page that says, "Apply Migrations", we click it, will actually create the database for us, Microsoft identity database. It will apply the migration to our database, create all the tables we need, and then it will bring us back into the application, sees us try refreshing the page so we can come back, hit "Continue", and now, we're actually logged in. It says, "Hello Ed Charbonneau@progress.com." So we have identity working, it's backed by SQL and.NET Framework and this comes out of the box with a few button clicks during the File New Project experience. >> So this is a generic identity provider. Can you hook it up to Active Directory? >> You can hook it. >> Or Azure Active Directory? >> You can hook it up to Azure and that steps you through as well in the File New Project experience. >> Okay. >> One other notable thing that's really interesting about the way identity works in Blazor right now is another question that I get asked a lot, and that is, do Blazor components work with MVC, and can you mix MVC, Razor Pages, and Blazor in the same project? So if we go under "Areas" and "Identity", and we look at our "Pages" in here, our logout or login pages, these are actually Razor Pages. So we have Razor Pages that exist in our Blazor application, and they're able to work side-by-side. Now, another thing is people ask, can I use Razor components or Blazor, the component framework inside of an MVC or Razor Pages application. That ties into the same idea. If we go into our host cshtml file. So.cshtml is a Razor Pages or Razor MVC view, inside of here, this is the bootstrapper for a server-side Blazor project, but this is a Razor page. If we look right here, this is where the application starts up, and we have inside of our app tag an HTML helper that says, "Html.RenderComponentAsync." This RenderComponentAsync method is something that we can call and bring Razor or Blazor components into MVC in Razor Pages views. >> Cool. >> So that's another frequently asked question. Two things tie together in my opinion, talk about using all of ASP.NET in a Blazor application, and that is possible. >> Cool. >> So the next thing that I wanted to show is people asked frequently because they see Blazor component. You can refer to these as Razor components. Razor components is something that is the component model of Blazor. So Blazor components, Razor components, interchangeable. >> Okay. >> But when they look at one of these, it's all written in C#, and your markup and your code is all in the same file. So one of the questions I get right away is, can I separate those two things because I don't want my markup and I don't want my C# code intermingled? So I've got an example here where I've already started taking these two things and decoupling them. So we'll finish this up here. What I want to do is I have a fetch data component, and I have the code section down here. What I want to do is remove this code section. So the first thing I want to do is create a C# file, and I want to name this file the same as my component, but with the extension.razor.cs. >> Okay. >> So what that does is it matches up with our component filename. So our component is FetchData.razor, our code behind is going to be FetchData.razor.cs, that allows to the nest in Visual Studio. So when we name them like that, that semantic allows that nesting to happen. So we get this nice tree effect where we can collapse that code behind down if we'd want to. So I'm going to click on "FetchData.razor.cs, and this is the same code that is inside of that code block. I went ahead and moved it out to keep this nice and short. >> Okay. >> So in FetchData.razor, we can now take out this code block because we have that inner code behind file. >> Okay. >> So to marry those two things back up together, we simply come back up to the top here. We just call inherit, so we have an inherits directive. Then we point to that code behind file. So this is called fetch database. The component name is fetch data, so this is the base of that component. So we'll save that. I can also remove this dependency injection from it because that now happens in the code bar. So now I have tied those two things together, and all of our little red squiggles have gone away, and we separated those two pieces of logic. So our markup is in one file, logics on the other. >> So you named that fetch database? >> Yeah. So the filename itself is fetchdata.razor.cs. >> Okay. >> To provide that nesting. But we can't call it fetch data, because it will collide with the component names space. >> Right. >> So we can't have two fetch data classes. >> Okay. >> So we got to give it some things. >> It's a partial class, it's an entirely separate class. >> Excellent question or observation. Partial classes aren't supported yet. >> Okay. >> But it is something that may come in the next release of the preview. >> Okay. So fetch database was just a naming convention that you use. >> It's a naming convention that I use, and it's pretty common in the community right now, is to name that as your base of the component itself. >> Okay. >> Partials may be coming soon. >> It's okay. >> So this may change a little bit over time, but this is one way that you can separate those out today. Also we need to inherit from component based on that. So that gives us all the lifecycle methods, and everything that is part of the component. >> Right. >> So another notable piece is the inject parameter here. So we're injecting through property injection when we do the code behind versus when we're on the markup side, we use an inject directive instead. >> Okay. >> So that's one piece that people look for when they start refactoring this out, is they don't know how to inject that properly. So the inject attribute on the back end side, and it's inject directive on the front end side. >>Okay. >> So that's one of the pieces that people ask a lot about. >> You then you would expect ultimately that that would just be an available refactoring inside the Visual Studio editors so you don't have to do it yourself. That might be a nice feature request. >> Would be a good feature request. There's a lot of tooling changes that will come with all of this new blazer stuff. >> Right. >> I've talked with Daniel Roth and his team. They're very optimistic about what they can do with the razor engine itself. There was a lot of tooling that can come in the future. >> Cool. All right. >> All right. So we can look at some more frequently asked questions. Another one is we get this application out of the box. We need to rerun that, we've done some code changes here, we'll pick this back up and run it. We have this counter component that comes out of the box. The count starts at zero if we click on the counter. This is all file new project experience. So anybody that runs blazers probably seen this counter component before. If we go back home, and then we visit the counter page again, our state is gone. >> Right. >> So don't share a state if I created more counters. They don't share that count. So we can have multiple counters on the page, they would all have their own independent counts. So how do we manage state if that's something that we do on? So there's actually two ways to handle state in, well there's multiple ways to handle state in blazer. I'm going to show you two of them. There's actually some components that are designed for this, so we'll look at a component approach and then we'll look at using dependency injection and do some application state. So one thing I've added to this project, and under my shared folder, I have a component that I wrote, very simple one, is called counter state provider. So this is a provider component that I can plug into my application, and anything that is a child of it will receive the values that I assign to this component. So it uses a special blazer component, this is something built into the system called a cascading value component. Inside of that cascading value component, I can provide child content. That's essentially what this component is for anyway. On value, I'm going to keep this as simple as possible and I'm just going to assign this. So this component's value will be just assigned to the cascading value. Any child component can subscribe to this value now. So what we'll do is we'll take this, and we'll put our current count for a counter component in that object. So what I need to do to implement this, is I'll go into my main layout and now I can surround any piece of HTML in my application that I want to be able to receive the data from. So we'll go right around the main component of our application, and we'll call in our counter state provider. We'll wrap that around the body of the application. >> So this is now at the application level? >> This is at the root of our pages. >> Okay. >> So anything, any of the pages that we load will be inside of the body. >> Okay. Got it. >> So now anything that's in the body which includes our counter component, will be able to receive that. So how did we receive that inside of our component? So there is a special parameter that we set up. I'm going to use a shortcut here, and we're going to use the cascading parameter attribute on a property. We'll set this up and call this current count, or actually, we need to bring in the component namespace , because this is going to resolve to a counter state provider, and then we can name it, and we'll name this, let's keep this simple and just call it state. So this state will be assigned the value of this that it brings in from the counter state provider. So now, we can consume it, we can get rid of this current count equal zero. When we increment our count, we'll use the state instead. So we'll say state.currentcount, that's coming from the state provider. >>Okay. >> Up in this section, we'll do the same thing; state.currentcount. So that should tie it all together. Now, when we run our application, we won't lose that state as we go from page to page. We can also take advantage of that. So now we have our Current count. We can go to our "Home" page, go back and still have a four. Make this a little bit cooler. On our Index page, we can consume that same StateProvider. So then we have shared state across the application. So we'll do the same CascadingParameter. It's going to be a CounterStateProvider. We'll call it State. Then in my Hello world section here, I can just write out Current Count at State, CurrentCount just like that. Now, this will appear in our Home page. So now, we're getting the count off the counter even though they're not on the same page together. So our Current count is zero. We click this up. We go back and our "Home" page changes. >> Very cool. >> So that's one way that we can share state across the application. This is using a piece of markup, the StateProvider uses the cascading value component. So this is markup-driven. We can also do this through code. So we don't have to have this markup piece that drives the State management. So in my application, I've added a very simple poco object, plain old-class objects, called CounterState. I have a CurrentCount on that as well. This is something we can just inject in our application through dependency injection. So if I go into "Startup.cs", I'm going to scroll down to where all of my dependencies are registered. In services, I'll just uncomment this line that I've added earlier. Services.AddScoped of type CounterState. So now, I have this object, this CounterState that is available to my application through dependency injection. So if we go back to our "Counter" component, instead of using a cascading parameter, we'll come up to the top of the page and we'll use the inject directive. We can inject to that dependency injection that CounterState through dependency injection. So we'll call it CounterState. I think I'm missing a namespace here. This is on data. Data CounterState. We'll simply call that State again. So since we named it the same, we actually don't need any code changes here. I can remove this. Now, our data is resolved through dependency injection instead. So it has the same idea but it's application level. Then in our "Startup.cs", we'll go back here for a moment. We used AddScoped to add that to the application. We have several ways to add things to our container. We can use AddSingleton, AddScoped. The reason I chose AddScoped versus AddSingleton, so on Serverside Blazor, you're sharing that application state with the entire user base if you use AddSingleton. So that will be a single instance per application not per user. So it's a very important thing to know. You don't want to share certain things with everyone. Whereas, our weather forecasts service, something is pulling a weather data, we can share with all users because it's going to be the same. So those are some of the most frequently asked questions that I get when I present on Blazor. People ask about state management, they ask about identity, and they ask about code separation. Those are the real heavy hitters that I get all the time. So hopefully that clears things up for you. >> Yeah. That's awesome. So if someone who is starting out with Blazor, what are briefly some tips and tricks on how to get up to speed on it, how to get used to it, how to understand what it is and how to use it? >> So my biggest advice would be first of all you go to Blazor.NET and you walk through the Getting Started materials. The.NET Docs team, they've done a fantastic job there. Second of all, Blazor is a lot different from MVC, where in MVC applications, we're rendering strings. Blazor has something called a render tree that it builds. It's not a string, it's a representation of the DOM, the Document Object Model that is held in memory and it does diffs against it to see what's changed. So it's a big difference from HTML Helpers and Razor Views that just render out strings all the time. The reason for that is those string rendering mechanisms, the client-side code is done in JavaScript. So it goes back and it finds pieces of the DOM, manipulates it, edits it, deletes it, those sort of things. In Blazor, we work with the render tree. The developers do. Then the framework takes to render tree and applies the changes for us. That's what allows C# to be able to work on the client-side. >> Cool. Your impression of how far along this is. Is it preview? Can you put stuff into production with it? >> In September, we will see a GA release. >> Okay. >> So it's coming soon. For server-side Blazor, we'll have the global availability soon. Client-side Blazor will come sometime next year. We haven't got a solid date just quite yet. I've heard quarter one, quarter two. So that is coming soon. >> It requires.NET core? >> Yes. >> Is that true? >> Blazor requires.NET core. >> Okay. >> It's currently on set for.NET Core 3.0. Client-side will likely come with.NET 5. >> Okay. Cool. Thanks for that. >> Thank you very much. >> All right. >> Hopefully, everybody found something useful out of this. Getting started with this stuff is a little tricky. It's a brand new preview. So I figured that most people are new to the concepts because the entire framework is new. Something I've been working on very closely for the last year because of my job with progress, we build UI components for everything. So we jumped on the bandwagon early and created a suite of Telerik UI Components for Blazor. It's been my main focus. >> We will have links to that in the show notes along with the places people can go to learn more. So I hope you found that useful and we will see you next time on Visual Studio Toolbox.

Blazor Part 2

>> Hi welcome to Visual Studio Toolbox. I'm your host Robert Green and today's episode is part two of an hour longs worth of Sam Basu and Ed Charbeneau talking about Blazer. So, I explained previously, they were here taping a bunch of episodes with me. They wanted to do an episode on Blazor. I unfortunately had a conflict I couldn't get out of and Dmitri wasn't available. So, we left them alone in the studio and they talked for an hour on Blazor. Really good stuff, but we decided an hour is too much, so we cut the episode in half. Hopefully, the cutting job isn't a little too choppy, because we're just going to pick up where they left off now. >> Let's do file new project. We'll do ASP.NET Core web application again. This time we'll do the full stack version. Now, it's important it spins up, we'll outline when I say full-stack, we're not doing Server-side rendering. >> Okay. >> So, we're still using that Client-side, we're going to ship everything to the browser, let it run on Web Assembly. We're not doing ahead of time compilation of the views, and sending any HTML down the wire other than the bootstrapping index page. >> Sure. >> That's it. It's something that we just need to clarify, so people don't expect that those Razor views are being compiled on the server and HTMLs being sent down the wire. >> So, you are coming back to the server for data, like essentially UPI implants. >> So, if we look at this, it's exactly what you said. We have our client app, which is the same exact thing that we saw before. Now, we have a server project, and the server project has a Web API controller. This is going to supply that weather data that we saw coming from a static file before. >> Okay. >> So, it's web API endpoint with a Get action on it, and it's just going to randomize some weather data for us. >> Yes. You can hook this up to any data source you want. >> It could be Cloud service and Azure function, Node.js, all the above file. >> Or SQL server sitting under my desk. >> Cognitive Services, you could do some cool machine learning stuff there. >> So, this is just web API and I can do CRUD operations like create, read, update, delete? >> Absolutely. >> Okay. >> Then notice we have a shared library now. >> All right. >> So, if we're on the Client and we're going to iterate over a list of weather forecasts. So, this is the same view that we saw before, an array of weather forecasts is coming in from this GetJSONAsync, and the server sending a list of weather forecasts. Then the weather forecasts can live in a shared location where both projects can access that class type. >> I see. And is that like, how would you show, is that like a document standard library? >> Absolutely. >> Okay. > So, this is a .NET StandardLibrary. It's being referenced, if I go into my dependencies under projects, you can see shared. It is actually using the .NETStandard.Library as well. >> So, you can reuse this from Xamarin if you wanted to? >> Yes. You could share it not only across Blazor projects, but any .NETStandard project. That also opens up this to a whole ecosystem of things that already exist. So, think about that for a minute, we'll actually have a demo at the very end here, we'll I've gone in and tried some of these things. >> Like existing NuGet packages? >> Absolutely. >> Okay. >> Yes. NuGet, .NETStandard packages that are on NuGet within reason they work within Blazor. Now, if they have some direct access to the system, they're looking at your system temperature, registry or things that belong on maybe Windows, it's not going to happen. What you can do though is load in things that are business logic and stuff like that. I'll show you a use case for that, where it's been successful for me. >> Okay. >> So, this is the other project and we've got the same type of structure, but inside FetchData, we're actually going out to an endpoint now and pulling that data in through an API. We have shared logic folder. These are all very good things that help us be productive. >> Sure. So, in this solution, you could host the server in IIS or anything that you would host an ASP.NET application in, and then the client could just be served up from anything you want. It's a Client-side? >> Absolutely. In this scenario though, the client application is actually being served by .NET Core, but you could split those out if you wanted to. >> Okay. All right. >> So, let's look at another project. I'm going to open this one. I didn't want to do too much live coding here, so I know I will fat fingers something and we'll have some demo fails. So, I pre-created in here. Let's pull it off my start page here. I want to show the concept of having external component libraries. So, there's currently no file new project experience for creating a component library from within Visual Studio. There is tooling however. We can drop down to the command line, we can type in .NET new Blazor lib. So, that .NET new Blazor lib will spin up a project that is a boilerplate for creating component libraries. >> Okay. So, let me back up, you said CLI. So, all of this Blazor stuff I can do it through CLI as well? >> Yes. Technically, it's a NuGet package, so you can go into your command line .NETnew-I will install, and then you point to that package and it will install those command line tool for you. >> If this is on .NET Core I can do this on Mac or Linux. Right? >> Yes. Again, Blazor.net and look at getting started, you'll find those CLI commands. So, people don't have to try to memorize them as the same here on the show. That's the best place to find them on Blazor.net. So, we have our client application and we have another library called MyComponents. I have a component in here called MyComponent, really cleverly named component here. I've put that component on my index page. So, on my index page I have MyComponent. >> So, you're referencing your component project from inside the Blazor project obviously, and then you're able to just render that. Does the component have other NuGet dependencies that you're putting in? >> Right now, it's just dependent on the Blazor libraries. So, if we look in ".NETStandard", you'll see we have our Blazor libraries here. >> Right. >> It's dependent on Browser and build. If we come into our dependencies on the client application, you can see I have a dependency on MyComponents. Then that dependency is registered in the Viewimports file. So, here it's being registered as a tag helper. So, this is another familiar concept from ASP.NET Core mindset. >> Okay. >> So, I'm registering any components that exist in the MyComponents library and referencing. That allows me to drop it on my index page. So, let's take a look at what this component does. >> So, the code looks almost identical to just rendering a component that's inside of your client project, but you're just pulling this in? >> Yes. So, I have this big box with a dashed line. Most of this is actually boilerplate. I've modified it slightly, so we have a cool demo for the show. I've wired up what already exists in that template, just so it may give a little more flair. So, I'm going to click on this box, and now I'm going to prompt. I can type anything in here. I'll say, "Hello VS TB," and hit "OK". Now, that data's represented in its bound inside of that dotted box there. So, let's see how that works. So, again MyComponent, will look at MyComponent.CSHTML. It's a simple div, I'm binding to the HandleClick function handler. >> All right. >> Or ClickHandler. It's got a regular CSS class on it with MyComponent, and then I have a value called message. So, I'm going to create a placeholder for it, string message equals, "Click here to change". That's the default value. Then whenever I click "HandleClick," I'm going to set the message and this is going to do it asynchronously, and it's going to make a call to JavaScript. It's going to display a JavaScript prompt in the browser. >> Got you. >> So, I'm making a call to JavaScript from my C# code, and then when that comes back, we're just going to notify Blazor that the state of the view has changed, and it needs to do an update to the shadow DOM. Now, if I dive in to MyComponent, you'll see this Content folder. This is put here by the template, and inside of that are resources that belong to the component, including this example JavaScript interrupt. >> All right. >> So, this is a JavaScript module, and it's being loaded into the global namespace of the window here. So, on window, we have our scope of example JS function, and a function called showPrompt. >> All right. >> Then that prompt takes an argument of a message. So, we can set that prompt to whatever we want and then it returns the values that was put into the prompt. >> So, how is the name showPrompt different from what you are calling from JavaScript? I thought you just said prompt in your component. >> So, there's a nice little wrapper piece of syntactic sugar around that. If I open up example JSInterop. So, there's little C# extension method in here, and it's called ExampleJSInterop. Sorry, it's not an extension. That is just a static method. It's asynchronous, so it uses a Task, returns a Task at string, and it takes in the Prompt message and returns a string value as a Task. So, here's where it's calling that scope, and then, that function in JavaScript. >> Okay. So at this point, you're mixing and matching JavaScript and .NET on the client-side. So, if you have existing JavaScript assets and functions, you can call them from .NET. >> Yes. So, if you have existing JavaScript libraries that you love and they're too big to maybe translate over, or you want to have a moment where you're migrating to. >> You're in-between. >> Yeah. >> Yeah. Okay. >> So, you can do some migration there, or WebAssembly may not target certain things yet. So, for example, we can't pull up a prompt natively in C Sharp through WebAssembly, so we need to reach out to JavaScript to say, hey, we need a prompt, and we're able to do that. So, we have that flexibility, and this is how it's done. >> Okay. That's very interesting. >> At the same time, we've got little experience with developing component libraries, and you can see there's no page directive on this one, it's just HTML, a little bit of C Sharp in Razor, and this is very easy to understand what's happening inside of the system. So, let's do the server-side example now. >> This is where you're going to make it confusing for me, aren't you? But let's see. This is interesting. >> So, we've been talking a lot about WebAssembly, we're going to get away from that for a moment. We're going to actually do all this in the server. We're going to create a Blazor application that is running on the server, and all of the data is going to be handled through a WebSocket. So, the application on the client is just going to be a very thin client. It's just an HTML page that spins up a SignalR listener. >> Connection back to the hub on the server. Okay. >> Yeah. So, there's a hub on the server that's all part of the application framework. So, we don't really have to concern ourselves with all of that. It looks exactly like the previous few examples. Let's run this guy. While that's spins up, I'm going to fire up yet another application. This is Fiddler by Progress under the Telerik brand, something that you and I know and love. >> Most web developers can not live without Fiddler. >> Fiddler is a free tool that you can download and use, and it's very helpful for working with HTTP connections and things like that, because I want to show you, when we're running this, WebSockets perform a little different than your normal requests. So, the server has sent down the application through the SignalR pipeline. We have this active connection back to the server, and we can do updates like this and pull in data from our application, and we can do all this using that SignalR hub. >> Okay. But this one, this is not running purely client-side. >> There's actually almost nothing running client-side in this scenario. So, let's actually open this guy up. Let's pull up the "Network" tab, and again, we'll do a reload. Notice all the DLL's aren't coming down this time. >> No, they're not. >> Because they're staying on the server, they're running on the server, and we have a small JavaScript file that's handling all of this for us and just sending back changes through that SignalR pipeline. >> So, how does the server know about the DOM, if you had to do anything? >> So, that's in the diffs that it's sending back, and it's a binary package it's sending to Blazor to make those changes. So, for example, if I navigate here, let's clear this window out, and let me come down. Let's go to "FetchData". Notice the data loaded. So, the data is in here, and we didn't make any kind of communication back and forth. Let's do the "Counter" component. I'm clicking, there's no communication back and forth. You might [inaudible] surface think that you're not communicating with the server. Let's pull up Fiddler, and hopefully, this works for me. Let's try to put this side-by-side, and we'll do a click, and I'm going to demo fail. So, let's try clearing our, is Fiddler responding? There we go. Some kind of lag here. So, let me try again, and for some reason, Fiddler doesn't want to behave with this demo. So, I have a little demo fail. Normally, what we'd have, we'd be able to open this up, and Fiddler would actually show the Socket traffic. >> So, DevTools does not capture REP Socket's traffic that Fiddler can. >> It may. I just don't know where to look, if it's there. >> Okay. >> So, it may be a little bit of my inexperience with the WebSocket traffic in the tooling here. It does normally show up in Fiddler though. >> Okay. All right. >> So, every time I click this, actually, we've frozen up there. When we click this, we're actually sending some traffic through the Socket up to the server. Again, this is what happens when you work with experimental bits. Things don't always happen. >> You can pray to the Devil. That's enough. >> The way you expected them to. >> We get the point. So, this is running server-side, almost nothing on the client-side, and you are piping content through a WebSocket's channel or a tunnel, essentially. >> Yeah, absolutely. So, one other very big difference that you'll notice, remember before when we did our dependency injection on that FetchData? Something's a little bit different here. So, since we're on the server, we don't need to send an HTTP request. So, we can just new up a service, ForecastService. This could be maybe a layer over the top of [inaudible] Framework or something like that, but we don't have to send a web request because we're on the server with the data in the application and all of that, and we can just say, get the forecast asynchronously and do it that way. So, our dependency injection actually looks different as well. So, we're not injecting an HTTP client, we're just injecting the service, which is a C Sharp class that we've written. >> Right. Yeah. So, this is interesting. You're hosting the data on the server and you're also running the app right next to it. So, you can get the data just as quickly without making HTTP. >> You could see we have our WeatherForecastService in here, and it's just creating a Task, an asynchronous Task, return that array. Like I said, that could be your database there. So, no HTTP call. So, that's an interesting mode of operation. Let's do one last demo, where we show a project that I've created and used some existing .NET assembly from NuGet. I've got to stop this guy from running first, and then, I'll see if I can grab it off my Start Page, and I've lost it here. So, let's do "Open", "Project", and the project is called BlazeDown. I figured I'd go with the theme. Browser plus Razor is Blazor, Markdown plus Blazor is BlazeDown. So, let's do little bit of BlazeDown. So, this is a Markdown Editor completely written in Blazor. So, I'm going to run this up, and it's a client-side application. It's running on the browser only. There's no server code in here, so we're going to get the application, the browser loads it up. We have Markdown here on the left, and we have the rendered Markdown here on the right. So, this is a very cheap Markdown Editor that we can just come in here and live edit, and those changes persist on the other side. We can use some of our Markdown syntax to change things like headings and do code highlighting, for example. All of those things are working here right in the browser and being rendered as HTML on the other side. Might expect a lot of code behind this, right? >> Yeah. >> I'm parsing Markdown into HTML real time. >> Are you doing this yourself? Or do you bring in some libraries to help? >> I'm not the smartest guy in the room ever, Sam. So, I'm actually using something someone else created. >> Okay. >> So, there's an existing library called Markdig. So, there's a dependency in this application, and if I look under "Dependencies" and under "NuGet". We've got something missing here, it's actually in a Component. Sorry. I've moved it out to a Component. So, our dependencies in that Component itself. So, I have a markdown component, NuGet and there's Markdig. So, this is off the shelf, I haven't modified it in any way shape or form, pulled it into my project and just started using it right away. I don't know anything about making a markdown parser. I didn't need to somebody already did the hard work for me, I can just pull that into my component, if I open up my component, the component takes and runs a function called BuildHTMLFromMarkdown, and I pass in this content value which is whatever you're typing into that text box. >> Okay. >> That runs this function called BuildHTMLFromMarkdown and returns at HTML using this method here called ToHtml and sends that back as a string. Then that string is loaded as raw HTML into the Component displaying it in the browser. >> Okay. All of this is now running Client-side entirely? >> This entire thing is running Client-side, so Markdig is running on the browser using the DLLs that come out on NuGet, those are actually running right here in the browser. I can do things like pull in, I can use the HTTP client to pull in Markdown files from another resource maybe GitHub. >> Right. >> Something like that. I don't know if people saw that I'd clear this out. I can do import and it'll go back and pull in that original file that I was using before. Then I can also do something cool here, I can say download as Markdown, and click that button and I'm prompted with a Markdown file. >> So, at this point, you were on the Client-side and you downloaded a file from the Client-side that was generated in the Client-side as well, right? The Markdown file is acting like an output of the Markdig extension? >> So, that's what we're going to get to now. >> Okay. >> I'm glad you brought that up Sam. I have a download Component here. >> So, there's another component? >> There's another component and this is called DownloadButton. >> Okay. >> So this Component has an OnClick event that's when you click the actual button itself. It has a property called Payload and a property called FileName. So if we look at our index page here, you'll see the actual Component being used, DownloadButton here and I'm setting the value to that same content value. I'm binding. All these things are just being bound to content value. The Markdown Editor itself, the Output and the button are all binding to the same set of data. Then I set the FileName to whatever I like that to be, and then when somebody clicks the button, let's look inside of our button. So, we go to DownloadButton OnClicked event fires, and I'm using a JavaScript Interop. >> I see. >> So, the JavaScript Interop is necessary in the scenario because of browser incompatibilities. So, I initially wrote this with no JavaScript whatsoever. You're able to do this in Chrome through a special type of URL that you can just set a prompt and click a button and that URL translates into a file download. That's not possible on Edge. Edge has a special API that is custom for Edge called msSaveBlob. So, I've wrote an Interop that wraps msSaveBlob. There's basically a simple browser check. So, if I go in here there's a function in here called, isHtmlDownloadAllowed, and there's also one to say, ismsSaveBlobAllowed. So, we check to see is msSaveBlob a function that exists in the browser? If it's not, that means we're probably not on IE or Edge. Then it fails over to the next mode which is this HTML download that is more universal. Then finally, if no browser support is there, we'll just throw a console message and you won't see that download come across. >> Okay. >> So, that gets invoked when we click that button, and but this project is a good example of how I can use existing .Net technologies, go into NuGet pulling some packages write very little code, almost everything that exists in Blaze down you just saw on the screen, just couple properties here and there and couple of function calls and I'm able to make something really cool like this. >> Indeed, indeed. So, that's very interesting. >> That's Blazor in a nutshell right now. 0.5.1 is the current release. It just came out a couple of weeks ago. May be updated by when the recording comes out on Visual Studio Toolbox. But just check Blazor.net for updates. >> Sure. >> See how that turns out. >> You're wearing an interesting shirt that says, "Goodbye JavaScript, " but it sounds like we're not really saying goodbye to JavaScript. You can do JavaScript and .Net Interop, but just like JavaScript runs natively in the browser or on the Client-Side now you've got C# running native on the Client-Side as well. >> Yeah, my shirt does say, "Goodbye JavaScript, hello C# and Blazor," but I don't wish any bad will towards JavaScript. >> Of course. Yeah. >> It's still, there's still some great frameworks out there that a lot of people are using. This is just another option for .Net developers and people that may want to use .Net for doing Web technologies and creating browser-based applications to use. >> Yeah, yeah. So, it sounds like if you are a .Net and developer and you want to stay on top of modern web but you don't want to write a whole lot of JavaScript, this is a way for you to write C# straight up in the browser and run it natively. What about performance? We are running native performance in the browser. >> Not yet. So, again, this is only like six months old. >> Sure. >> The performance, if you look at Blaze down, it's pretty performing, it does a good job. You're not supposed to be using this framework for building production applications because of the state that it's in, it's an experiment. The performance isn't going to be as good as JavaScript at the moment. But it'll get there over time. At least I feel that's the direction it's headed in and I think Daniel Roth and his team have a pretty good outlook on what's happening. >> It sounds like this is not just a Microsoft or a Google or an Apple thing. As long as Web Assembly gets better at executing those bytecodes we'll get more and more performance out of it. >> Yeah. Nothing about Web Assembly is Microsoft. It's the W3C standard. It's a standard technology that browsers are implementing, all the other evergreen browsers have it. Other technologies are looking at targeting it. There's Go Compilers, Russ compilers, C++. So, this is just another flavor of WebAssembly and a really cool framework built on top of it. >> Sure thing. So, sounds very exciting. Well, what's next? So, they just keep an eye out on what the ASP.NET team is doing and Blazor is as open-source now? Part of the GitHub repo? >> Yes. So Blazor is open-source. Again Blazor.net or look for it on GitHub. Further down the pipeline, we'll see some more experimentation. There's actually a project out there of using electron with Blazor and using that same signal or a type Server-side experience but it's using the electron shell instead. It's yet another avenue for this cool technology to take off. The experiments just keep producing really interesting things. So, keep an eye on it. >> They are very exciting. Yeah. Surely, you are prompt and I think if you're a C# developer and you want to see where your code can go, definitely keep, it behooves you to kind of keep an eye out on Blazor and where this is heading. >> Very much, very much so. >> All right. Well, thank you so much for sharing all this knowledge and all the cool stuff that the ASP.NET team and Steve Sanderson and Dan Roth and those guys are building, this is very exciting. So we'll see what comes out of this and how this evolves. >> Yeah. Hats off to them. It's really cool stuff and I've just been watching and enjoying all the things they're making and trying to help with issues on GitHub. If you get a chance to try this out and get the bits, click on the "Survey" button that comes with the example application, fill out the survey, get in touch with them on GitHub, let them know what your needs are so they know where to steer the framework and how to make it better. >> Yeah. Just like anything else in the ASP.NET is open-source and sounds like the community, this is the perfect time for us to play around and make sure we're doing this together. Yeah. All right. Very exciting, very cool stuff. So, this was all about Blazor on VS Toolbox. Hopefully, you guys enjoyed it. Keep an eye out on how this evolves. Very exciting times ahead. Thank you so much for being with us on this VS toolbox show. Thank you and bye for now. >> So, I hope you enjoyed that look at Blazor it's a revolutionary technology. It's still experimental but it's got some potential to really change web development. Hope you enjoyed learning about it and we will see you next time on Visual Studio Toolbox.

Blazor Part 1

>> Hi! Welcome to Visual Studio Toolbox. I'm your host Robert Green and this episode is part one of what winds up being a two parter on Blazor, which is an experimental technology that could revolutionize the web development world. I had Sam Basu and Ed Charbeneau, here a few weeks back. They were here for the Visual Studio Live Conference which was on Microsoft campus. I taped a bunch of episodes with them and they wanted to do an episode on Blazor. Unfortunately, I had a conflict and Dmitry wasn't available, so I left them alone in the studio. They were so excited. They spoke for an hour, so we're going to cut that in half. This is the first half of them explaining to us what Blazor is. >> Hello. Welcome to VS Toolbox show. My name is Sam Basu. Robert Green is busy, so I'm filling in for the day and with me, I have Ed Charbeneau and we're going to talk about something very exciting, especially in the ASP.NET land with Blazor and WebAssembly, right? >> Yeah. So, I'm a huge fan of Blazor right now. It's an experiment that's being worked on by the ASP.NET Team, Daniel Roth and Steve Sanderson. They're working hard, experimenting with this new framework. So, I'm happy to have the opportunity come on Visual Studio Toolbox and kind of share that story with everyone. >> Awesome. Tell us more about. >> So, my name is Ed Charbeneau. I'm a Developer Advocate with Progress or you may know them as Telerik. Sam here is a pro- a Developer Advocate at Progress as well. Co-worker of mine and we've kind of invaded the Visual Studio Toolbox episode here, to talk about Blazor. So, I am an author, I do some writing. I have a podcast called Eat Sleep Code and if anybody ever wants to reach out and get in touch, just give me a shout on Twitter. >> Okay. All right. So, let's dive in. What's the hop loud sounds like? There are some very sharp minds behind this at Microsoft and other places. You should tell us more. >> So, as a web developer that specializes in C#, one thing that I've always wanted to have is the ability to write C# and create Client-side applications using it. >> Okay. So, to kind of backup. So, with ASP.NET, is it entirely Server-side or we can do somethings Client-side but it's all in JavaScript? >> Right now if you want to write an application that's running in the browser, you're going to have to leverage JavaScript but there's some new things that have come around with WebAssembly, which is a- >> Okay. >> A way of natively writing code for your browser, that it understands using Web Standards, it's a bytecode format. >> Okay. >> So, it's similar to an assembly language, but it runs natively inside the browser and the browser understands it. So, we're starting to step away from the days where JavaScript rules the browser only and we're allowing some new things into the ecosystem. >> Okay. So, from what I understand like every browser has a JavaScript engine right, V8, or Chakra, or WebKit and is these engines that run JavaScript natively in the browser, Client-side. So now we're saying there's something more that the browser can run and that's the Web Standard that you've talked about. >> Yeah. I want to point out, this is a Web Standard. >> Okay. >> Because we've tried some things like this before and well things have changed. >> Things have changed. So, maybe to backup. So, I'm actually a big fan of Silverlight back from the days Flash was a plug-in. Sure, it had some vulnerabilities. I think Steve Jobs kind of wrote a scathing letter onetime to say. So, essentially when you run Flash on Safari, it makes your tiny iPad heat up and that not something Steve liked. So, he essentially kind of kill the plugins model and along with it, like, we never said Silverlight is done but, we kind of stopped talking about it and maybe the plugins model just didn't scale for the web. So, now we're saying "We're not going to do plug-ins. This is different." >> No. No plug-ins and don't get me wrong. These were things that were necessary at the time and people were doing the best with the best tools that they could, to build amazing applications. I'm sure there's some just phenomenal Silverlight applications out there that people have built but now's the time to start moving onto something else. >> Yeah. >> We're going to drop all those plug-ins and just use things that the browser understands natively. >> Yeah. With Silverlight though, I mean it wasn't just the plug-ins model. Like people who did Silverlight, we just enjoyed the Dev experience. The rich ecosystem. The data binding with C# and Xamarin. I think as developers, all of those skills, I mean they move forward with, be it UWP, be it WPF, or Xamarin.Forms. So, you can build cross-platform apps with the same skill sets. >> Absolutely. >> We're just trying to see how we can bring that Dev module bag, the ease of using Visual Studio and C# but do it differently in the browser, right? >> Right. >> So, let's start off with no WebAssembly. >> Okay. >> How does the browser work without it? So, normally we feed the browser HTML and JavaScript pages. Those things go through a parsing and then they're kind of precompiled. They're turned into a JavaScript tree and the JavaScript engine inside the browser interprets that into a bytecode. >> Right. >> So, it gets JIT compiled, turns into bytecode and then things happen within the browser. >> Okay. >> So, that's kind of where WebAssembly happens. What they've done is, think of this kind of like, for lack of a better term dependency inversion of control, right? >> Okay. >> So, we have this part of our browser that understands this bytecode. What if we took that part of the browser and exposed that to where developers could target it? So, this is WebAssembly. So, we can target this bytecode now and give that to our browser and your browser understands how to execute that bytecode. >> Okay. >> So when we do that, we open up that input to things like C++, Rust, Go, and our favorite C#. >> Okay. So, now you're talking about like higher level programming languages, been able to write things that we're going to compile down. Maybe not compilers. Maybe not the right word but, bring it down to that low-level assembly ish code, which the browser can execute on its own. >> Yeah. >> Okay. >> There's one more clarification to make here. This isn't bytecode that would run on your machine. >> All right. >> So, this isn't something that's going to get loose and have security issues. >> All right. right. >> For example, library that you send down, isn't going to be able to access your system registry or run natively on your Windows desktop. >> Okay. So, it is still running in the browser shells, so to speak. >> It's very much sandboxed. >> Okay. >> The bytecode is only going to be understood by the browser. It's not something that's used outside of the web. >> So, why should I trust WebAssembly? Is this like a standard that the web community has accepted? >> Absolutely. >> Okay. >> So, this is a Web Standard. It's in all the evergreen browsers and then, also if you have another browser that's same, maybe on a mobile device. Some manufacturers that like to ship their own web browsers and those don't always have standards that are up to what we expect. There are polyfills. >> Okay. >> That can polyfill in WebAssembly. >> Okay. >> So, it will be compatible with those as well. >> All right. So, you mentioned like modern browser, so is that like Edge, Safari, Chrome? All of their latest bits will support WebAssembly? >> Yeah. So when we say something like an evergreen browser, that's one that doesn't have a hard version number. >> Right. >> That we're tracking. >> It auto updates from [inaudible] >> For example, like IE 7/8/9. >> Right. >> Or Edge. You're always on the latest version. >> Okay. So, Apple is on-board with this. Okay. >> Edge, Safari. >> Yeah. >> Chrome, Firefox. The big ones that many of the users use, those are the ones that you'd expect to have the native use of WebAssembly. Then the other ones like I said, the polyfill works. >> Right. >> There's a little bit of a performance gap obviously with that type of approach, but at least your app works. >> Okay. All right. >> So, this is where Blazor enters, the picture. Now, there's a couple of modes of how Blazor can run. One of those is very new. So, we'll talk about that in just a little bit. But, what I want to focus on right now is the experience where you're developing for the browser, the client and you're running the application on the client. >> Okay. >> There is an opportunity to run it on the server, and this diagram doesn't quite fit that model. So, right now we're talking client side. >> Why Blazor? What's with the name? >> So, the Blazor name came from Razor. So, we're going to use Razor to create our markup for application, and then the Blazor part of it comes from the- >> Is running it in the browser? >> Yeah, in the browser. >> Okay. >> So, browser, Razor, Blazor. >> I see. Okay. So, like Razor is the syntax that we use to build ASP.NET applications, be it MVC or ASP.NET Core. You're saying we're going to use the same syntax, but it's going to just run try inside in the browser? >> Yes. So, if we look at the diagram here what happens is, remember that model we had before we're going to feed the browser HTML and JavaScript only, now we're using the Blazor framework, and the Blazor framework, it renders those Razor CSS HTML files. Those get turned into HTML, which the browser understands. >> Okay. >> Then we take Mono. So, Mono the runtime that can target multiple platforms, there are now targeting the browser. >> Okay. So this is Mono under the covers, and I mean Mono has been known that is not a new thing. I mean Mono has been around since .NET has been around. So it's the port of .NET to other platforms, and that's how Xamarin apps run today on iOS, Android, and other platforms. So, you're saying, we will use Mono to bring your C# down to WebAssembly? >> Yes. >> Okay. >> So, Mono is compiled to run on WebAssembly, and then Blazor is a framework that sits on top of that. Now Blazor is able to take, and load your DLLs directly into Mono, and Mono is running those in an interpreter into the browser. >> Okay. So, it's being interpreted at runtime now but eventually we might have a little more static compilation to make things a little more faster? >> Yeah. So right now, this is the way it's happening. I have spoken with Daniel Roth and there are ideas around maybe collapsing this stack at a final compilation stage, where all of your application gets compiled into WebAssembly directly. So, when it loads into the browser it's at native speeds, and there's nothing inhibiting that direct pipeline into the browser. The way this works now, this is a great development experience because when we compile we're compiling it to DLLs, and then Mono is handling that WebAssembly interpretation for us. So, the compilation time is very short. If we were to take our entire left application and compile it, that compilation time would take quite a bit of time, and our development process would be slow. >> Sure. >> So, this is a very fast way to iterate on an application and build it, and then in the future we may have that longer compilation to get the final package tightened up and ready to send down to our users. >> Okay. I see a blazor.js, and mono.js, what are those? >> So, those are intermediate layers for the browser to help do things like JS interrupts, so we have a JavaScript interrupt layer. So there are things that WebAssembly doesn't support yet. So, there might be times where we need to fall back on JavaScript, so we can actually talk to JavaScript from within WebAssembly. >> So, from .NET code, you're going to call JavaScript, and back and forth? >> Correct. >> Okay. >> So we can actually do that bidirectionally. We can call JavaScript modules and functions from within Blazor, and then we can also from JavaScript invoke .NET functions. >> Okay. >> So that's one reason those two JavaScript files are there. The other part is just loading the application hub. So, the mono.js takes and loads bootstraps up the the Blazor assemblies, and then Blazor has those interrupt layers, and communicates down through mono.js into those interrupts directly. >> Okay. >> So we've got a nice stack workflow here that we can build some pretty interesting applications already. Now it's worth saying that Blazor is an experimental project still. >> Sure, for now. >> We are in release 0.5.1 as of recording. The first 0.1 release was just in March. So it's only six months old, it's a baby. It's got a lot of growing to do. >> But I here it's come a long way. Its come in tooling. >> Quite a long way. They are making some good investments in producing this experiment, and it's nice to have this experimental phase because they're able to think outside the box, and do some creative experimentation with it, and not have to worry so much about breaking changes at the moment. >> Then the community gets to weigh in, we developers get to try it out and see what works, and where the pain points are. So, back on this diagram. I mean this is all client-side, right? >> This is absolutely all client-side, and Blazor it can run out of process. So we don't need to necessarily be tied to WebAssembly. We can do it on the server, and we'll get into a project. This is actually something that shipped in 0.5.1. >> It was very, very new. >> How we can run the framework on the server side. So we don't have to compile it down, and then send it into the Mono WebAssembly runtime. We can use the regular .NET runtime on the server, and then what we're going do is open up a signal or hub, and communicate across the hub to your browser, and do diffs between the browser and the updates that we need to send. We'll get into that more, we don't want to get too much going on. >> You'll mention going on. Let's lock in the client-side first. >> So client-side, we've got our Blazor framework, running on top of Mono, we're able to load DLLs directly into the browser. >> Okay. >> Which is something very new and unexpected. >> Well, it's curious if I might say. >> Yeah, we will pull up the network traffic here, and take a look and see. >> So what exactly are you shipping from the service side when you do Blazor apps? >> All of it. We are shipping DLLs down to the browser and the browser is able to understand how to run those DLLs, thanks to the Mono runtime. >> Okay. Hopefully, we're doing some work with linkers and some tree shaking. So we are shipping only what we need and the client-side. >> That is stuff that is in the works that's coming, yes. >> All right. >> So right now, we're shipping down full assemblies but soon we hope that Steve and his team will come up with a way to create smaller DLLs and ship those across the wire. >> All right. Let's hear this. >> So before we get started, we'll talk a little bit about the Blazor framework itself. It has a lot of those things you expect out of a single-page application framework or SPA framework. It has a virtual DOM. So DOM manipulation has very taxing effort. So things like jQuery that directly go in and modify, manipulate the document object model in the browser, those things are sometimes pretty inefficient. So, Blazor has its own shadow DOM similar to other SPA frameworks like Angular and React. >> This almost sounds like a very SPA client-side framework with some of the features like routing and layouts and dependency injection. >> So we interact with this virtual DOM and then Blazor does diffing between the actual DOM, and the virtual DOM. So it's only changing what it needs to change rather than repainting that entire DOM within the browser. >> Got you. >> So we have efficiency there, we have a component model. It's very Model-View-View-Model type thing. This is something that developers from other .NET frameworks would appreciate. Things like UWP, and WPF, and Silverlight. It's not identical, but it has some similar type of ceremony too. >> This is what we liked about Silverlight development. This is the ease of doing data binding and XAML tools, the ecosystem. If you're saying we can bring some of it back, then yes. Let's do it. >> We have some layout capabilities in there as well. Dependency Injection, none of the box. Something that we'd expect from a modern .NET framework. So, we have that as well. We have routing. This very easily follows that Razor Pages type of construct, where we can open up a page and have an at page attribute. We'll show some of that in a moment. Then, again, the JavaScript interrupt is part this as well. So, we'll show that too. >> Okay. >> So let's jump straight into Visual Studio. Now, I have some tooling that I have to install. If you want to install this tooling, you go to Blazor.net and just follow the step by step instructions there, and you'll have the same tooling that I'm showing now. >> Okay. >> So in Visual Studio, I have a file new project experience for this. I am going to click on the ASP.NET Core Web Application project template, and we'll just do "OK" here to spin up a new project. Notice I have three new projects in here. I have a Blazor, Razor ASP.NET Core hosted, and Blazor Server-side. So, let's dig into these really quick. >> So, before you do that, this has to be ASP.NET Core 2.1 release and forward? >> Yes. >> Okay. >> As of now. So, as of recording that's what it is. Visual Studio 15.7 or 8. >> Okay. >> Those instructions, again, are on Blazor.net. You'll find those there. They may be updated after this video airs. So make sure you keep an eye there, but you do need to install these. You are not going to come out of the box in your normal .NET Installation. So, our first project. Think of this Blazor app as a client-side only template. So, if you were to do this in, say, just normal JavaScript terms, it would be HTML, CSS, JavaScript. Static files you've run on your client only. Okay? So, now talk about server interaction. You can still have server interactions, but you do that through web APIs and things like that. They're not included in this project. >> Sure. >> The next one over is the Blazor ASP.NET Core hosted. I like to call this the full stack template. So this has the previous project template, but it also includes ASP.NET Core and some web API end points that we can hit. >> So that's like your backend then for your app? >> Yes, and ASP.NET is actually hosting the application as well. With the first example, you don't even really need a host. You just need somewhere to stick your files, and it's just stuff the browser understands, so it can pick it up and run it. >> Sure. >> Just like in HTML, JavaScript, CSS project you could put it on GitHub, Pages and host it there. >> Any FTP server can just put up to put down and run? >> Exactly, Azure storage. You can host your application from using that format. The second one here though, this actually ASP.NET Core hosting the application for you. It also has a web API endpoint for you to be able to hit, and it also has a concept of code sharing. Remember, we're using the same language now on the browser, client and the server. >> Yes. So, that's interesting. So, folks doing Node.js, we are used to doing like JavaScript front and back, and now we can do C# front and back essentially, right? >> Absolutely. >> Okay. >> So, that's where that one sits. This is a brand new project. So, this is where, I talked about it a little bit earlier, this is a server-side model. No web assembly involved, where the Blazor framework sits on the server as an application, and the server connects through web sockets down to the browser using signalR. >> Okay. >> Those packets with signalR are sent through a binary transfer. So, it's actually taking the diff from your updates, your interactions, and sending that up to the server, the server then processes the changes in Blazor, and then Blazor knows the diffs to make, sends that down the wire in a binary packet, and then the signalR client picks it up and replaces what it needs to in the browser. >> Interesting. >> So, it's a very interesting approach to doing this type of development. >> Yes. If you talking about like server-side now, you're in Node.js territory, and you can think about what this might mean for electron js apps maybe that run on the desktop, but we'll get to that. But this is interesting, that we can actually host Blazor outside of the web browser's process, and just do it all on the server or desktop. >> Yes. It's extending that UI thread across the wire instead of doing it right there in the browser, on the client. >> Sure. >> So, let's actually jump into this first Blazor template. So, we can actually show some code and how this stuff is structured. So, I'm going to spin this up, File, New Project. Looking at our solution explorer to see what we get. Some of these things may seem very familiar out of the box because they follow conventions that we already use in ASP.NET development. >> In particular, this looks familiar if you do any Blazor Pages. So, you don't have to Model-View-Controller pipeline, you'd have pages, and that's where you render things from. >> So, we'll start top down. We have our WW root. >> Okay. >> So, this is just like you would find normally, this is static resources for our application. >> Okay. >> We go to pages. Like you said, Blazor Pages, same idea here. We have all of the features of our application. People like to talk about apps and features now like we want to have, in this case, our component feature and our fetched data feature, and we can dive into those files here in just a moment. Then, our shared libraries, our shared views, same concept is ASP.NET. We have things like templates in our main layout and we can even have a view imports file to do those global using statements and bring in component libraries, and things like that. >> Okay. >> Another familiar concept is the startup in program.cs files that you find in .NET Core projects. Those are the things that bootstrap your application and configure dependency injection, and all those great things. >> Okay. >> So, let's give this guy a run. We'll get this started and kick it off in the browser, and then we'll go look at the code behind it and see how this works. >> So you're running how this in IS express, but you just said it may not need any of that. >> Yes. We don't really need to do all that. We could host this on GitHub Pages if we wanted to. These are all static files that we're using here. So, we get our Hello World app. We have a couple of features here, we have our counter component. We can click and increment a counter. >> You're not coming back to the server. >> So, no. There is no server. >> Okay. >> We're not doing any data transfer across anything right now. We have a fetched data, but it's all being handled locally. So, we're just grabbing a JSON file and just pumping the data into the application. So, we're grabbing that static JSON file. It's not coming from a web service or anything at this point. So, right now it looks like an average application, but let's see how it's built. So, let's dive into some of the features here. Let's open the counter component or the counter page. You'll notice right away the Blazor syntax. It's a .cshtml file and it uses very familiar conventions. >> It does, yes. >> At the very top, we have a router. So page is at the counter endpoint. So if we go to counter in a browser that's where we end up. >> That routing is built-in. >> No, routing is built into the framework. So, now we have just simple HTML here. We have our header tag, and then we have our current count. Then we're using Blazor here to display a value of currect count. >> Sure. >> We have a button to click, and then we have a event binding to the on-click event. Then we have a function block here that has our functionality for this page. So, there's our current count that's being bound up here, and we have our event handler for the increment. >> Okay. When you say at functions like that's C#, right? >> Yes. This is Blazor, and everything inside of this block is C# code. >> Yes, yes. >> So there's no JavaScript at all on this page. When we click the button, it invokes this increment count function and its data bound to this current count value. So that's the view that we see here when we click this button. So we're able to do that with very little code. There is no post backs going to the server, it's all being handled locally on the client in a very easy to understand fashion. >> Okay. So, if you go back to the browser for a second, so you said it has a Shadow DOM but there is a DOM out there. So, if you right click, you'll actually see HTML. >> Yeah, absolutely. >> Okay. >> So, those CSS HTML files are being rendered out into the browser. So, we use bootstrap rows, your links and your buttons and all those good things. Let's actually jump over to our network tab while we're in here and just do something interesting. Want to do Empty Cache and Reload. When this comes down across the wire, notice that we're actually sending DLL files from the server. >> Little scary. But it's here. Lets see. >> These all get loaded in through web assembly and our applications spins up and it's all client side. >> Okay. >> So, we're actually running these DLLs locally on the client. >> That's very interesting. You literally shipping .NET DLLs to the browser. >> Absolutely. >> We would figured out at runtime. If you look at the sizes, this is where you're saying it'll get better. Like we'll ship smaller and smaller as we go on. >> Yeah. Right now you can see that we're shipping the .netstandard dll and mscorlib, all these things as a whole across the wire. I would imagine, I'm not on the dev team just for clarification. But I've had discussions with Daniel Roth, the PM on the team and he's ultimate about making these things smaller and more compact when they go across the wire. >> Sure. >> So let's jump back into code again. We'll take a quick look at the fetch data. This is the view that, if we click ''Fetch Data'' here, we have a little bit of a grid showing some data that's coming in. The first thing I want to point out again, we have routing and then underneath routing we have this @inject declaration up here. >> All right. >> So, this is actually calling out to the dependency injection system and it's asking for the HTTP client that's registered independency injection. So that's going to get resolved and then down in the code of this page, you'll see we use that HTTP client to go to a file on local storage. >> Okay. So, you're not going anywhere, it's just a JSON that you are loading. But you could go across the network if you wanted to. >> Absolutely, we can make requests to the backend services and all those type of things, and we're doing it in a familiar .NET way. We're using HTTP client and doing a GetJsonAsync to pull in a object type of an array of weather forecasts. So, there's JSON binding that's happening automatically in here. So, we don't need to even worry about those type of things. >> Sure. >> Then there's our weather forecast object right there. So, we're getting these values and just mapping those values from the JSON into this object and then we iterate over those in the view. >> So at this point, would you say these are views or would you say these are components? >> So these are both actually. So we have the concept of a page here. We're using this app page directive with the routing, but I could actually come into my home or my index and let's wipe this component out for a moment, and I can come in here and type in counter. Notice that nice IntelliSense come up and we'll close that tag and I'll come back to my browser and refresh. Let's go home and wait for it to refresh. We're getting a message. I'm actually in debug modes. Let's actually run this a different way. Let's do a Ctrl F5. So we'll run without debugging. So we can refresh this experience. Now, remember this is an experimental project. >> Oh, I see. Okay. >> So, the debugging experience right now is little lackluster. There's some work being done to make debugging available in the browser. We can actually at current state, set breakpoints. >> In C#? >> In the browser, we can set breakpoints. We'll look at that in a few moments, because I don't want to get too off track. So, at some point, we'll be able to debug C# code in Chrome or IE. >> Wow. >> At current states not quite there, but it's getting there. So back to talking about the components. >> See you have the counter. >> Take that entire page, use it as a component. >> I see. That's not something you are able to do at all in ASP.NET, MVC, or Core, or Blazor. >> That is right.This is a new component model. >> It's literally a component. So, this is like in some ways like Angular and React, you just literally plopping a component down into a page. >> Absolutely. It's very similar concept to those things. You could say it was inspired by or borrowed from those. Which those things inspired by and borrowed from things like WPF. >> Absolutely. We rediscovered the same problem so and over again. >> So let's have a little fun with the counter component that we have. We'll go back to this page here and let's set up a property. So we actually have a shortcut for this now in the tooling and we can say instead of prop tab tab, which we might be used to do this, we can say parameter tab tab and now we get the Parameter attributes, and then we can expose a property on our component. Let's call this CountBy. So this is an integer that will set to be CountBy. Instead of just incrementing this internally, we can just say, plus equals CountBy. We might want to set a default value here. >> What if someone does not pass in the parameter? >> So we'll do that. >> Okay. >> I saved it. We'll go back to our index and now we can say count. I may have to recompile here. Let's do a build, and now we can do CountBy. There we go. >> Very interesting. >> Now are IntelliSense comes up, we need to build that library out. I can set that to an integer of five and we'll save this and we'll refresh our page. >> So, if I'm getting this right, so these are individual components? So the actual counter should still increment by one, but this one should pick up the parameter? >> Right. So, the instance of the counter on my index page, counts by five and the instance of the counter on the counter page is only counting by one. >> Sure. >> But now we've extended that component out and actually made it a little more robust where we can have a developer experience where you can type in and get IntelliSense and set variables and properties on the object or the component. >> This is very cool. >> So, very simple component model to understand and it's absolutely simple to get up and running. So, let's take a look at the other project type. >> So, that's the first half of a four hour of Sam and Eddie, talking about Blazor. The next episode of Visual Studio Toolbox, will continue on with their conversation.