Let's say my solution has 2 projects:
The first called "MainProject" (A .NETStandard 2.0 project).
The second called "MainProjectTests" (A NUnit test project) with some unit tests for each class into "MainProject".
The first project (MainProject) has a NuGet dependency called "dependencyX". Obviously, the project "MainProjectTests" has a reference to "MainProject".
So when the test runner runs a test of "MainProjectTests" that calls methods from "MainProject" using "dependencyX" I'm getting a System.IO.FileNotFoundException exception:
System.IO.FileNotFoundException : Could not load file or assembly
'dependencyX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one
of its dependencies.
Why am I getting this exception? When I add "dependencyX" to "MainProjectTests" all works fine, but it seems to me not a good practice... How to solve it?
I'm using Visual Studio for Mac Community 7.2 preview (7.2 build 583)
Thanks for the help.
EDIT:
Tried putting the options:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
in the NUnit project, but getting the same result.
This seems to be a known bug regarding .NET Standard libraries (and maybe especially in conjunction with NUnit). I already filed a bug report here which seems to confirm that this is not the intended behaviour. Altough there has been no progress for over half a year.
Maybe one should file a bug in the NUnit repo after confirming this only happens when using NUnit.
For the time beeing you'll need to reference all libraries used in a .NET Standard project also in all projects referencing the .net standard one as you are doing right now.
It is a bug reported to Microsoft few times and it seems they did not do much on this, look at this Visual Studio does not copy referenced assemblies through the reference hierarchy
On the other hand at least with Nuget Packages you have a simple way (to add the same package to multiple projects in the same solution) using the package manager for the solution, as you can see here Nuget Package Manager.
Related
I have a vsix project. I use commandtool and create files. I upgraded .net framework (4.6.1 to 4.7.2) and packages
I run project, everything is ok. But I get error when I click Extension's button.
I checked error in XML file. Error description is
Description: Could not load file or assembly Microsoft.VisualStudio.Threading, Version=16.8.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; or one of its dependencies
But there is package in References
Do you have any idea?
Best Regards
When you upgraded to the newer version of Microsoft.VisualStudio.Threading, you upgraded to a version that's higher than what your Visual Studio is shipping with as a part of the platform. Although there are ways you could make your version now be the preferred version, the easiest answer is probably 'don't do that', since you're artificially limiting which versions of VS your extension could install onto.
Unless you had a specific reason to upgrade, you're probably best off leaving the version there.
Background: I developed a .NET Standard 2.0 Nuget package (local) for a class library with a dependency on Microsoft.Extensions.Configuration, Version=2.1.1.0. It passed unit tests and ran fine when invoked from a .NET Core 2.0 console app. However, when I added my package to an Azure Function project it caused an exception to be thrown whenever I attempted to run the azure function from the VS2017 debugger.
System.Private.CoreLib: Could not load file or assembly 'Microsoft.Extensions.Configuration, Version=2.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Question: How can I fix the problem?
Copied from OPs question:
Answer: The problem goes away when I downgraded to Microsoft.Extensions.Configuration, Version=2.0.0. in my package, republished it and then reinstalled it in my Azure Function. This seems to be another example of the packages-dependency-crisis. The Nuget package manager should have caught any dependency problems with v2.1.1 when my package was added to the Azure Function project, but it didn't so it only became apparent at runtime. This is sub-optimal.
I provide the above information in the hope that others will not waste a day tracking down the same issue. It also raises the question as to how you decide what version of a package to add. Clearly in the case of Microsoft.Extensions.Configuration adding the latest stable version isn't always the best idea.
I know this is an older question but ran into the same issue downgrading a project from 2.2 to 2.1. And removed the user of ASPNetCore.All to ASPNetcore.App. This showed me how many packages we really had to depend on, as well as this issue eventually came up. My error came from the Usersecrets retrieval. Since I was missing: Microsoft.Extensions.Configuration.UserSecrets
hope this can help someone like me who was stuck on this. Should have known it would be a missing package.
The setup is like this:
A Xamarin.Android application, which depends on Android class library
(at least that's what the template is called in VS)
Said class
library, the purpose of which (not entirely relevant, but FYI) is
interfacing with a REST service and has a dependance on the famous
Newtonsoft.Json NuGet package.
An NUnit test project for said
library.
IDE is Visual Studio 2017, latest version.
If you build and deploy the app on the phone, everything is fine.
However, if you try to run tests from the tests project, it says that it can't find the Newtonsoft library.
I've even managed to find a sort of reason: when the library gets built, it's dependancies aren't packed inside, and they are not copied to build directory.
When .apk is built for the phone, the dependancies ARE getting packed inside.
However, when NUnit project builds itself, it only takes the library, and the dependancies are nowhere to be found.
However, there's no interface to control the behaviour of NuGet "Package Reference" type dependencies (blue ones), the properties window is empty for them. And I found no way to add NuGet packages to this kind of project as a ".config" type of dependancy (grey one).
There is a workaround - you can add the Newtonsoft package to the NUnit test project, then it gets copied to the build directory and the Android library works with it, however it doesn't feel right to me. Tests don't need that reference and it has no business in that project.
How to control NuGet packages in Android Class Library?
Your workaround is the correct solution, you don't need to worry too much about it.
That is because the Newtonsoft package is not used directly in your NUnit test project, so Visual Studio / MSBuild doesn't know if your test project needs this Newtonsoft library. In order to avoid reference pollution in NUnit test project, Visual Studio / MSBuild tries to only bring references over into NUnit test project that it detects as being required by project Xamarin.Android application.
So, to resolve this issue, we often add Newtonsoft to the test project or give a copy task to copy it to the test project.
See This Thread for some more details.
Looking for an answer to another question I now found info that my described behaviour is a known problem, described by .NET developers here:
https://github.com/dotnet/standard/issues/481
I've got a Solution with lots of projects and all but one of them is behaving. The one that is not working is a ConsoleApplication, and it relies on C# Class Library project. I've added a reference to the library project, and add the namespace (which I've checked is correct), but everywhere I reference the classes in my library, I get:
The type or namespace 'MyClass' could not be found (are you missing a using directive or an assembly reference?).
The library project is building successfully (I can see the DLLs appear in the bin folder) and I've tried a project reference, and also a reference to the DLL itself. Neither works.
Also, all projects are set to build with a platform target of 'Any CPU'.
I've tried pretty much every suggestion I've come across on forums with no success. Can anyone shed some light on what's going wrong?
Thanks
This solved the problem:
The console application had a Target framework of .NET Framework 4 Client Profile, whereas the library just had .NET Framework 4. I set the console app to .NET Framework 4 and it all builds perfectly.
My bet is on a framework mismatch between your library and you app...
Check if your library is not building with a superior version than you app, or if your app is building with a Client profile flavor
It is probably that one of your DLLs references some part of the .net framework that is not referenced in your console application. For example if one of your class library projects has asp.net server controls in and references System.Web, but your console application does not reference System.Web it will not build and you will get that error. But it is not obvious because the DLLs referenced are stored in the GAC so they would never appear in your bin folder.
I had to simply restart visual studio for reference to work but make sure you have reference added in .csproj file.
If you still experience the issue, make sure the class you're referencing is public and that Asp.net core Framework version match.
Sounds weird,
Have you tried to remove the reference of the project and add it again? Check if your console app has got all the right references.
You could also inspect the .csproj file and see if everything is correct in there.
Just Check that you "Class Library" project has classes in it or if it is a data access layer project which include only a .edmx Model check the Model designer is found and it generates fine.
Good Luck
I worked with syncing the framework, but still, it was giving issue.
So I tried another way.
Right-click on the dependency, and select Add project reference. I added the required project then the error was gone.
This is a weird one.
I created a new Windows Service in C#, and want to re-use some of the code we created before that's in a Class Library.
The project is loaded in the solution along with the service. Both target .NET Framework 4.0 (not client profile).
I tried adding a project reference, and it worked for a short while. After working on some old code that I was rewriting, when the project compiled again, it complained that it no longer recognised the namespace for the using statement.
I've made sure to clean the solution & rebuild, but no dice. Sometimes VS can have a bad day, so I restarted VS, but this also didn't work.
I then build the DLL, and add a reference to it via 'browse', also no dice. Then I tested it on another project, but after adding it, it works instantly, so it's not the DLL.
I then checked with other libraries in the solution, but I was able to add a reference to them in the service and access their namespace without a problem.
I'm out of ideas here, anyone got an idea of what to do here?
Thanks,
Nick.
Almoast forgot: the weird thing is, that if I open up the Class view, and expand the 'References' section, the namespace/dll doesn't show up there either... it's a real conundrom...
I should pay more attention to warnings:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3253: The referenced assembly "" could not be resolved because it has a dependency on "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.
So, I'm a ready idiot for checking the DLL's target framework but not the Windows Service :)
The problem is my DLL uses System.Web, which is not part of the .NET 4 Client Profile framework target. Changing the Service's Target Framework to 4.0 fixed it.
If the class view doesnt show the types that should be there, the actual dll you're compliling against is not the correct version.
There could be several reasons for this
A previous compilation of the dll might still be around
The project might reference another, older, binary version of the library rather than having a project reference
Another project mgiht be referencing an old version of the dll, and have copy local set to true. When that project is compiled it overwrites the new version of the library
Make sure all projects in the solution use project references, and remove all binaries you can find.