Support for the Upcoming .NET SDK 7 Follow

Dear everyone! 

Here is a small update about this matter: 

• The ".NET SDK 7 is not fully supported" message was removed in the 2022.3 EAP8 build. 
• We are going to deliver two more EAP builds before the final release to polish all the things. 
• We are going to release Rider/ReSharper/.NET tools 2022.3 at the beginning of December. 

Thanks!

Thanks Alexander Kurakin! Appreciate your time and work!

Thanks, Alexander Kurakin! Looking forward to it and appreciate the hard work and time on this matter!

If you're seeing

The current .NET SDK does not support targeting .NET 7.0 

then try switching your tooling (settings -> build, execution, deployment -> toolset and build -> msbuild version). What I've found is that using msbuild from vs2022 _Community_, all up-to-date, produces this error, but using msbuild from vs2022 _Build Tools_ (all up to date) works just fine. For me, the Rider warning is just that - a warning - I'm currently working on many solutions targeting dotnet7, in Rider. I came here to find out _what_ isn't supported, and that hasn't really become apparent. Apart from the warning, after ensuring that I'm using _Build Tools_ and _not_ VS proper, I wouldn't even know the difference from targeting net6.0.

Interestingly, some projects seemed to be easily upgraded from net6.0 to net7.0 without any issue, and other times I had to manually set the build tools msbuild for use. I only have vs2022 community installed "just in case" I need an IDE - I tend to use Build Tools anyway, rather than the built-in msbuild, because I can update it out-of-band and I have CLI build for all my projects anyway, so I'm going to need CLI tools.

Alternatively, select msbuild from your dotnet 7 sdk installation folder - it seems like, for some projects, this is being auto-detected & selected.

Jesus man, we're looking at 2-3 weeks after the official release given it's in the latest EAP. Considering Jetbrains don't have the foresight or control MS have over the roadmap, that's really not that bad!

Stop being so bloody entitled, you're just embarassing yourself.

Since I can't seem to edit it, my previous comment was aimed at Pavel

James Hughes James:

• The original comment is from October. At that time, .Net 7 was in RC2 and the post from Jetbrains (which has now been changed) said something along the lines of ".Net has itself many issues, we'll look into it closer to its release" - which at that point was less than a month before the release
• For previous releases - .Net 5 and 6 (can't tell for .net3 as there was no Rider back then), Jetbrains had official EAP with support for the upcoming .Net in (if I recall correctly) in August or September. For .Net 7, less than a month before official release, it said "we'll look into this later". WTH?
• I have been paying for the all products subscription since whenever it came along (and have been a paying Jetbrains customer for about 10 years now - myself, not an employer or something like that), so I can compare both over time service degradation as well as the development speed among different Jetbrains IDEs. In general, the features are available in IntelliJ, then the rest, and then long time after in Rider. Goland always has up to date feature set with both official and pre-release of Go, for instance. Same with Java. Rider on the other hand is often a year or more late with features that other Jetbrains IDEs have (such as container development, Code with me etc.)
• .Net development is very transparent, and roadmap has been stable since January and first preview came out in mid February. That is a lot of time. .Net development is not a MS blackbox, hasn't been for many years now.
• You're confusing entitlement and customer service. If I'm paying a subscription, I expect the service. And the service has degraded greatly comparing to what it was before. Or, in another words, I paid for a different level of service (based on previous experience) at the time of subscription than what I'm getting right now. And if that still sounds too cryptical for you: If you go to a pub for 10 years, always order Heineken and always get Heineken, and then suddenly one day order Heineken again but get PBR for the same price without any explanation, it's not entitlement to call it out.
• The fact that the original post has changed several times by Jetbrains in the past few weeks and now my original comment seems less relevant is unfortunate, but considering nobody from Jetbrains made any comment or response to this thread and instead changed the post is by itself wrong and shows a rather strange approach of Jetbrains towards its longtime paying customers. I haven't seen this kind of communication from a reputable company in quite a while.
• So, to paraphrase your own words, shut your bloody mouth, you have no idea what you're talking about.

I upgraded to 2022.3 yesterday, and now the builds for one of our legacy .NET Framework 4.7.2 projects fail in Rider because it is trying to use .NET Core (not sure which version). Rolling back to 2022.2.4 fixed the issue. I will open a ticket.

I don't know if anyone else had the same issue, but since I upgraded to 2022.3, it's been almost impossible to use Rider due to high CPU usage, almost 80%. This wasn't happening with 2022.2.4. 

Have you tried invalidating caches and restarting (from the file menu)? I've had some times when an upgrade to rider doesn't play nicely with existing project caches.

Hi Davyd,

I found out what was the issue (sorry, I totally forgot to come back here and post my solution). I found this info in a ticket thread in Jet Brains support area. The issue was related to Hunspell. Disabling it did the tricky.

But hey! JetBrains just released a new update to 2022.3 (it is 2022.3.1) which contains some bug fixes and, among them, the fix for the Hunspell issue.

Hi all,

I was able to resolve the issue "The current .NET SDK does not support targeting .NET 7.0". I don't know if this is specific to Rider.

MSBuild 17.4 is required for .NET 7. For some reason, even if you have SDK 7.x installed, the build tries to use older version that only works for .net 6.

Add a global.json file to the project to tell MSBuild the SDK version to use. For example (not sure if you have to be so specific with the version, looks like "7.0" works as well):

{
  "sdk": {
    "version": "7.0.101",
    "rollForward": "latestFeature"
  }
}

find your latest sdk version installed with > dotnet --list-sdks

Are we getting close?  I'm seeing a lot more red squiggles in Rider these days as .NET 7 features are showing up all over our code.

Unacceptable for how long it took for Jetbrains to support .NET7. I mean the whole reason for having this toolchain is to not needing to use MS Visual Studio. With .NET 7, we just couldn´t! 

I'm not sure how you needed MS Visual Studio to develop against net7.0 - not only have I written brand new things in net7.0 in Rider, I'm really close to a release on our main product which is an upgrade from net462 to net7.0 (asp.net mvc4 to asp.net core 7.0 mvc). At most, you could have disregarded the occasional warning and manually switched your toolchain.

Would it have been nice not to have? Sure. Was it a show-stopper? Not At All.

Dear Jetbrains, I have been using your products for a while (resharper v1). You are doing a great job! Release it when it is ready. I have done OSS stuff with Microsoft in the past and I am familiar with how the "sausage machine" works. Good decisions but it can rip through tooling like a living nightmare of a tidal wave for new major versions of the SDK. Suggest the "fast food culture raging" on this thread is kept to a minimum folks, you have no idea what a garganuation engineering feat it is to keep up with tooling for a major release of dotnet. Easy now, slowly slowly we will get there. Patience is a virtue my friends. #genx :)