.NETCore intellisense problem when having multiple versions of .NETStandard

Answered

   We have a .NETCore class library configured to compile the project for the following frameworks: net35, net40, net45, .NETPortable,Version=v4.0,Profile=Profile328, .NETPortable,Version=v4.5,Profile=Profile259, netstandard1.0 and netstandard1.3. There is one important thing in the netstandard configuration section. Look at this section

        "netstandard1.0": {
            "buildOptions": {
                "define": [ "NO_FILE", "NO_CRYPTO" ]
            },
            "dependencies": {
                "System.Collections": "4.0.11",
                "System.Diagnostics.Debug": "4.0.11",
                "System.IO": "4.1.0",
                "System.Linq": "4.1.0",
                "System.Resources.ResourceManager": "4.0.1",
                "System.Runtime.Extensions": "4.1.0",
                "System.Text.Encoding.Extensions": "4.0.11"
            }
        },
        "netstandard1.3": {
            "dependencies": {
                "System.Collections": "4.0.11",
                "System.Diagnostics.Debug": "4.0.11",
                "System.IO": "4.1.0",
                "System.IO.FileSystem": "4.0.1",
                "System.Linq": "4.1.0",
                "System.Resources.ResourceManager": "4.0.1",
                "System.Runtime.Extensions": "4.1.0",
                "System.Security.Cryptography.Algorithms": "4.2.0",
                "System.Text.Encoding.Extensions": "4.0.11"
            }
        }

Pay attention that there is "define": [ "NO_FILE", "NO_CRYPTO" ] for the version 1.0. We have another test project in the solution using xUnit to test this class library and the project.json looks like this

{
    "testRunner": "xunit",
    "frameworks": {
        "netcoreapp1.0": {
            "dependencies": {
                "Microsoft.NETCore.App": {
                    "type": "platform",
                    "version": "1.0.0"
                }
            },
            "imports": [
                "dnxcore50",
                "portable-net451+win8"
            ]
        }
    },
    "dependencies": {
        "Microsoft.Extensions.PlatformAbstractions": "1.0.0",
        "SharpCompress": "0.12.4",
        "xunit": "2.2.0-beta2-build3300",
        "dotnet-test-xunit": "2.2.0-preview2-build1029"
    }
}
 
   Now the problem is this. No matter what we did what we tried to change, intellisense did not pick up all the methods from the class library and many methods which are perfectly valid and compilable were displayed red is if they were missing. It looks like the problem is that ReSharper uses "netstandard1.0" section no matter what and there are defines in that section which affects the API and certain methods are excluded for "NO_FILE", "NO_CRYPTO". Nevertheless, the solution is perfectly compilable and runnable and xUnit tests are started just fine because as I understand everything is compiled against "netstandard1.3" which does not have those defines and has the complete set of methods.
   We found one workaround. Commenting out "netstandard1.0" section makes intellisense working right but we always have to remember uncomment it before committing which is rather inconvenient. Is there a way to fix this situation without commenting out "netstandard1.0" section? (ReSharper 2016.2.2).
 
6 comments
Comment actions Permalink

Hello Alex,

It is hard to say anything useful without a demo project which will demonstrate the same behavior you experience.

Thanks!  

0
Comment actions Permalink

   I believe you can easily replicate it with my detailed description. Try it. Honestly it looks like a bug in ReSharper. It simply uses either first encountered .NETCore class library or gives preference to lower version. Instead if it would use project.lock.json, it could find correctly the currently linked library version. There is section in the project.lock.json

"SharpCompress/0.12.4": {
"type": "project",
"framework": ".NETStandard,Version=v1.3",
"dependencies": {
"System.Collections": "4.0.11",
"System.Diagnostics.Debug": "4.0.11",
"System.IO": "4.1.0",
"System.IO.FileSystem": "4.0.1",
"System.Linq": "4.1.0",
"System.Resources.ResourceManager": "4.0.1",
"System.Runtime.Extensions": "4.1.0",
"System.Security.Cryptography.Algorithms": "4.2.0",
"System.Text.Encoding.Extensions": "4.0.11"
},
"compile": {
"netstandard1.3/SharpCompress.dll": {}
},
"runtime": {
"netstandard1.3/SharpCompress.dll": {}
}

   It clearly states that netstandard1.3/CustomLibrary.dll library should be used (not netstandard1.0/CustomLibrary.dll).

   If you think it is difficult to replicate the issue by this description you can try to get https://github.com/adamhathcock/sharpcompress project locally and you'll see yourself what I mean. Intellisense will work right only if you comment out netstandard1.0.

 

0
Comment actions Permalink

   So, do we have a confirmed bug here?

0
Comment actions Permalink

Hello Alex,

I downloaded mentioned SharpCompress solution, ReSharper shows me "WriteToDirectory"/"WriteEntryToDirectory" in red, but Roslyn analysis does the same things. Also there are some red squiggles for, e.g. "path" variable in "using (var archive = ArchiveFactory.Open(path))" but Roslyn shows the squiggle for that as well. 

So please could you attach a few screenshots of the issue you are talking about? 

Thanks!  

0
Comment actions Permalink

   But you have the screenshot, there is nothing more to it. This is exactly what I meant. I didn't compare ReSharper with Roslyn or anything else. Maybe Roslyn fails too. I simply assumed that you want to make ReSharper the best and even if Roslyn does not work it does not mean that ReSharper should fail in the same manner. :)

   Now if you open project.json from the SharpCompress class library and remove netstandard1.0 section from the frameworks list, then, of course recompile and probably you need to restart VS you'll see that the problem is resolved. It is a workaround I mentioned. However it would be nice if we were not forced to remove netstandard1.0 to make it work.

   Anyway, I guess it is up to you. I have a workaround, not a perfect one but it works. If you want to improve ReSharper, thank you.

0
Comment actions Permalink

Hello Alex, 

Thanks for the reply and for sharing your thoughts.

I filed a new request to YouTrack https://youtrack.jetbrains.com/issue/RSRP-461145, so feel free to follow/comment/vote for it.

Thanks!  

0

Please sign in to leave a comment.