TL;DR here is a demo repository https://github.com/olsh/mvc5-custom-error-pages-example

There are many posts on the internet how to set up the custom error pages in ASP.NET MVC and IIS. However, some of them doesn’t cover all errors or suggest to have two files for each custom page (html and aspx). Some articles use client redirect, which is not suitable for SEO. In this short note, we set up custom errors without code duplication, and all cases will be covered.

First, we need to create aspx pages for 404 and 500 errors; let’s keep them simple. We use aspx because we need to override customErrors status code, for some reason it sets it to 200 (OK), also both customErrors and httpErrors don’t work with cshtml.

Remove HandleErrorAttribute. We don’t want to use it because it doesn’t support aspx files.

Add customErrors to web.config file, this config is responsible for handling errors which occurred in .NET stack

Add httpErrors to web.config, this one is needed for errors outside .NET stack (for example static files)

Set .NET Framework version to 4.6.2 or higher. This step is important. Otherwise, custom errors won’t work if a URL contains whitespace.

That’s it!

Here is a demo project https://github.com/olsh/mvc5-custom-error-pages-example
The configuration was tested on .NET Framework 4.6.2 and IIS 8.5/10.

If you found a mistake or the configuration doesn’t work for you, please let me know.

Recently we switched from TFS to Jira and TeamCity. We used to generate release notes with the Octopus extension, and it has release notes generation feature out of the box. Sadly, the TeamCity plugin does not have the feature, and the Octopus team said that they are not going to implement it. Starting from Octopus 2019.4 the official TeamCity plugin supports the metadata generation.

However, the Octopus support sent the link to the excellent article which shows how you can generate the release notes with commits using PowerShell. However, the script doesn’t fit our needs, because we wanted to include linked tasks too, so I extended the script.

The extended script grabs all the changes from a TeamCity build and tries to retrieve the tasks’ information from Jira and generates a markdown file with release notes. After that, you can publish the generated file to the Octopus server with octo.exe or TeamCity plugin. I’ve also created a TeamCity meta-runner which you can use as a build step in TeamCity. The source code is available here. The script was tested on Jira 7 and TeamCity 2018.1

Hope this script will be useful for someone else.

1. Install Snyk CLI

   npm install -g snyk
   

2. Copy your API token and add a new environment variable with the name SNYK_TOKEN, you can find it on the account page
3. Build the testing solution
4. Run monitor command to detect vulnerabilities where org parameter is your organization name, you can find it on the settings page.

   snyk monitor --org=olsh --file=YourSolution.sln
   

5. At the moment of writing, the is an issue with scanning directories with multiple package file types so you should execute monitor command for each project which contains package.json or other package type and specify obj directories as arguments.

   snyk monitor --org=olsh youproject/obj yourproject2/obg
   

That’s it. Go to your Snyk dashboard and check found vulnerabilities.
You can also execute these steps on CI server to continuously test your projects, here is an example of a cake script which runs on AppVeryor on each commit and sends the analysis to snyk.

In the latest version of SonarQube new fantastic feature was introduced, so-called external analyzers. The quote from the official site:

SonarQube 7.2 introduces a generic way to import issues found by 3rd-party analyzers. No need to jump from one tool to another, just benefit from a consolidated view in SonarQube. Even better: SonarQube has built-in support for some of the standard analyzers out there.

At the moment of writing, only TypeScript plugin has out of the box support of the feature. Fortunately, there is generic issue data format, which allows importing issues from any analyzer. ReSharper in its turn has a free command-line tool Inspect Code which can analyze projects and produce a report in XML format, so all we have to do is to convert ReSharper format to SonarQube format.

Generate ReSharper report part is simple, just run the Inspect Code tool against your solution:

InspectCode YouSolution.sln --swea -s=INFO -o=ReSharperReport.xml

For the next step, I wrote a small .NET core global tool which can convert ReSharper report to SonarQube format. First, you need to install dotnet-reqube with the following command.

dotnet tool install --global dotnet-reqube

and do the conversion:

dotnet-reqube -i ReSharperReport.xml -o SonarQubeReport.json -d YouSolutionDirectory

Then, you need to run Sonar Scanner as usual but with the additional parameter /d:sonar.externalIssuesReportPaths=SonarQubeReport.json where JSON file is the -o parameter that you pass to dotnet-reqube.

That’s it after the analysis is complete, you can see issues detected by ReSharper in SonarQube interface.

ReSharper issues will be marked with R# label.

Please note that external issues have some limitations:

• they cannot be managed within SonarQube; for instance, there is no ability to mark them False Positive.
• the activation of the rules that raise these issues cannot be managed within SonarQube. In fact, external rules are not visible in the Rules page or reflected in any Quality Profile.

I’ve created the example project with a Cake script which do all these steps automatically.

If you have any problems with the integration, please open an issue on GitHub.