In this post I will show you how to integrate an OWIN project with Angular CLI project.
Below are the pre-requisites:
After the project is successfully created, add new "cs" file and name it as Startup.cs and delete "Global.asax" file.
Add the below NuGet packages and it's dependencies into your project:
Now in the Startup.cs file, please add the below code.
Now modify the web.config as shown below
We are done with the Owin project, so now let's create the Angular CLI project.
I am creating the Angular project inside directory "AngularProject" and overall structure of Owin and Angular is as shown below
Now open powershell and browse to parent directory of AngularProject i.e. in my case its "c:\git". Now execute the below command
Once the Angular CLI project is created successfully, open ".angular-cli.json" and modify the outdir file location to the App folder which we created in the owin project.
Now build the angular project using "ng build -ec" and you will notice that all the build files are copied into App folder.
Now run the Owin project which we created and you will see the index.html of Angular project got rendered using owin.
Hope you enjoyed reading!!!!
Finally Snapshot Debugger tool is now ready for the Production, it’s a tool that enables you to debug web apps running in production in Azure. With the latest Visual Studio 2017 Enterprise 15.5 you can make use of that tool.
I am sure many developers might have come across a scenario in which it’s very tough to debug an application and that’s the reason we use logs. But many times digging logs is very tough and painful and many times you won’t be able to reproduce the issue in Local Environment. Snapshot Debugger comes as a saviour in such scenario. The Snapshot Debugger enables a safe, non-invasive way for you to use the Visual Studio debugger you know and love directly against the production environment in Azure where the issue is happening.
Just like in memory profiler we take the snapshot of the particular state of our application, Snapshot Debugger works very much similarly. Here Snapshot debugger takes a snapshot of the state of your app at specified lines of code where you set Snappoints. While traditional breakpoints would halt your live server when hit and stop it from serving requests; Snappoints quickly capture state, including locals, watches, and the call stack while your app continues to run. This means that you can debug the actual live, running app, without impacting the experience your customers have while using the app.
Below is the GIF file which Microsoft released showing how to use Snappoints.
Best part of Snapshot debugging is that, it has no performance impact on the application
Behind the Scene
As per Microsoft, Snapshot debugger intelligently captures state where you have pin pointed your snappoints. When snappoint is placed Debugger forks your app’s process and suspends the forked copy, creating a snapshot. You then debug against this snapshot, which sits in-memory on your server. The snapshot is not a copy of the full heap of the app – it’s only a copy of the page table with pages set to copy-on-write. The Snapshot Debugger only makes copies of pages in your app if the page gets modified, minimizing the memory impact on your server. In total, your app will only slow down by 10-30 milliseconds when creating snapshots.
You can try out Snapshot debugger in Visual Studio 2017 Enterprise version 15.5 and greater. Currently, the Snapshot Debugger supports ASP.NET and ASP.NET Core apps running in Azure App Services. For more details you can read at official visual studio blog.