ReSharper 2018.2 will require .NET Framework 4.6.1

TL;DR: ReSharper 2018.2 will require having .NET Framework 4.6.1 installed.

Starting with the next ReSharper 2018.2 release, we will require having .NET Framework 4.6.1 installed on your machine. Earlier versions of ReSharper will continue to work on .NET Framework 4.5.

Why is this changing?

With the .NET Framework evolving rapidly in the past years and Microsoft having stopped support for .NET Framework 4, 4.5 and 4.5.1 over two years ago, updating the required .NET runtime for ReSharper is a logical next step.

Newer versions of the .NET Framework come with numerous improvements, such as performance, security and Windows Presentation Foundation updates. The NuGet client SDK used by ReSharper also requires .NET Framework 4.6 or higher. Making use of the newer, modern runtime brings along these improvements and will greatly benefit our users and opens up new possibilities!

Thanks to this upgrade, the ReSharper codebase can now target .NET Standard 2.0 (and .NET Core), so that for example our Command Line Tools and Remote Profiling Tools will eventually no longer require a full .NET Framework installation at all. This also helps our (non-UI) tools to run on Linux and Mac OS X with better quality. The future is bright!

What does this mean for me?

Older operating systems, such as Windows XP, Windows Vista, Windows Server 2003 and Windows Server 2008 Service Pack 2 will no longer support ReSharper 2018.2 and newer. Earlier ReSharper versions will continue to work.

If you are on a modern operating system or are using Visual Studio 2015 or newer, the .NET Framework 4.6.1 is already installed and will support working with ReSharper 2018.2.

Will I need to retarget my own projects as well?

No. The .NET Framework 4.6.1 runtime is only required to be able to run ReSharper.

Being a productivity tool for .NET developers, we strive for compatibility with as many versions of the .NET Framework and Visual Studio as possible. Projects targeting e.g. .NET 3.5 or .NET 4.5 will still be supported in ReSharper 2018.2, and continue to benefit from rich code editing and code generation features, code analysis and quick-fixes, powerful refactorings, excellent navigation and more!

Download ReSharper now and give it a try!

This entry was posted in How-To's and tagged , , , , , , . Bookmark the permalink.

9 Responses to ReSharper 2018.2 will require .NET Framework 4.6.1

  1. Warren says:

    Why 4.6.1 instead of 4.6.2? There are no supported operating systems that don’t allow 4.6.2, and you could be doing your part to enable long file paths — a feature new to 4.6.2.

    • Serge Baltic says:

      We had long paths working years ago in v4.5 and v4.0 :) Probably even when we did v3.5. This only applies to calls via our FileSystemPath APIs, but it covers almost all user scenarios except for running the product when installed in long paths. Ah, and they dropped long paths support in the recent Nuget versions, yes.

      So we only need to enable long paths support for third-party code. Which means our own code does not change. If v4.6.2+ is present on the machine, we can do the thing, and if it’s v4.6.1 only, we do not, but we can run in either case. Actually, why not try it right now when we’re on v4.5 requirement.

  2. Martin says:

    What about Rider in linux?

    • Martin says:

      Sorry… the answer is right there!

    • Serge Baltic says:

      Linux/Macos distributions ship a portable xcopy version of the runtime, and have no dependencies on the installed versions. Right now that’s Mono, but we’re eager to try .NET Core.
      Shouldn’t be any concern for end users even if we switch.

  3. Hendrik says:

    Will this bring a performance improvement for R# (RyuJIT)?

    • Any performance improvement the framework provides, yes, but these will probably be minimal. More performance work is being done in general, and that will have a much bigger impact.

  4. Loïc Galland says:

    This update to .NET Framework 4.6.1 prevents us to run 4.5.2 unit tests which use other DLLs which contain ZipArchive.GetEntry because of “Change in path separator character in FullName property of ZipArchiveEntry objects” as described in https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/retargeting/4.5.2-4.6.2
    How can we fix this?
    Is there a way to apply the Switch.System.IO.Compression.ZipFile.UseBackslash in the Resharper executable?

    • We’re going to support selecting any target framework version for running tests in the future (currently, it’s only v2.0 – v4.0 – v4.5).

      There is a workaround: you can edit all of the %LocalAppData%\JetBrains\Installations\ReSharperPlatformVs15_{guid}\JetBrains.ReSharper.TaskRunner***.exe.config files and add:

      <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" /> under the <runtime> node.

Leave a Reply

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