3

Sorry for asking this naive question which is even difficult for me to describe. I have a classlibrary project say 'A' that has logic that I am referring in Project 'B' via Assembly reference (added the dll reference of Project 'A') which is basically an unit test project. Project 'A' uses some third party assemblies like Serilog, Newtonsoft. So now in an Unit test in Project 'B' when I invoke the methods of a class from Project 'A', I see my test fails with file not found exception and its referring the assembly files like Serilog and NewtonSoft which were there in project 'A'. So I was puzzled that my project 'B' doesn't need any of those libraries directly, only project 'A' needs them. But still to remove the error one by one I added the same assembly references in Project 'B' as well and it resolved the error.

But I didn't understand why I needed to add the same assemblies again in Project 'B'. This kind of defies the purpose where I am trying to abstract the logic in separate project so that other projects doesn't have to repeat the same thing? With this logic now every other unit test project that I am going to write in future referring the Project 'A' would require the same kind assembly reference which appears to be an overhead.

If this is relevant: My class library project 'A' is a .NET Standard 2.0 based project and project 'B' is a .NET Core 2.1 console application type of project.

If this is a repeated question please direct me, I want to understand how this works. If there is a C# concept behind this behavior please let me know and I will read more on it. Also does this behavior varies based on the type of 3rd party library we are using like if its logging vs any other type of library?

Thanks in advance!

Vikas
  • 404
  • 5
  • 18
  • 1
    This is a known limitation in the current tooling support for .netstandard. It just isn't smart enough to know to copy dependent .netstandard assemblies as well. It was supposed to get fixed in VS2017 but that didn't happen. A new milestone was set to get this work done, its title is "Unknown". The workaround you found is the correct one right now. – Hans Passant Jun 16 '18 at 21:58
  • Thanks Hans for your quick response. I am glad to know that this is a tooling problem not with the way I was using this. :) Hopefully this will be fixed soon. Thanks once again. – Vikas Jun 16 '18 at 22:03
  • I thought i was playing with core and a standard the other-day, and all nugets were not only copied but natively callable without issue and i had to especially flag the dependencies so they weren't – TheGeneral Jun 17 '18 at 00:00
  • Thanks TheGeneral for your response. But unfortunately that is not what I experienced with the 3rd party libraries I was using. I also did update my vs2017. Not sure if its relevant but my project 'B' is a xunit project. – Vikas Jun 17 '18 at 06:32
  • Can you take a look at this answer? It sounds like it might be the same issue. https://stackoverflow.com/questions/50771569/incompatible-net-standard-assemblies-that-should-have-been-compatible – Alex Ghiondea - MSFT Jun 18 '18 at 22:23
  • Hi Alex it does sound like same problem of dependencies not being copied between .NET standard and .net core console application. I tried the first solution but it didn't help. So I am using the 2nd option of adding the dlls directly. Hope this issue is sorted soon. – Vikas Jun 19 '18 at 04:50
  • Would you mind sharing the solution for which the first option did not work? I am glad that the second option is working for you! – Alex Ghiondea - MSFT Jun 19 '18 at 23:36
  • I can try to create a small sample app to reproduce this issue. Say if I can reproduce where I can upload the solution? – Vikas Jun 20 '18 at 05:00
  • Can you create a repo in GitHub and put the solution there? – Alex Ghiondea - MSFT Jun 20 '18 at 05:37

0 Answers0