Wave dependency

[aienabled]

https://www.jetbrains.com/help/resharper/sdk/Extensions/Troubleshooting.html#wave-dependency

I have started rewriting the plugin C# project to new SDK project type and removed nuspec file by moving all the stuff into csproj. Turns out the wave dependency is artificial... is there a proper way to define it into csproj file so it will result in a proper generated nuspec file in the generated NuGet package?

[aienabled]

Ok I see it's done this way in https://github.com/JetBrains/resharper-rider-plugin/ generated plugin csproj... however it doesn't build for me with VS2017: Detected package downgrade: JetBrains.Psi.Features.src from 183.0.20190124.113324 to 183.0.20181217.121206. Reference the package directly from the project to select a different version.

UPD. Ok it works when I define the ReSharper SDK version as 2018.3.3. $(WaveVersion) is automatically substituted and I have resulting nuspec: <dependency id="Wave" version="183.0.0" exclude="Build,Analyzers" /> That's a bit strange as I was defining version="13" before but I will check maybe it will be properly recognized by ReSharper extensions manager...

UPD. It's properly recognized. The resulting csproj definition I have (I'm using JetBrains.Annotations for my plugin project):

 <ItemGroup>
    <PackageReference Include="JetBrains.Annotations" Version="2018.3.0">
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="JetBrains.ReSharper.SDK" Version="2018.3.3">
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Wave" Version="183.0.0" />
 </ItemGroup>

Guys, please update the docs here https://www.jetbrains.com/help/resharper/sdk/Extensions/Troubleshooting.html#wave-dependency as the text is outdated.

[matkoch]

Please check the 0.9.0 of the plugin template.

[matkoch]

Guys, please update the docs here jetbrains.com/help/resharper/sdk/Extensions/Troubleshooting.html#wave-dependency as the text is outdated.

I'm not sure what to update, the general statement is still correct.

[aienabled]

@matkoch, I've checked 0.9.0 and it's building without any issues, however it seems to target new ReSharper EAP only? The resulting nuspec file (in nuget package) contains: <dependency id="Wave" version="191.0.0-eap02" exclude="Build,Analyzers" />

I'm a bit confused the csproj doesn't set to produce NuGet package on build. I suppose this is intended considering there is the buildPlugin.ps1 script? But it doesn't produce NuGet package either. I had to manually use the "pack" command to see the resulting NuGet package.

Regarding the docs - the general statement is still correct but it's definitely outdated in some places such as The dependency should be set to [2.0] for ReSharper 9.1, and [1.0] for ReSharper 9.0. it was years ago and doesn't help much - it would be better if you add a hyperlink on a page describing it in more details... Another outdated wording is The “Wave” package is a “virtual” package. It doesn’t exist, and cannot be added to the compile time project via nuget.org however as I can see you had to actually create such NuGet package to workaround this issue (I mean the ticket we're discussing now) as NuGet doesn't support any artificial dependencies and new csproj format requires PackageReference to an actual NuGet package. The version number also doesn't make much sense to me as previously as I remember the wave version was incremented with every ReSharper release (and I've definitely used wave version 13 for my latest ReSharper plugin) and now suddenly it's 183.0.0 or 191.0.0. That's very confusing.

[matkoch]

• If you don't want to build against EAP releases, you can modify the download URL here
• Build does nothing else than actually building. If you want to change this, you can edit the invocation to be similar to the run script.
• Okay, I will remove the specific version numbers there.
• The package is virtual in the sense, that it doesn't exist in our NuGet feed. The one you've linked is from 2017 and is only shown because all packages have been unlisted.
• The versioning scheme was changed so it better matches the actual ReSharper/Rider releases. 2018.1 -> 181.0.0

[aienabled]

@matkoch thank you for the detailed response. It resolves most of the confusion I had, and if you also improve the docs it will help other plugin developers.

The overall plugin development experience does look better now, but I have some worries.

With "dotnet new" it's easy to start a new project as it generates the boilerplate but there is no way to update the current plugin by using the latest template - as I understand this should be done manually (create a plugin with the same name by using the latest template, copy the plugin code) and all the customizations done to scripts (such as proposed "If you don't want to build against EAP releases, you can modify the download URL here") should be redone after updating.

Please consider a way to make this easier for developers to update to newer version of the template (and to select ReSharper/Rider/VS target versions).

Also, please consider to making the generated template folder tidy... there are too many building artifacts which I personally don't want to keep track of - for example, I have no idea what is gradlew.bat or build.gradle or protocol and other folders. I don't care about them. I care only about my project code and I want a clear way to:

• build it
• test it (F5!)
• publish it
• update it - to support any ReSharper/VS version

This was clear and straightforward before (VS2015 and prior). My project folder was extremely tidy, everything was configured in csproj and packages.config. I understand the reasons why it became complicated with VS2017, but I still want to have the best experience. And if you actually want to have developers working on plugins you need to remember this and make everything as simple as possible to us, removing all the clutter and providing the best tools. (for example, move all the building artifacts into a subfolder, create a file with constants where I can define my target ReSharper version and other necessary settings)

I can create a new issue so you can keep track of my concerns and suggestions there. Or you can do this yourself. You can also discard my opinion if you believe you're actually doing your best.

You can close this issue now as it's resolved - I was able to upgrade my plugin from nuspec to modern SDK csproj. Thank you.

[matkoch]

Please consider a way to make this easier for developers to update to newer version of the template (and to select ReSharper/Rider/VS target versions).

I'm not really sure what you're thinking of, but as far as I'm concerned, overwriting the existing files + picking/reverting changes via VCS seems pretty straightforward. Also, new versions are released very quickly, and changes can be tracked in this repository.

Also, please consider to making the generated template folder tidy... there are too many building artifacts which I personally don't want to keep track of - for example, I have no idea what is gradlew.bat or build.gradle or protocol and other folders. I don't care about them.

The template is as tidy as it can be considering the frameworks involved. The Rider part needs Gradle to work, which already brings a lot of structure with it. If you're talking about a separate template, that would be somewhat contradictory to what you said, because it would make the release of new template versions more complicated and confusing. If you don't need the protocol folder, then just delete it (which also allows reverting the deletion in case you need it later). Build artifacts should all be excluded via gitignore.

I care only about my project code and I want a clear way to: build it, test it (F5!), publish it, update it - to support any ReSharper/VS version

As far as I can tell, the template already serves a one-click solution for debugging, and that's in fact cross-platform. Same for publishing; as long as you're following the suggested structure, it automatically builds for ReSharper and Rider. The readme contains explanations about version-relevant code, which is basically how you update.

And if you actually want to have developers working on plugins you need to remember this and make everything as simple as possible to us, removing all the clutter and providing the best tools.

I can assure you that we made a lot of effort already to provide this template as a better entry experience for ReSharper/Rider plugin developers. However, at the current moment there won't be a ReSharper-only template, but maybe in a few months when we can call it a 1.0 template. All other suggestions are welcome.