How to let a Visual Studio 2015 xproject (project.json) reference the highest framework of a depending project

Question

I'm creating a reusable library that targets several platforms (.NET 4.0, .NET 4.5, .NETStandard 1.0 and .NETStandard 1.3). The .NET 4.5 version of this project contains some features that are not available under the .NET 4.0 version.

The unit test project that references this library project has one single target platform, namely NET 4.5.1. This test project obviously contains some code that tests the .NET 4.5 specific features of the core library.

Unfortunately however, the test project does not compile, because Visual Studio seems to reference the .NETStandard 1.0 version, which obviously does not contain this feature.

To demonstrate my problem, I reduced this to the following two projects:

Core library:

{
  "version": "1.0.0-*",

  "frameworks": {
    "netstandard1.0": {
      "dependencies": {
        "NETStandard.Library": "1.6.0"
      }
    },
    "net40": {},
    "net45": {}
  }
}

Code file:

namespace CoreLibrary
{
#if NETSTANDARD1_0
    public class ClassNetStandard { }
#endif

#if NET40
    public class ClassNet40 { }
#endif

#if NET45
    public class ClassNet45 { }
#endif
}

Test library:

{
  "version": "1.0.0-*",

  "dependencies": {
    "CoreLibrary": { "target": "project" }
  },
  "frameworks": {
    "net451": {}
  }
}

Code:

// This compiles
new CoreLibrary.ClassNetStandard();

// This doesn't.
// error: Type or namespace 'ClassNet40' does not exist in namespace 'CoreLibrary'
new CoreLibrary.ClassNet40();
// error: Type or namespace 'ClassNet45' does not exist in namespace 'CoreLibrary'
new CoreLibrary.ClassNet45();

What should I change to allow my unit test project to compile and test the specific .NET 4.5 features?

Bink

In my case (with the exact two projects you provided), Test library actually compiles with "new CoreLibrary.ClassNet45();" statement and does not compile with "new CoreLibrary.ClassNetStandard();". So, as you would have expected. You sure it really does not work with ClassNet45 in your case? Because it might show that there are errors in "errors" window in Visual Studio, but still really successfully compile. – Proffitt

@Evk: You are right. Although both the IDE and Error List show an error, the assembly does get compiled to the bin\Debug\net451 folder. After inspecting this assembly with Resharper, it does work. Conclusion: the Visual Studio Tooling sucks. – Bink

Try to install latest version of .NET Core tools for VS 2015 from here: microsoft.com/net/core#windowsvs2015. This actually solved this for me (no fake errors any more). – Proffitt

@Evk: I just installed the latest tools (1.0.1 Preview 2), but the effect is the same (still fake errors). – Bink

Yes you are right, that's not what fixed that error for me - I just put "net45" first in the framework list in Core library project (which removes the error but of course does not solve the problem). – Proffitt

I love the concept of having one project for multiple builds, but integration in the IDE still stinks. Nonetheless, thanks for your time. – Bink

Yeah seems so. Maybe worth trying to install Visual Studio 2017 RC and see how it goes there... – Proffitt

@Proffitt If you post an short answer, I will mark it as such. This way I can compensate you for your help. – Bink

Answer 1

There seems to be a bug in Visual Studio tools for .NET Core. When you reference multi-framework project from another one - Visual Studio only takes first listed framework from a list (in your case - "netstandard1.0") and treats that referenced project as single targeted for this framework. However, compiler handles this correctly, and while it seems that project builds correctly - in reality it does not. On the other hand, when you use ClassNet45 definition - it seems that it does not compile (Visual Studio shows errors) - it really does compile successfully.

It seems that Visual Studio tools for .NET Core are not polished enough yet, but probably this bug will be resolved in some near future.

Proffitt

If it's a bug, could you link to the actual issue on Github? You say it's a bug, but without some sort of evidence, it's just a supposition. How did you verify that this was a bug? – Merocrine

@GeorgeStocker Well it is supposition, and I think I indicate that("There seems to be a bug"). Though it's quite clear that behavior is wrong - project successfully compiles while Visual Studio indicate there are errors in it and as such it should not compile. Not sure what kind of stronger verification you want. – Proffitt

@GeorgeStocker As for actual issue, there are 403 open issues on github for asp.net core tools for Visual Studio and it's not very easy to figure out if it was reported or not. But here is similar issue: github.com/aspnet/Tooling/issues/849. – Proffitt