Swagger and Swashbuckle: Disable Try It Out

In last week’s post, I walked through adding Swagger support to an ASP.NET Core 2 API using the Swashbuckle. One of the awesome things about Swashbuckle is it provides an integration with swagger-ui.

Try it out!

One of the features of the UI integration is the ability to invoke an end point using the “Try it out!” button. This feature is awesome during development but may not be something you want to allow, depending on the use case, for a production end point.

Disable Try it out!

I tried googling lots of different things to find the option to disable the “Try it out” button and had a really hard time finding an answer. It didn’t help that I want the button text to be “Try it now” for some reason. Thankfully it truly was a failure on my part and there is a provided way to disable “Try it out” and it is much more flex able than what I was initially looking for.

In the  Configure function of the  Startup class find the call to  app.UseSwaggerUI. Adding  c.SupportedSubmitMethods(new string[] {}); will completely disable “Try it out”. The following is the full call to  app.UseSwaggerUI just to provide context.

The great thing about the way this is set up if you can allow some actions and not others. For example, say you wanted to allow get actions but disable the rest. The following would allow for that.

One word of caution the above is case sensitive and if you use  Get instead of  get “Try it out” will remain disabled.

Swagger and Swashbuckle with ASP.NET Core 2

This post is going to be very similar to a post from last December which can be found here. A lot has changed since then and this post is going to add Swagger to an existing ASP.NET Core application using Swashbuckle much like the one from last year. The starting point of the code can be found here.

What is Swagger?

Swagger is a specification used to document an API. As I am sure we all know API documentation tends to get out of date fast and a lot of times is a low priority.  Swagger aims to help solve that problem using a format that is both human and machine readable which can be maintained in either JSON or YAML. The documentation can be auto generated using a tool like Swashbuckle which provides away to keep your consumers up to date. Check out this post by the Swagger team for the full introduction.

What is Swashbuckle?

Swashbuckle provides auto generation of Swagger 2.0, a UI, etc. The project takes all the pain out of getting going with Swagger as well as providing tools and hooks for using and customizing Swagger related items. The full description can be found here.

Adding Swashbuckle

Using your favorite method of NuGet interaction, add the  Swashbuckle.AspNetCore NuGet package to your project. Personally, I have gotten where I edit the csproj file to add new packages. If that is your style you would need to add the following package reference.

This one package provides all the functionality we will need.

Wiring up Swashbuckle

Now that the Swashbuckle package is installed, there are a few changes that are needed in the  Startup class to get everything wired up. First, in the  ConfigureServices function, the Swagger generator needs to be added to DI.

AddSwaggerGen allows for configuration of options, but here we are just setting a name and a minimal amount of information.

In the  Configure function Swagger needs to be added to the request pipeline in order to expose the Swagger generated data. I placed this after  UseMvc.

At this point, the Swagger generated JSON would be available at  {yourBaseUrl}/swagger/v1/swagger.json. To take a step further let’s expose the UI that comes with Swashbuckle. Add the following just below  app.UseSwagger().

Now a UI based on your API is available at  {yourBaseUrl}/swagger with zero extra work on your part. The following is the UI for the post contact route in the example project.

As you can see the UI provides a great view of your API as well as ways to try it out and the potential responses that should be expected from a call.

Controller Considerations

All of this wonderful functionality doesn’t come for free of course. In order for Swashbuckle to pick up your routes, your controller will need to use attribute based routing instead of depending on convention based routing.

In order for Swashbuckle to know the return types and of your controller actions may need to have some attributes added. This won’t be required if your action return a specific type, but if you are returning an  IActionResult you should attribute your action with all the  ProducesResponseType you need to cover the results of your action. For example, the following is the action definition for the Post in the screen shot above.

Wrapping up

Swashbuckle makes it easy to add Swagger to a project. I feel that it also provides a huge value for anyone trying to consume an API. It is of course not a magic bullet and communication with your API consumers about API changes will still be critical.

Microsoft’s docs have a great walk through which can be found here. It does more in-depth on customizing your setup and as far as modifying the look of the UI. I also recommend checking out the GitHub page for the project which can be found here.

The finished code can be found here.

NDepend Spotlight

Today I am going to be doing a tool spotlight on NDepend. NDepend has a ton of features to help you keep a handle on your applications including the following plus much more.

  • Code Rules
    • 200 default rules with ability to add custom rules using LINQ
  • Quality Gates
  • Visual Studio Integration
  • Build Process Integration
  • Dependency Graph
  • Dependency Matrix
  • Technical Debit Estimation

For full disclosure, NDepend reached out to me to give their tool a try. I am writing based on my experiences with their tool and will be including both the positive and negative aspects of my experience. None of the links in this post are referrals that would in any way provide me any sort of payment.

Installation

The download is a zip file that you then have to find out what you want to do with. This was the first negative I hit with the product. While it isn’t hard to figure out it would be much nicer if this were an installer where I could select what I wanted to install instead of having to look at the getting started docs right away. For non-build usage, the options to run the tool is either via a Visual Studio extension (NDepend.VisualStudioExtension.Installer) or as a stand alone application (VisualNDepend.exe).

I chose to go explore with the Visual Studio extension. As a hint that I didn’t notice until later, VisualNDepend provides an option to install the Visual Studio extension in addition to providing all the functionality of the Visual Studio extension.

Visual Studio Extention

After installing the NDepend extension there will be a new top level NDepend menu in Visual Studio.

With the solution you want to analyze already open select the NDepend > Attach New NDepend Project to Current VS Solution.

This will launch a dialog that allows you to select which assemblies you would like to analyze preloaded with the assemblies for the current application.

As you can see from the dialog there are a lot of options. If your project has other assemblies or solutions that you would like to be included as part of the analyses they are easy to add. When finished adding items to analyze click the Analyze button at the bottom. I am using a small project for this entry and the process took less than 10 seconds. I also tried it on a large project (500k+ lines of code) and it took less than 30 seconds.

After the analyses are complete the extension shows a dialog asking what to do next as well as launching a web page with the results of the analyses if you kept the Build Report check box checked. Following are the options in the dialog.

From here I chose to View NDepend Dashboard, but also make sure and check out the report that the analyses generated as it provides a great summary at the end of all the issues found. The following is a part of the dashboard.

There is a ton of data provided. If you notice at the top there is a Choose Baseline option which would allow comparisons of solutions over time. I can see this view of a project over time is very helpful, but not a feature I will get to explore here.

Exploration

Exploration of the data NDepend provides is something I could spend hours looking at even on a small project. For example, the following is an output to HTML (their output is much prettier than the version that is shown here) of the issues that make up the critical group in the Rules box in the dashboard above.

4 rules Issues Debt Annual Interest Breaking Point Category Full Name
Avoid methods with too many parameters 1 issue 1h 9min 5min 4 522d Project Rules \ Code Smells Rule
Avoid non-readonly static fields 12 issues 32min 4h 0min 48d Project Rules \ Immutability Rule
Avoid namespaces mutually dependent 2 issues 30min 1h 1min 179d Project Rules \ Architecture Rule
Avoid having different types with same name 3 issues 30min 1h 0min 182d Project Rules \ Naming Conventions Rule
Sum: 18 2h 41min 6h 6min 4 933d
Average: 4.5 40min 1h 31min 1 233d
Minimum: 1 30min 5min 48d
Maximum: 12 1h 9min 4h 0min 4 522d
Standard deviation: 4.39 16min 1h 28min 1 899d
Variance: 19.25 34d 979d overflow

Here is the same view inside the Queries and Rules Edit window.

Double click any line will take you to a detail view showing a listing of the rule broken down by project, namespace, and class.

The same window also shows the query that was used to find the rule violations. For example, the above is powered by the following query.

The above is CQLinq or Code Query LINQ which is used to query the code model that the NDepend analysis creates. The detail of CQLinq are outside the scope of this post, but based on the above you can see how powerfully this could be.

Other considerations

Based on my usage to get the best value from NDepend your whole team would need to be licensed and making sure new code satisfies with all the rules your team wishes to follow. NDepend has a component that can be used as part of server based build processes which is needed, but I would want to use that component as a fail safe, not as a way to avoid buying licenses. If you use multiple computers it seems that you will need multiple licenses which will cause issues for some users.

Wrapping up

After trying NDepend out for awhile I am still amazed at the amount of data it provides. Not to mention the ability to add new queries and rules of your own. One blog post is never going to be enough to cover even a fraction of what this tool does. It feels like Resharper in it does so much that it takes a lot of time to learn and take advantage of the full set of features it provides.

Swagger and Swashbuckle with ASP.NET Core API

This post is going to walk through adding Swagger to an existing ASP.NET Core API application using Swashbuckle. The starting point for the code can be found here.

What is Swagger?

Swagger is a specification on documentation an API. As I am sure we all know API documentation tends to get out of date fast and a lot of times is a low priority.  Swagger aims to help solve that problem using a format that is both human and machine readable which can be maintained in either JSON or YAML and can be auto generated using a tool like Swashbuckle. Check out this post by the Swagger team for the full introduction.

What is Swashbuckle?

Swashbuckle provides auto generation of Swagger 2.0, swagger-ui integration, etc. The project takes all the pain out of getting going with Swagger as well as providing tools and hooks for using and customizing Swagger related items. The full description can be found here.

Adding Swashbuckle to the project

There are lots of ways to get a new package into an ASP.NET Core application and the following covers the NuGet UI, Package Manager Console and Project.json. Pick one of them to use.

NuGet UI

Right click on the project Swashbuckle is going to be added to, Contacts in the case of the sample code, and select Manage NuGet Packages.

swashbuckleprojectmenu

Select the Browse tab, check the Include prerelease checkbox and search for Swashbuckle. Prerelease is need to get the version that works with ASP.NET Core.

swashbucklenuget

Finally click the Install button and work though any confirmation dialog screens that might show.

Package manager console

From the package manager console run  Install-Package Swashbuckle -Pre.

Project.json

Open porject.json and in the  dependencies section add  "Swashbuckle": "6.0.0-beta902".

Add and configure Swashbuckle

In the  ConfigureServices function of the  Startup class add the following. I added it as the end, but placement shouldn’t matter.

Next in the  Configure function after  app.UseMvc add the following.

The first line enable serving of the Swagger JSON endpoint and the second enables the swagger-ui.

Test it out

Running the application will now provide two new routes one or each of the items added to the  Configure function above.

The first is  http://localhost:13322/swagger/v1/swagger.json (your base URL may differ if not using the sample procject) and it exposes the Swagger compliant JSON.

The second URL is  http://localhost:13322/swagger/ui and it provides a very readable view of the documented API along with examples and options to try the API out. The following as an example of what the current version outputs.

swaggeruiexample

Wrapping up

Swashbuckle make it easy to add Swagger to a project. I feel that it also provides a huge value for anyone trying to consume an API. It is of course not a magic bullet and communication with your API consumers about API changes will still be critical.

Microsoft’s docs has a great walk through which can be found here. It does more in-depth on customizing your setup and as far as modifying the look of the UI.

The code for this post in it’s finished state can be found here.

Tool Spotlight – Add New File and Open Command Line Visual Studio Extentions

Tool Spotlight is a new type of post that I am trying out to bring attention to tools that I find useful and worth sharing. These entries will not be on any sort of schedule and will get posted anytime I come across a tool worth mentioning.

This post is going to cover two Visual Studio extensions that I find very helpful especially in the context of writing ASP.NET Core applications. Both of today’s extensions were written by Mads Kristensen.

 Add New File

The Add New File extension provides a simple way of adding new files without having to go through Visual Studio’s add new item dialog. Visual Studio’s dialog is great when I need it, but a lot of times I am adding a html or JavaScript file and just want a blank file and this extension provides a mechanism to do just that.

Lets look at the difference in the two dialogs. Here is Visual Studio’s dialog:

defaultAddNewFile

And here is what the add new file’s dialog looks like:

addNewFile

As you can see the extension’s dialog is much simpler. After the extension is install simply hit Shift+F2 to show the above dialog, enter a file name and click Add file to create a file in the current directory. Directories will also be crated as needed.

Open Command Line

The Open Command Line extension provides a way to open a console from within Visual Studio. The default console application is configurable with options from cmd and PowerShell to cmder and custom user defined applications. Opening the default console to the current directory of the selected item in Visual Studio’s solution explorer can be triggered using the Alt+Space shortcut. The extension also adds an Open Command Line option to the right click menu in solution explorer.

openCommandLineRightClick

Thoughts and Suggestions

Leave any thoughts on if this sort of post is helpful, your favorite tools or suggestions for future topics in the comments.