Let’s cut to the chase: the latest Rider 2019.1 EAP build supports running ASP.NET Core apps in IIS Express! There’s
launchSettings.json support for IIS Express. We’ve added a settings page to help verify IIS Express is installed, including prerequisites. Oh, and we also check whether a trusted developer SSL certificate has been set up, and allow generating a self-signed certificate in case it isn’t.
After creating a new ASP.NET Core project or loading an existing one that has a
launchSettings.json file with an IIS Express profile, Rider auto-imports it as a Run configuration.
That’s… it. Do read on if you would like to learn more – we’ll cover some details and additional configuration options that are available.
DOWNLOAD RIDER 2019.1 EAP
We spent last month scrambling to prepare some great new goodies for you. Please welcome the Rider 2019.1 Early Access Program!
The highlights of this first EAP build include:
Posted in How-To's
Tagged angularjs, C#, debugger, F#, performance, publish, refactoring, Rider, TypeScript, unit testing, Unity, Xamarin
We are continuing our series on testing ASP.NET Core Web API projects using Rider. We will be using the HTTP Client built into Rider’s IDE that will allow us to build the calls to our REST APIs developed in ASP.NET Core Web API.
In this part, we will look at executing the HTTP Client scripts and examining the results of the responses. We will be testing the GET, POST, PUT and DELETE HTTP request verbs. We will also look at how we can compare the history of the responses that have taken place against our APIs over time.
In this series:
There are many different ways to test Web API’s developed using ASP.NET Core. Let’s look at how we can cover testing and profiling our APIs inside Rider. We will be using the HTTP Client built into Rider’s IDE that will allow us to build the calls to our REST APIs developed in ASP.NET Core Web API.
In this first part of a two-part series, we will begin with creating and composing the scripts for our HTTP requests against an ASP.NET Core Web API solution. We will be testing the GET, POST, PUT and DELETE HTTP request verbs. In part two of the series, we will look at executing the HTTP requests and analyzing the responses.
In this series:
There are many users of Rider that value the IDE for developing .NET Core applications on macOS. They also have need of running their Microsoft SQL Server databases locally for their work. This blog post will give developers insight on how to create SQL Server containers with Docker, and how to work with them in Rider. The best thing about working with Docker is that it is supported in many of our IDE’s – including DataGrip! Continue reading
Today it is time to introduce you the new bug-fix update for 2018.3 releases of both ReSharper Ultimate and Rider.
ReSharper Ultimate 2018.3.4 fixes some critical issues which prevented using ReSharper in the Visual Studio 2019 Release Candidate build:
- Both ReSharper and Visual Studio code completion popups appeared at the same time RSRP-473453.
- The “New project” wizard was broken RSRP-472852.
Rider 2018.3.4 fixes the wrong URL for the Help | Contact Support action (RIDER-24391) and gets all the fixes from our IntelliJ Platform.
Last time, we looked at Rider’s new performance indicators for Unity, which highlight expensive operations inside performance critical contexts, such as calling
GetComponent inside an
These highlights are intentionally different to traditional warnings and suggestions because there is no easy “fix”, partly because the code isn’t necessarily wrong, but also because removing an expensive operation requires either changing the semantics of your code, or rearchitecting parts of your application (e.g. avoiding the use of
SendMessage completely). These indicators provide context and awareness, and it’s up to you (and your profiler) to decide how, when and even if you want to address the advice.
Of course, there are always code patterns that can be easily and safely rewritten to perform better simply by using a different API or overload, or by caching values. In this post, we’ll take a look at some of these inspections and the Quick Fixes you can use to follow Unity’s own best practices and avoid some common performance issues in Unity.
We have all experienced bugs that throw exceptions in our applications. Using ASP.NET and getting a “yellow screen of death” (YSOD) with an exception message and stack trace? Using .NET Core and seeing stack traces printed to log files?
With ReSharper and Rider, we can explore and navigate stack traces from these exceptions better within the IDE. Let’s take a look at using the Stack Trace Explorer!
At JetBrains, we’re big fans of static analysis. Rider has over 1,200 inspections designed to warn about potential issues, or suggest changes, nearly all with quick-fixes to address the problem. Some are about consistency, such as naming standards and code style. Others warn about redundant, unused, or unnecessary code, or help you write terser, more modern code, making use of new language features. And of course, Rider will warn you about code quality issues, such as potential null-reference exceptions or other runtime issues like infinite loops.
Rider even has some Unity specific inspections and quick-fixes – such as warning about ambiguous usage of the
?. operators on Unity objects, incorrect method signatures for Unity’s magic methods, and so on.
But wouldn’t it be nice if Rider could help with the one thing that all Unity developers care about – performance? Surprise! Of course it can!