7

I have created a number of Shared Projects and am testing whether these can be shared among all the different project types as I hope and expect. I've managed all of them so far (sometimes with a little workaround), but I can't yet figure out how to do it with a .NET Core Class Library, which would be really useful.

As I can't seem to do it through Visual Studio 2015, does anyone know a way to do it? Perhaps by typing the reference straight into the project.json file for the Class Library?

EDIT: As of Visual Studio 2017 RC, Shared Projects properly work with .NET Core projects.

Arwin
  • 973
  • 1
  • 10
  • 21

2 Answers2

6

As of Visual Studio 2017 RC, Shared Projects properly work on the .NET Core platform as well.

Arwin
  • 973
  • 1
  • 10
  • 21
  • 1
    I guess that depends on one's definition of "properly". I have shared project that contains a unit test, and two test projects, one .NETCoreApp1.0 and one .NET Framework 4.6.2 which both reference the shared project. The shared test is only visible in .NET Framework. The same is true with a .NETCoreApp1.1. – Stephen Drew Feb 09 '17 at 14:41
  • 1
    I always bundle my Shared Projects in a dll, for instance a .NET Core 1.1 class library or a .NET Framework class library. Then I reference that dll to my test project. Considering how tests themselves tend to depend on specific versions of libraries, I haven't tried actually sharing a test between two libraries. Anyway, hope you report your findings to Microsoft using the built-in reporting tool - they've just fixed an issue in the latest release that I reported earlier, where you couldn't remove a Shared Project reference using Visual Studio (had to do so in the project file instead) – Arwin Feb 10 '17 at 13:45
4

It seems like this isn't possible - I've been trying to find out how to do it today! The best that I've found comes from this SO question:

How can I use xproj (asp.net/dotnet core project) with shproj (shared project)?

What I'm taking away from it is that I can create Shared Projects that can be referenced directly by NET45/46 class libraries but which will have to be pulled into .NET Core projects using a project.json-based workaround, by adding the following "buildOptions" -

"buildOptions": {
  "compile": {
    "include": [
      "../../TesterShared/**/*.cs"
    ]
  }
}

In the example above, my shared project is called "TesterShared" and Visual Studio has created that in the root of the solution - unlike the .NET Core projects which it creates within a "src" folder (hence the double "../" parent path navigation).

Community
  • 1
  • 1
Dan Roberts
  • 2,244
  • 16
  • 31
  • If that works, that's something I could live with for the time being! Then hopefully the next Visual Studio update will fix this. – Arwin Nov 06 '16 at 14:39
  • 1
    I hope so too! Since project.json is apparently being replaced with a different kind of .csproj file, maybe they'll do it then. I've been using this approach so I know it works ok but there are some limitations.. I wanted to include a ".sqlite" database file in the shared project and have had problems with that (there's "copyToOutput" options which can nearly achieve what I want, but not quite). Also, if you edit files in the shared project then you need to force a rebuild of your .NET Core project - it won't realise that changes to the shared project require a rebuild. – Dan Roberts Nov 06 '16 at 15:42
  • Ah, those are some annoying limitations indeed. So basically Visual Studio doesn't really know that the Shared Project was linked, but at least will compile it. As for the SQLLite thing, I consider those mostly Client specific. I strive to have zero dependencies in my Shared Projects and would have them define interfaces for everything external that can be injected in the constructor. I will accept your answer, thanks again. – Arwin Nov 07 '16 at 06:12
  • The information that @Arwin has added as an answer is better now - the final version of VS2017 has support for Shared Projects and it works perfectly; references from .NET Framework projects and .NET Core projects work nicely. – Dan Roberts Jun 14 '17 at 18:36