TargetFramework version for R# 9 extension csprojs

Hello,

Which "TargetFramework" version should be selected (4.0, 4.5, ...)?

4.0 if you want to target VS10.
4.5 if it's VS11+.

Both seem to work, but both produce a lot of compiler warnings

Weeellll, can't be sure they're unexpected. What are they?

—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

Hi,

Both seem to work, but both produce a lot of compiler warnings

Weeellll, can't be sure they're unexpected. What are they?

Below I posted the warnings for an empty class library, referencing SDK package version 9.1.20150522.81235.


... the warnings for TargetVersion = 4.0:

... the warnings for TargetVersion = 4.5:

hiThere,

| Warning | 1 | There was a mismatch between the processor
architecture of the project being built "MSIL" and the processor
architecture of the reference "JetBrains.ReSharper.Psi.Cpp", "x86".

This one is expected. That's the way it is :( We have this ignored in our
build (by setting MSBuild property ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch
to None). Might have done this in our Nuget .tasks (or .targets, whatever)
file, but not sure if that would be a nice thing to do for every project
which references them.

| Warning | 3 | The predefined type 'System.Threading.Tasks.Task' is
defined in multiple assemblies in the global alias; using definition

This one is also expected for v4.0+ projects with wave02 and below. In v3.5
projects that won't happen.

Starting with wave03, we're dropping support for v3.5, together with those
shim DLLs.

These can also probably be suppressed (we don't have them on compile), but
these have been copied from some strange view and they have incomplete info.

| Warning | 5 | The referenced component
'JetBrains.Platform.VisualStudio.JustVs11' could not be found. |  |

Hmm, where is this coming from? "Component"?.. What's a component?

.. the warnings for TargetVersion = 4.5:

| Warning | 3 | The predefined type
'System.Runtime.CompilerServices.CallerLineNumberAttribute' is defined

'System.Runtime.CompilerServices.CallerFilePathAttribute' is defined

'System.Runtime.CompilerServices.CallerMemberNameAttribute' is defined

These are also coming from the async shim library for v3.5.

So they're OK to ignore, after all.

—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

Hi Serge,

Many thanks for your info and especially how you cope with these warnings in your internal builds.

Should I create a bug report for the "The referenced component 'XXX' could not be found" warnings with TargetFrameworkVersion = 4.0?

Hello,

Should I create a bug report for the "The referenced component 'XXX' could

not be found" warnings with TargetFrameworkVersion = 4.0?

Can't see these with 9.1.20150522.81235 when compiling in VS12 for netfx
4. Got the full output like this:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5):
warning MSB3270: There was a mismatch between the processor architecture
of the project being built "MSIL" and the processor architecture of the reference
"JetBrains.ReSharper.Psi.Cpp", "x86". This mismatch may cause runtime failures.
Please consider changing the targeted processor architecture of your project
through the Configuration Manager so as to align the processor architectures
between your project and references, or take a dependency on references with
a processor architecture that matches the targeted processor architecture
of your project.

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5):
warning MSB3270: There was a mismatch between the processor architecture
of the project being built "MSIL" and the processor architecture of the reference
"JetBrains.ReSharper.TaskRunner", "x86". This mismatch may cause runtime
failures. Please consider changing the targeted processor architecture of
your project through the Configuration Manager so as to align the processor
architectures between your project and references, or take a dependency on
references with a processor architecture that matches the targeted processor
architecture of your project.

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'

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'

Could you please copy the full warning message on that component, incl the
tool name and error code? That's either the Output VS tool window, or console
output of the msbuild.exe tool.

—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

Hello,

Many thanks for your info and especially how you cope with these
warnings in your internal builds.

Sure. Now found the second kind of warnings as I ran the build here (yours
sample were missing the warning numbers).

We got the suppress for it also emitted into the list for the NoWarn MSBuild
property.

      // “The predefined type 'System.type name' is defined in multiple assemblies
in the global alias; using definition from 'File Name'”: we use a lib for
asyncs in netfx35, so in netfx4+ projects it causes this warning.
      codelist.Add(1685);

So, manually this would amount to adding 1685 to the NoWarn list of the csproj;
no better solution so far.

—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

Hi Serge,

Many thanks!

With the 2 suppressions (CS1685 and ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch) all warnings except "The referenced component ..." disappeared.

But, these warnings just appear in VS (see screenshot), not in an MSBuild command line build.

Hi Serge,

I found the reason for the "The referenced component X could not be found" warnings. The VS project system seems to be confused by the conditional <Reference> elements in the .targets file (The assembly reference is loaded although the condition evaluates to false, but it has no properties, like the HintPath).

But: I found a workaround by using the <Choose> element.

If you refactor the following block in JetBrains.Platform.VisualStudio.Targets ...

    <Reference Include="JetBrains.Platform.VisualStudio.SinceVs10" Condition="($(TargetFrameworkVersionNumberWizusul) &gt;= 4000) OR ('$(JetReferencesNoFilter)' == 'True')">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>$(MSBuildThisFileDirectory)..\DotFiles\JetBrains.Platform.VisualStudio.SinceVs10.dll</HintPath>
      <Private>$(JetReferencesPrivate)</Private>
      <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
      <TargetFrameworkVersionNumber>4000</TargetFrameworkVersionNumber>
    </Reference>
    <Reference Include="JetBrains.Platform.VisualStudio.SinceVs11" Condition="($(TargetFrameworkVersionNumberWizusul) &gt;= 4005) OR ('$(JetReferencesNoFilter)' == 'True')">
      <SpecificVersion>False</SpecificVersion&>
      <HintPath>$(MSBuildThisFileDirectory)..\DotFiles\JetBrains.Platform.VisualStudio.SinceVs11.dll</HintPath>
      <Private>$(JetReferencesPrivate)</Private>
      <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
      <TargetFrameworkVersionNumber>4005</TargetFrameworkVersionNumber>
    </Reference>

... into ...


<Choose>
  <When Condition="($(TargetFrameworkVersionNumberWizusul) &gt;= 4000) OR ('$(JetReferencesNoFilter)' == 'True')">
    <ItemGroup>
      <Reference Include="JetBrains.Platform.VisualStudio.SinceVs10">
        <SpecificVersion>False</SpecificVersion>
        <HintPath>$(MSBuildThisFileDirectory)..\DotFiles\JetBrains.Platform.VisualStudio.SinceVs10.dll</HintPath>
        <Private>$(JetReferencesPrivate)</Private>
        <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
        <TargetFrameworkVersionNumber>4000</TargetFrameworkVersionNumber>
      </Reference>
    </ItemGroup>
  </When>
</Choose>
<Choose>
  <When Condition="($(TargetFrameworkVersionNumberWizusul) &gt;= 4005) OR ('$(JetReferencesNoFilter)' == 'True')">
    <ItemGroup>
      <Reference Include="JetBrains.Platform.VisualStudio.SinceVs11">
        <SpecificVersion>False</SpecificVersion>
        <HintPath>$(MSBuildThisFileDirectory)..\DotFiles\JetBrains.Platform.VisualStudio.SinceVs11.dll</HintPath>
        <Private>$(JetReferencesPrivate)</Private>
        <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
        <TargetFrameworkVersionNumber>4005</TargetFrameworkVersionNumber>
      </Reference>
    </ItemGroup>
  </When>
</Choose>

... no warning is generated for VisualStudio.SinceVs11 in a 4.0 project, and the assembly reference is correctly loaded when switching to 4.5.

I created RSRP-440559.

Hello,

But: I found a workaround by using the <Choose> element.

The sets are not mutually exclusive, so Choose-When is not a nice fit here.
And using multiple Chooses smells bad.

What would it say if you transplant the condition from Reference task item
elements onto the parent ItemGroup element?

—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

What would it say if you transplant the condition from Reference task item
elements onto the parent ItemGroup element?

I tried this already. It didn't work, just the <Choose>-workaround. And yes, it would require one <Choose> per condition expression.

I am also running into many of these warnings/errors when installing the NuGet package JetBrains.ReSharper.SDK 9.2.20150819.163916 into existing projects.
The projects are targeted to "Any CPU", and I am getting many build errors:

Error CS0246 The type or namespace name 'CallerMemberName' could not be found (are you missing a using directive or an assembly reference?)

I wasn't getting these errors with JetBrains.ReSharper.SDK 9.1.

Hi,

did you change the target framework version of your 9.2 project to .NET 4.5?

KR, Ulrich

I have an existing project/solution of Resharper Plugins, and was trying to upgrade from the ReSharper SDK 9.1 to 9.2 but was getting errors trying to do that in VS2015. So I uninstalled all the ReSharper NuGet packages from the project and just installed ReSharper SDK 9.2 from VS2013, but now I get:

Error 6 The type or namespace name 'CallerMemberName' could not be found (are you missing a using directive or an assembly reference?)

I didn't manually change the target framework version to 4.5. I believe it's still targeting 4.0. Should I change it to target 4.5?

You should stick with 4.0. I've tested the nuget packages, and they do work, but you do have to close and reopen the solution after installing them. This is because they add new .targets files and msbuild doesn't automatically import these files - they're only imported when the solution is initially loaded.

"CallerMemberName" is an attribute defined in mscorlib. If, after reloading the solution, the type is still unresolved, I'd suggest clearing the caches (ReSharper -> Options -> General -> Clear caches + restart VS)

Hmm, .. but CallerMemberNameAttribute is .NET 4.5+. See https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.callermembernameattribute.aspx.

That's true but before the update to ReSharper 9.2 it looks like my project was still targeted to 4.0 and was resolving the CallerMemberNameAttribute type in the following assembly:

C:\Users\user\AppData\Local\JetBrains\Installations\ReSharperPlatformVs14_000\AsyncBridge.Net35.dll

(So even though it was targeting 4.0 it's using a type in a ReSharper library to resolve CallerMemberNameAttribute. This is the case after updating to 9.2. The project reference to AsyncBridge.Net35 isn't there anymore. Should I manually be adding it?

Nope. The async bridge project was because we wanted to use Tasks and async and everything, but only targeted .net 3.5. We now target .net 4.0, so we can use the real TPL and Task. So the async bridge package is no longer needed, and has been removed. What do you need to use CallerMemberNameAttribute for in a plugin? Is it for IPropertyNotifyChanged?

I could remove the references to [CallerMemberName], but they were ok before the update, and ReSharper's own plugin "Implement INotifyPropertyChanged" (Alt-Enter when cursor is on INotifyPropertyChanged in a class) add it in the code:


public class Triangle : INotifyPropertyChanged
    {
        public string TriangleId { get; set; }

        public int Size { get; private set; }

        public string Label { get; private set; }

        public event PropertyChangedEventHandler PropertyChanged;

        [NotifyPropertyChangedInvocator]
        protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
    }

If i need to remove the attribute from my code to get the plugins to build again (or target framework 4.5) I will do that, but it is unfortunate, since after I call "Implement INotifyPropertyChanged", I will need to remove that attribute again manually.

When ReSharper generates the OnPropertyChanged method, it only adds the CallerMemberName attribute if the attribute is known to the project - if it's not defined, it doesn't get added. I think you can declare the attribute in your own code, and as long as you give it the same name and namespace, the compiler is happy to use it. However, if you can, I think it would be a good idea to remove the references.

Hello,

The async bridge project was because we wanted to use Tasks and
async and everything, but only targeted .net 3.5. We now target .net
4.0, so we can use the real TPL and Task. So the async bridge package
is no longer needed, and has been removed.

Not quite, tasks are v4.5 for a substantial part, so we're still using async
bridge. But it's now the bridge 4.0->4.5 rather than the former 3.5->4.0,
so it should not have the same problems (might have other problems though).

Wish we could use the MSFT libraries for tasks like in Microsoft.Bcl.Async
Nuget package, but the DLL versions are not compatible with DLL references
in that package, so got to fallback to AsyncBridge.

—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”