I'm trying to use NSubstitute in my Unity project (Unity version 2019.2.2f1). No matter how to import it, my IDE, both Visual Studio and JetBrains Rider, would give an error when I try using NSubstitute saying NSubstitute is undefined.
I have tried many options and versions of NSubstitute packages (4.2.1 and 2.0.3). I also import the dll file from net35 folder of the package into a Plugins folder in my Unity project. I also tried to install the same version of NSubstitute using Nuget in the IDE.
I added NSubstitute 4.2.1 (.NET Standard 2.0) in a Unity project, but I needed to include 3 more dependencies for it to work:
system.threading.tasks.extensions.4.5.3
system.runtime.compilerservices.unsafe.4.6.0
castle.core.4.4.0
Update 2020
If you read this in 2020 or later, check the answer from Rodrigo Eleuterio how to make this work with the latest version of NSubstitute.
/end update
I was able to make the 2.0.3 version work with Unity. The newer versions have additional dependencies which I could not make work in Unity, so it seems for now we're stuck with 2.0.3. So here is how I did it:
Download 2.0.3 from the NuGet Website.
Unzip the file and move the lib/net35/NSubstitute.dll into the Plugins folder of your project.
In your test assembly definition, don't forget to reference it, otherwise it will not be found.
When you now reopen the project in Rider it should be found. Sometimes Unity acts up a little and doesn't seem to find the DLL. In this case re-importing the project can help.
Related
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 have a solution with two projects - a primary project, and a unit test project. When opening in Visual Studio 2015 all references are found and project builds successfully. When opening in Visual Studio 2017 several but not all NuGet package references are not found and compile fails. Some of the failed references are...
System.Data.Common
System.Net.Http
System.Net.Http.WebRequest
System.Security.Cryptography.Algorithms
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates
... but other NuGet references are found with no problem. This solution was created with VS2015. When viewing the .csproj file nothing out of the ordinary is jumping out.
I am thinking of rebuilding it from scratch in VS2017 to try to identify the problem.
Has anyone else experienced this problem, and/or has anyone any suggestions on why this is occurring and what should be done to facilitate a fix?
Update:
I created a brand new VS2017 WebApi project referencing .NET 4.7.1, and compiled successfully. I then added NuGet package System.Data.Common 4.3.0. The NuGet install process appears to have completed with no errors, but still I am left with an invalid reference. That was pretty easy to replicate.
OK, answering my own question.
I found what I believe is the answer. This particular project was originally developed in VS2015 using .NET 4.6.2. When changing to VS2017 we elected to upgrade .NET to 4.7.1. The problem is with the .NET version, not the VS version.
The newer version of .NET has many of these NuGet assemblies added to standard libraries. The NuGet packages were in conflict with the native .NET 4.7.1 namespaces. For example, in .NET 4.7.1, the namespace System.Data.Common is found in the assembly System.Data.dll. No longer is it required to add a NuGet assembly System.Data.Common.dll. In fact, if I do add System.Data.Common NuGet package assembly, I now have two assemblies having the namespace System.Data.Common - one in System.Data.dll and another in System.Data.Common.dll - hence the reference problem.
The solution is to use the .NET 4.7.1 version and remove the extra NuGet assembly. This was also true for System.Security conflicts. The conflict with System.Net.Http was actually moved into a NuGet assembly called Microsoft.AspNet.WebApi.Client.
I hope all of this helps someone else...(uhhhgggg)....
BTW - it appears that when using VS2015 with .NET 4.7.1, these conflicts are suppressed and never display. This feels like a shortcoming of VS2015. Glad VS2017 shows them to reveal the true problem...
Check your packages.config file to make sure the Nuget packages are actually listed as dependencies for your project.
Also, open the solution in VS 2015 and double check the file path for the references in question. Make sure the DLLs are not referenced from a file path unique to Visual Studio 2015.
I had to create a new project and transfer all the necessary files from the old project to new project to fix this.
I'm attempting to write tests with NUnit3 as part of some tech-debt migrations. I created a new project within an existing solution. Using nuget I added NUnit and NUnit.Console as per the instructions on github. (I also added the NUnit 3 Test Adapter extension to Visual Studio 2015, but I'm fairly sure that has no bearing on my current situation).
After adding the nuget packages I attempted to import the TestFixture attribute, however, visual studio isn't recognizing the NUnit.Framework namespace and I can't import anything.
The only thing I could thing to fix it was to add the reference manually. There too I was blocked by NUnit not being available.
I'm somewhat at a loss as to how to move forward. How do I proceed and fix the missing reference?
Update: The project I created was of type Unit Test Project, however I've gone ahead and create a Console Application and Class Library. I attempted to add NUnit via nuget to each of them and all of them have had the same result.
Update: Other nuget dependencies seem to install correctly with no discernable difference.
This is only a pseudo solution, as I don't know what the actual issue is. If anyone else comes across a better fix than my work-around I'll be glad to select it if it works for me down the line.
At the time of this writing, the latest version is 3.4.1. I forced nuget to downgrade to 3.4.0 for both the packages NUnit and NUnit.Console and violà the namespace is available as you'd expect any nuget package.
I'm trying to use R with C#. I'm using Unity and MonoDevelop on the C# side and I've R version 3.2.1. I've tried my best to follow instructions here: http://jmp75.github.io/rdotnet/getting_started/
But I'm stuck. Here's what I've done
download nuget.exe, put it in a folder already in PATH.
open CMD.exe
run nuget install R.NET.Community
If I try to reinstall R.NET.Community with the same command above, I got the message that it is already installed (which is good I guess).
My question : what now? I tried to run the RDotNet namespace, but it's not recognized. Obviously I need to set up something else, but I do not know where and what. Any lead would be appreciated!
I wouldn't expect just running the nuget install to add a reference into your project - the nuget installer is basically just downloading the package for you.
You could manually add a reference in your project to the relevant assembly file (.dll) that has been downloaded. However, it would be better to use a package manager within MonoDevelop. If you're using MonoDevelop 3.x or 4.5, you should use the NuGet MonoDevelop add-in and use that to manage the NuGet packages for your project. MonoDevelop 5.x has a NuGet package manager built in, apparently.
There is a project that wraps V8 engine into C# library. Its nuget package is broken and i'd like to fix it. Creating a package seems easy and there is documented way to pack different C# dlls for different .NET versions. However, i have no idea how to package .dll with C++ and C# code which could be built with different options:
x64 or x86 and not "Any CPU"
MS Visual C++ 2010/2012/2013
debug or release
.NET 4.0/...
I've found this thread and it seems that one can use .targets file with MSBuild commands inside. Then i've read in the docs that MSBuild way is old and not recommended. So what should i do?
One more question is: if this package depends on MSVC++, how to specify this? How to let package consumer select a specific version of dll (built against MSVC++2010, 2012 or 2013)? I suppose it is not a good idea to package msvcr*.dll.
Take a look at how the SQLite packages deploy their DLLs. With the 2.x and earlier versions of NuGet you need to write some powershell code to inspect the version of Visual Studio and apply your changes to the project manually.
We are working towards a more elegant solution for this exact problem with the updates that are to be deployed in NuGet v3