Browser Link in ASP .NET Core

What is Browser Link?

Browser Link is a feature in Visual Studio that creates a communication channel between the development environment and one or more web browsers. You can use Browser Link to refresh your web application in several browsers at once, which is useful for cross-browser testing.

How Does It Work?

Browser Link uses SignalR to create a communication channel between Visual Studio and the browser. When Browser Link is enabled, Visual Studio acts as a SignalR server that multiple clients (browsers) can connect to. Browser Link also registers an HTTP module with ASP.NET. This module injects special <script> references into every page request from the server. You can see the script references by selecting “View source” in the browser.

https://docs.microsoft.com/en-us/aspnet/visual-studio/overview/2013/using-browser-link/_static/image13.png

Your source files are not modified. The HTTP module injects the script references dynamically.

Because the browser-side code is all JavaScript, it works on all browsers that SignalR supports, without requiring any browser plug-in.

Earlier Discussion

We discussed about the browser link in .Net Framework earlier.

Take a look at here:

Browser Link option in Visual Studio

BrowserLink in ASP .NET Core

To use BrowserLink in ASP .NET Core, we should do few tweaks in the source code.

Install the following package in your project

Microsoft.VisualStudio.Web.BrowserLink

Or using packet manager

Install-Package Microsoft.VisualStudio.Web.BrowserLink -Version 2.2.0

And config BrowserLink in your startup.cs

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseBrowserLink();
}

Start using

Now start using the BrowserLink from the tool bar dashboard

Happy Coding!

What’s new in ASP.NET Core 2.2 – Web API improvements – API Analyzer

In the past post, we discussed the Web Improvements that have been released in the ASP.NET Core 2.2 preview. We have discussed how the creation, testing, and documentation of API has been improved in the ASP.NET Core release. Using Swagger gen, we created API documentation and also able to test our API application from the UI itself. On successful HTTP action, we usually get 200 status code and response from the API.
ASP.NET Core provides custom error response by default from 2.2 release. The error response includes TraceId to correlate to other response easily,
In the earlier post, we use SwashBuckle to generate swagger UI, but it isn’t able to determine all the possible response type of an HTTP method. For example, a post method can return 200, 400, 500 kinds of responses based on different input. Our documentation should cover most of the possible response type available in our API.
[ProducesResponseType(StatusCodes.Status400BadRequest)]
We shall specify the possible response type of each method in our Controller which will generate related documentation in the Swagger UI. But it will be a tedious process to analyze and add all the methods in our API. For this, ASP.NET Core 2.2 shipped an API Analyzer that will analyze the API actions and provide code fix that can be added in the code. We shall the package “Microsoft.AspNetCore.Mvc.Api.Analyzers” from Nuget Package manager
Once added API analyzer in our project, the analyzer starts showing the possible response type suggestion in warning window.
Instead of providing mentioning each response type on every action, we shall globally enable the API convention type with default conventions like below

[assembly: ApiConventionType(typeof(DefaultApiConventions))]
namespace APITest.Controllers
{
  ....
}
These DefaultApiConventions can also be extended and defined separately based on our needs. DefaultApiConventions covers some basic commonly used convention types in APIs.
using Microsoft.AspNetCore.Mvc.ApiExplorer;
namespace Microsoft.AspNetCore.Mvc
{
public static class DefaultApiConventions
{
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
[ProducesDefaultResponseType]
[ProducesResponseType(201)]
[ProducesResponseType(400)]
public static void Create([ApiConventionNameMatch(ApiConventionNameMatchBehavior.Any)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object model);
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
[ProducesDefaultResponseType]
[ProducesResponseType(200)]
[ProducesResponseType(404)]
[ProducesResponseType(400)]
public static void Delete([ApiConventionNameMatch(ApiConventionNameMatchBehavior.Suffix)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object id);
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
[ProducesDefaultResponseType]
[ProducesResponseType(204)]
[ProducesResponseType(404)]
[ProducesResponseType(400)]
public static void Edit([ApiConventionNameMatch(ApiConventionNameMatchBehavior.Suffix)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object id, [ApiConventionNameMatch(ApiConventionNameMatchBehavior.Any)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object model);
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
[ProducesDefaultResponseType]
[ProducesResponseType(200)]
[ProducesResponseType(404)]
public static void Find([ApiConventionNameMatch(ApiConventionNameMatchBehavior.Suffix)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object id);
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
[ProducesDefaultResponseType]
[ProducesResponseType(200)]
[ProducesResponseType(404)]
public static void Get([ApiConventionNameMatch(ApiConventionNameMatchBehavior.Suffix)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object id);
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
[ProducesDefaultResponseType]
[ProducesResponseType(201)]
[ProducesResponseType(400)]
public static void Post([ApiConventionNameMatch(ApiConventionNameMatchBehavior.Any)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object model);
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
[ProducesDefaultResponseType]
[ProducesResponseType(204)]
[ProducesResponseType(404)]
[ProducesResponseType(400)]
public static void Put([ApiConventionNameMatch(ApiConventionNameMatchBehavior.Suffix)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object id, [ApiConventionNameMatch(ApiConventionNameMatchBehavior.Any)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object model);
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
[ProducesDefaultResponseType]
[ProducesResponseType(204)]
[ProducesResponseType(404)]
[ProducesResponseType(400)]
public static void Update([ApiConventionNameMatch(ApiConventionNameMatchBehavior.Suffix)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object id, [ApiConventionNameMatch(ApiConventionNameMatchBehavior.Any)][ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] object model);
}
}
Based API conventions, now the swagger UI generates documentation of various response types and its sample inputs.
Documentation and testing become simpler in ASP.Net Core 2.2. Please try out for your API code, and leave your feedback in comment section. Happy Coding!