What is the difference between a Shared Project and a Class Library in Visual Studio 2015?

Question

I was looking at the new features for Visual Studio 2015 and Shared Project came up a lot but I don't understand how it is different to using a Class Library or a Portable Class Library. Can anyone explain?

Edit: Shared Project is a new feature in Visual Studio 2015 and is different to a Portable Class Library. I understand what a Portable Class Library is. What I'm trying to understand is how a Shared Project differs to a Class Library. See link below.

http://www.c-sharpcorner.com/UploadFile/7ca517/shared-project-an-impressive-features-of-visual-studio-201/

Linell

See: different between class library and portable class library in visual studio – Columella

Answer 1

The difference between a shared project and a class library is that the latter is compiled and the unit of reuse is the assembly.

Whereas with the former, the unit of reuse is the source code, and the shared code is incorporated into each assembly that references the shared project.

This can be useful when you want to create separate assemblies that target specific platforms but still have code that should be shared.

See also here:

The shared project reference shows up under the References node in the Solution Explorer, but the code and assets in the shared project are treated as if they were files linked into the main project.

---

In Visual Studio 2012 and earlier versions, you could share source code between projects by Add -> Existing Item and then choosing to Link. But this was kind of clunky and each separate source file had to be selected individually. With the move to supporting multiple disparate platforms (iOS, Android, etc.), they decided to make it easier to share source between projects by adding the concept of Shared Projects.

Asphaltite

Let's say two projects that reference the same shared project. If one of those adds a reference to the other, do you get duplicate type declaration errors? – Danais

@Asad - I haven't checked, but I'd expect not. You can have two distinct types, with the same names, and declared inside the same namespaces but existing within different assemblies. That is not an error, per se. – Asphaltite

I had the exact same question as the OP in 2017 but since we have .net standard 2.0 now. Isn't shared projects now obsolete? If you would create a brand new webapp or uwp app today? – Aloisius

@JPHellemons - .net standard is good - but if you need to go outside of that for any reason (e.g. if there is functionality only available on specific platforms) then a Shared Project could still be a decent approach. – Asphaltite

Thank you for your update! The landscape is moving fast so it's nice to see how this holds up in 2017 and if the accepted answer is still valid. – Aloisius

We say with a Shared project we can share Javascript files. How do we use that in a bundleConfig? – Orthoptic

@Orthoptic - that sounds like a distinct question - if it's not already been covered on StackOverflow, please ask a new question. – Asphaltite

so in this case if librarry projects reference a shared project i guess when performing an update on the shared project you also have to update ALL the assemblies that use the shared project? coming from a financial project that has over 300 librarries that could be a huge mess ! O_O – Alow

I've just tried this and like it for generating single assemblies when you need this, for example in class libraries. Note that you don't add References to the Shared Project directly; you add them to the linking project(s). – Siemens

Bear in mind that C# SharedProject will not be visible when trying to add reference in C++/CLI .Net project - obvious - C++ compiler can't compile C# code. But you can add reference to C# library. – Arnulfoarny

Answer 2

I found some more information from this blog.

• In a Class Library, when code is compiled, assemblies (dlls) are generated for each library. But with Shared Project it will not contain any header information so when you have a Shared Project reference it will be compiled as part of the parent application. There will not be separate dlls created.
• In class library you are only allowed to write C# code while shared project can have any thing like C# code files, XAML files or JavaScript files etc.

Linell

a class library can have .xaml as well (User Controls) – Forestall

Answer 3

Class library is shared compiled code.

Shared project is shared source code.

Midgett

Nailed it, the only significant difference. Wanting to understand a "Shared project" type is almost more easily answered by this and a question: a WPF project and a WinForms project have 10 classes that they both need, how do you achieve that without duplicating code or binaries - a shared project is practically the only way – Brigitte

Answer 4

Like others already wrote, in short:

shared project
reuse on the code (file) level, allowing for folder structure and resources as well

pcl
reuse on the assembly level

What was mostly missing from answers here for me is the info on reduced functionality available in a PCL: as an example you have limited file operations (I was missing a lot of File.IO fuctionality in a Xamarin cross-platform project).

In more detail
shared project:
+ Can use #if when targeting multiple platforms (e. g. Xamarin iOS, Android, WinPhone)
+ All framework functionality available for each target project (though has to be conditionally compiled)
o Integrates at compile time
- Slightly larger size of resulting assemblies
- Needs Visual Studio 2013 Update 2 or higher

pcl:
+ generates a shared assembly
+ usable with older versions of Visual Studio (pre-2013 Update 2)
o dynamically linked
- lmited functionality (subset of all projects it is being referenced by)

If you have the choice, I would recommend going for shared project, it is generally more flexible and more powerful. If you know your requirements in advance and a PCL can fulfill them, you might go that route as well. PCL also enforces clearer separation by not allowing you to write platform-specific code (which might not be a good choice to be put into a shared assembly in the first place).

Main focus of both is when you target multiple platforms, else you would normally use just an ordinary library/dll project.

Trilinear

Answer 5

In-Short Differences are

1) PCL is not going to have Full Access to .NET Framework , where as SharedProject has.

2) #ifdef for platform specific code - you can not write in PCL (#ifdef option isn’t available to you in a PCL because it’s compiled separately, as its own DLL, so at compile time (when the #ifdef is evaluated) it doesn’t know what platform it will be part of. ) where as Shared project you can.

3) Platform specific code is achieved using Inversion Of Control in PCL , where as using #ifdef statements you can achieve the same in Shared Project.

An excellent article which illustrates differences between PCL vs Shared Project can be found at the following link

http://hotkrossbits.com/2015/05/03/xamarin-forms-pcl-vs-shared-project/

Dantedanton

Answer 6

From the book VS 2015 succintly

Shared Projects allows sharing code, assets, and resources across multiple project types. More specifically, the following project types can reference and consume shared projects:

• Console, Windows Forms, and Windows Presentation Foundation.
• Windows Store 8.1 apps and Windows Phone 8.1 apps.
• Windows Phone 8.0/8.1 Silverlight apps.
• Portable Class Libraries.

Note:- Both shared projects and portable class libraries (PCL) allow sharing code, XAML resources, and assets, but of course there are some differences that might be summarized as follows.

• A shared project does not produce a reusable assembly, so it can only be consumed from within the solution.
• A shared project has support for platform-specific code, because it supports environment variables such as WINDOWS_PHONE_APP and WINDOWS_APP that you can use to detect which platform your code is running on.
• Finally, shared projects cannot have dependencies on third-party libraries.
• By comparison, a PCL produces a reusable .dll library and can have dependencies on third-party libraries, but it does not support platform environment variables

Vespasian