CS1685 warning after creating new 8.1 Plugin in VS2013

I've installed the Resharper 8.1 (SDK 8.1.555), and in Visual Studio 2013 I created a new "ReSharper Plugin" project using the project template added by the SDK.

This newly created project has a couple of issues.

Firstly, immediately after creating the project, Visual Studio seems to think it has none of the necessary references (and R# turns loads of things in the source file red as a result). Unloading and reloading the project makes this go away - this seems to be because all the references come via the Plugin.References.Targets file in the build directory in the NuGet package folder for the SDK that the template seems to create.

That's annoying but not a big problem.

The real problem is that I get this warning when I build:

CSC : warning CS1685: The predefined type 'System.Threading.Tasks.Task' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll'

In fact, I get it twice.

The cause seems to be that the NuGet package for the ReSharper 8.1 SDK (as added by the project template) rather astonishingly insists on supplying its own copy of System.Threading.Tasks.dll!

(Even if I were prepared to ignore the warning, I can't really, because as soon as you try to use the Task type, instead of a warning, you get an error reporting the ambiguity of the reference.)

I presume this has something to do with enabling support for .NET 3.5, which doesn't have that DLL. However, the newly created project is set up to target .NET 4.0, which does have this DLL. Except, there isn't really support for .NET 3.5 with this project templaet: modifying the project to target .NET 3.5 results in some 273 build warnings, because loads of the DLLs in the SDK have either direct or indirect references to the .NET 4.0 version of mscorlib.

So there doesn't seem to be any justification for this bogus System.Threading.Tasks.dll being present. The problem is that you don't seem to be able to get rid of the reference to it. Because this reference comes from the Plugin.References.Targets file, you can't remove it from the list of references in Solution Explorer like you normally would. (It's not an ordinary assembly reference stored in the .csproj - it's a reference picked up from an external targets file.)

Of course, I could edit the Plugin.References.Targets file, but editing the contents of NuGet packages is in general a bad idea. (What if I update the package at some point? In any case, I normally use package restore, so the contents of the NuGet packages folder don't normally get checked in.)

About the only way I can see to resolve this is to make a copy of the Plugin.Reference.Targets file that lives somewhere outside of the packages folder, edit it to remove the reference to the unwanted local copy of System.Threading.Tasks.dll, and use that instead. But that would then mean having a modified copy of Plugin.Targets (because that's what reference the problematic Plugin.References.Targets), which in turn would mean having a modified copy of JetBraings.ReSharper.SDK.Targets (because that's where the reference to Plugin.Targets comes from). Basically, I'd have to stop using most of what's in the NuGet package's 'build' folder.

I can't believe I should have to perform such major surgery on the build configuration of a freshly-created Plugin project created for me by the SDK.

What am I missing? What do I need to do to get a clean compile with a brand new ReSharper plugin project?

Comment actions Permalink

I did not experience the problem with the references. I switched to the NuGet-Bundle and did a rebuild. That worked just fine.

The "Task" problem did appear for me too, though. Fortunately, I have only one usage of the type, so I could rewrite that part quite easily. But that's an ugly workaround, not a fix... I'd really like to see a clean solution for this!


Comment actions Permalink

I submitted a bug for this at http://youtrack.jetbrains.com/issue/RSRP-403893

I see that a JetBrains employee has escalated the bug to "Critical" so it looks like they agree it's a problem.

Unfortunately, they currently seem to be proposing a fix for version 9.0, which suggests that there might not be an update to the 8.1 SDK to fix this.


Please sign in to leave a comment.