Referencing shared project in several projects of solution
Asked Answered
D

3

6

I am trying to fix warning

Warning CS0436: The type 'Class1' in '...\SharedProject1\SharedProject1\Class1.cs' conflicts with the imported type 'Class1' in 'ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in '...\SharedProject1\SharedProject1\Class1.cs'. WpfApplication1 ...\SharedProject1\WpfApplication1\MainWindow.xaml.cs

Repro:

  • create solution with 3 projects:

SharedProject1 (add new class to it)

namespace SharedProject1
{
    public class Class1() { }
}

ClassLibrary1

namespace ClassLibrary1
{
    public class Class1 { }
}

WpfApplication1 (add this to MainWindow constructor)

public MainWindow()
{
    InitializeComponent();
    var a = new SharedProject1.Class1();
    var b = new ClassLibrary1.Class1();
}
  • reference SharedProject1 in both ClassLibrary1 and WpfApplication1;

  • build, you will get a warning.

Question: how to fix the warning?

Declass answered 14/4, 2016 at 9:10 Comment(0)
T
5

Change the dependency schema from:

Shared -> Class
Shared -> Application

to:

Shared -> Class -> Application

That is: remove from Application a direct reference to Shared.

The first schema results in same class built into 2 dlls. That's what causes the conflict. In the second schema the shared library is built into Class dll and thus is also accesible to Application.

The first schema would be ok, if Class and Application were independent of each other.

All of this is because a shared project does not generate a library. So one must think about making it appear somewhere in a library. Usually only in one place. That usually means, that each shared library should be referenced only once.

Toxophilite answered 14/1, 2017 at 20:47 Comment(0)
L
3

Jarekczek's solution works fine when you have only one class library, but as soon as you add another class library which also references the shared project, you get the same warning again.

The solution might be obvious, but if it's not here it is...

You could create one more ordinary class library project named 'Common' which doesn't contain any classes on it's own, but only references shared project. It serves as a 'container' for shared code.

So reference tree could look like this:

SharedProject -> Common
Common -> ClassLibrary1
Common -> ClassLibrary2
ClassLibrary1 -> Application
ClassLibrary2 -> Application
Common -> Application
Lenitalenitive answered 19/4, 2017 at 13:51 Comment(4)
In other words you suggest to convert shared project into class library. I can't disagree. Shared projects are meant to be used in different assemblies, as soon as you start thinking to include them into dlls - say to shared projects NO, convert them into dlls and reference those.Declass
I did't say to convert them into dlls. There is nothing preventing you to include them directly from other solutions. I'm posting a possible solution for conficts which occur when multiple class libraries are referencing the same shared project in the same solution. Shared project is still there, untouched.Lenitalenitive
"Shared project is still there, untouched" - only wrapped into common.dll and should not be ever used by anything else.. sounds exactly as converting to me ;)Declass
We have a windows forms application with multiple dlls + xamarin app. Windows app and its dll's are accessing the shared code through the common dll. Xamarin is referencing the same shared project directly, and it works perfectly.Lenitalenitive
P
0

Try to change your code as :

       namespace SharedProject1{public class Class1() { }}

In your project WpfApplication1 you must add references to SharedProject1 and ClassLibrary1 ,it hork after that :

I have create a project for you with your specefication :

Project exemple

Pastose answered 14/4, 2016 at 9:19 Comment(1)
Thanks for correcting typo I did when posting question. The problem is however still.Declass

© 2022 - 2024 — McMap. All rights reserved.