0

I am using Visual Studio Community 2015. I have one executable c# project which references two different dll projects and these two dlls are referencing the same shared project. It worked this way. I mean I could build that executable project but today after pulling latest commits (I think it shouldn't be a reason) I cant build the executable project because of an error

Error CS0433 The type 'TypeDefinedInSharedProject' exists in both 'DllProject1, Version=2016.1202.6180.26482, Culture=neutral, PublicKeyToken=SomeKeyToken' and 'DllProject2, Version=2016.1202.6180.26481, Culture=neutral, PublicKeyToken=SomeKeyToken'

I think that the .cs file where TypeDefinedInSharedProject type is declared is somehow linked to the project at build time and I suppose that if I change type of that shared project to class library project I will be able to build executable project. I had similar problem earlier and I solved it this way. I can do this now but I am just curious why it worked earlier but now doesn't. What can be a reason of it?

Aleksandre Sukhitashvili
  • 132
  • 13
  • I guess you Co-Workers did compile one of your two "dll Projects" with a newer Version of the 3rd shared project - if you got a assembly Auto Inkrement, the Version is different - at least the `26482 / 26481` seems like this. So I'd suggest you build DllProject2 again - this should solve your issue. (in .csproject the shared project will be defined different - this is why your compiler complaines) – TripleEEE Dec 02 '16 at 11:24
  • @TripleEEE Yes I have set auto increment but this doesn't necessarily mean that the this revision numbers '26482 / 26481' should be the same because these represent time when project was built (and it changes in every 2 seconds) and these projects can't be built in parallel – Aleksandre Sukhitashvili Dec 02 '16 at 11:39
  • Well but this is what the compiler complains about - that both of you dll.projects refer to an different Version of the same shared-project. Check this maybe: http://stackoverflow.com/questions/4381195/3rd-party-libraries-refer-to-different-versions-of-log4net-dll/4381340#4381340 there you can find a solution maybe, it's for log4net but it is the same issue you have. – TripleEEE Dec 02 '16 at 11:53
  • I think it is not the case either, because that may be fixed with assembly binding redirection in app config file. My current problem is not about assembly versioning. It's about just one shared file which is considered as two different files (with similar content) by a compiler – Aleksandre Sukhitashvili Dec 07 '16 at 15:57

0 Answers0