Rider 2020.1.3 and ReSharper Ultimate 2020.1.3 Bugfixes Are Here!

We’ve published a couple of bugfixes a moment ago: Rider 2020.1.3 and ReSharper Ultimate 2020.1.3 are ready for you to download. Here’s how we made each tool a tiny bit better.

ReSharper Ultimate 2020.1.3

In this build, you will find the following most important things we’ve managed to fix:

  • When using nullable reference types, you have two fewer things to worry about (RSRP-478846, RSRP-477755).
  • Solution Wide Error Analysis (SWEA) now starts as normal on some projects on which it used to hang forever.

Rider 2020.1.3

  • The code editor no longer auto-scrolls when you type (RIDER-44278).
  • Nodes in the unit test sessions tree are updated correctly after the session tree is expanded (RIDER-44326).
  • A couple of fixes in the support for nullable reference types (RSRP-478846, RSRP-477755).
  • Code assistance in F# script files (.fsx) works again on macOS and Linux (RIDER-42925).
  • The scrolling and selection issue for the Local History diff is finally fixed for partial classes, as well (RIDER-42981).

Check out the full list of fixes here.

You can download Rider 2020.1.3 and ReSharper Ultimate 2020.1.3 from our website or update either using the Toolbox App. You can also update Rider as a snap.

This entry was posted in Releases and tagged , , , , , . Bookmark the permalink.

3 Responses to Rider 2020.1.3 and ReSharper Ultimate 2020.1.3 Bugfixes Are Here!

  1. Fernando says:

    Very often when we run unit tests or coverage in VS using Resharper, after all the tests are done, the “Unit tests sessions” keeps working forever, and there is a CPU continuous usage for JetBrains.dotCover.WorkspaceHost.exe. It is even impossible to abort the execution of the tests from within “Unit tests sessions”.

    This is happening in at least two different computers since we updated to the latest Resharper (for me, it was also happening in 2020.1.2).
    And this prevents us from running unit test at all with Resharper, or using continuous coverage.

    Based on the name of that process, it could be that the SWEA issue is not fully fixed?

    Stacktrace:

    0, CORINFO_HELP_CHECKED_ASSIGN_REF <– clr.dll+0x3f80
    1, System.Text.StringBuilder.MakeRoom(Int32, Int32, System.Text.StringBuilder ByRef, Int32 ByRef, Boolean) + 0x6d <– mscorlib.ni.dll+0x59af2d
    2, System.Text.StringBuilder.Insert(Int32, Char*, Int32) + 0x54 <– mscorlib.ni.dll+0x59ae94
    3, JetBrains.ReSharper.TaskRunnerFramework.UnitTestPersistentElementIdEx.FromString(System.String) + 0xe4 <– 0x7ffbe7d18514
    4, System.Linq.Enumerable+WhereSelectListIterator2[[System.__Canon, mscorlib],[System.__Canon, mscorlib]].MoveNext() + 0x74 <-- System.Core.ni.dll+0x348c44
    5, System.Linq.Buffer
    1[[System.__Canon, mscorlib]]..ctor(System.Collections.Generic.IEnumerable1) + 0x102 <-- System.Core.ni.dll+0x3433a2
    6, System.Linq.Enumerable.ToArray[[System.__Canon, mscorlib]](System.Collections.Generic.IEnumerable
    1) + 0x5d <– System.Core.ni.dll+0x33fc4d
    7, System.Linq.Enumerable.ToDictionary[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.Collections.Generic.IEnumerable1, System.Func2, System.Func2, System.Collections.Generic.IEqualityComparer1) + 0x10e <– System.Core.ni.dll+0x34283e
    8, JetBrains.dotCover.WorkspaceHost.Backend.RdProtocolSkeletons.UnitTesting.UnitTestSessionsManagerSkeleton.ProcessSnapshotsHandler(JetBrains.Lifetimes.Lifetime, JetBrains.dotCover.Workspace.RdModel.Host.ProcessSnapshotsArg) + 0xe5 <– 0x7ffbe7d1b295
    9, JetBrains.Rd.Tasks.RdCall`2[[System.__Canon, mscorlib],[System.__Canon, mscorlib]].OnWireReceived(JetBrains.Serialization.UnsafeReader) + 0x242 <– 0x7ffbe7786602
    10, JetBrains.Rd.Impl.MessageBroker.Execute(JetBrains.Rd.Base.IRdWireable, Byte[]) + 0x102 <– 0x7ffbe7783c32
    11, JetBrains.Rd.Impl.MessageBroker+c__DisplayClass8_0.b__0() + 0xb5 <– 0x7ffbe7783a35
    12, JetBrains.Threading.ReentrancyGuardEx+c__DisplayClass0_1.b__3() + 0x2d <– 0x7ffbe7782eed
    13, JetBrains.Threading.ReentrancyGuard.Execute(System.String, System.Action) + 0x1b1 <– 0x7ffbe7781ff1
    14, JetBrains.Threading.ReentrancyGuard.ExecutePendingActions() + 0x9b <– 0x7ffbe77814bb
    15, JetBrains.Threading.JetDispatcher+Closure.Execute() + 0x1a5 <– 0x7ffbe7781265
    16, JetBrains.Util.Concurrency.WinJetDispatcher.ProcessQueue(Int32) + 0x271 <– 0x7ffbe7780f41
    17, System.Windows.Threading.DispatcherOperation.InvokeDelegateCore() + 0x30 <– WindowsBase.ni.dll+0x159a20
    18, System.Windows.Threading.DispatcherOperation.InvokeImpl() + 0x131 <– WindowsBase.ni.dll+0x166761
    19, MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object) + 0x4d <– WindowsBase.ni.dll+0x17a7fd
    20, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <– mscorlib.ni.dll+0x58df12
    21, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <– mscorlib.ni.dll+0x58dd95
    22, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) + 0x55 <– mscorlib.ni.dll+0x58dd65
    23, MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object) + 0xb1 <– WindowsBase.ni.dll+0x166531

  2. Ivan says:

    Guys, please. Remove unnecessary dotnet logs, that you introduce sinse 2020 version:
    It has gray color and looks like this

    C:\Projects\xxx\src\xxxx
    -t
    obj\Debug\netcoreapp2.2\xxxx.TagHelpers.output.cache
    -v
    2.1
    -c
    MVC-2.1
    -n
    MVC-2.1
    -e

Leave a Reply

Your email address will not be published. Required fields are marked *