I have the following setup:
Solution N1 -> .net 3.5, Ninject 2.2
Solution N2 -> .net 4.5.2, Ninject 3.2
I added a project from Solution N1 to Solution N2 and then generated fakes for the project that uses Ninject 2.2.
In vs, the fakes generation succeeds.
In MsBuild (and in TeamBuild) I get the following error:
C:\Somepath\Fakes\SomeProj.fakes: assembly C:\Somepath\SomeProj.dll failed to load properly Could not resolve assembly 'Ninject, Version=2.2.0.0, Culture=neutral, PublicKeyToken=6b7e450ec5ed63ad'. Are you missing an assembly reference?
So my tests are not working on build, even though I selected vs test runner (not msbuild) for running tests.
Unfortunately I can not update Ninject in Solution N1 for some external reasons.
In production the app works as I have Ninject remapped to 3.2.0.0 and it works.
Any idea how to make fakes either load 3.2.0.0 (without referencing in SomeProj) or just ignore that code? (I tried specifying the stubs and shims that I need explicitly, same error in MsBuild).
So what I did in the end was add the old Ninject to the repo, and then referenced it like so inside .fakes file:
<Compilation>
<Reference Path="RelativeToCsProjFolder\Ninject.dll" FullName="Ninject, Version=2.2.0.0, Culture=neutral, PublicKeyToken=6b7e450ec5ed63ad"/>
</Compilation>
What got me a bit was the relative path syntax in this path.
Related
I am doing a unit test with NUnit and i want to integrate it into azure devops.
When i run the test locally in visual studios with test explorer,
the tests are able to run properly without failure.
However, when i build it on azure devops, i encounter the problem of NUnit failing to load the MSTestAdapter and MSTestFramework Dlls or it being unable to find MSTestAdapter/MSTestFramework dlls.
Initially when i looked through, i thought it was because my processor architecture did not match.Thus i tried to create a runsettings file and change the test platform to x64 for NUnit to match the test.
However, it still didnt work and gave me the same error message (will be shown below)
code in Runsettings file which i have tried :
```` <RunSettings>
````<!-- Configurations that affect the Test Framework -->
```` <RunConfiguration>
````<TargetPlatform>x64</TargetPlatform>
```` <TargetFrameWorkVersion>Framework45</TargetFrameWorkVersion>
```` </RunConfiguration>
```` </RunSettings>
Just a part of the error messages
The error message is what i get at the VSTest part in azure devops when i build my project
(the messages are all similar) :
Multiple versions of same extension found. Selecting the highest version.
Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter : 14.0.2505.1
Input string was not in a correct format.
Could not load type 'Microsoft.VisualStudio.TestTools.UnitTesting.ExecutionScope' from assembly 'Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load type 'Microsoft.VisualStudio.TestTools.UnitTesting.ExecutionScope' from assembly 'Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Unable to load types from the test source 'd:\a\1\s\MSTest.TestAdapter.1.3.2\build\_common\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll'. Some or all of the tests in this source may not be discovered.
Input string was not in a correct format.
Unable to load types from the test source 'd:\a\1\s\MSTest.TestAdapter.1.3.2\build\uap10.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll'. Some or all of the tests in this source may not be discovered.
Input string was not in a correct format.
NUnit Adapter 3.12.0.0: Test execution started
Running all tests in d:\a\1\s\HeyX.UnitTest\bin\Debug\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.dll
NUnit failed to load d:\a\1\s\HeyX.UnitTest\bin\Debug\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.dll
Running all tests in d:\a\1\s\HeyX.UnitTest\bin\Debug\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll
NUnit couldn't find any tests in d:\a\1\s\HeyX.UnitTest\bin\Debug\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll
Running all tests in d:\a\1\s\HeyX.UnitTest\bin\Debug\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.dll
NUnit couldn't find any tests in d:\a\1\s\HeyX.UnitTest\bin\Debug\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.dll
What is the framework version and visual studio version of the NUnit project?
In the "visual studio test" task, you can select the visual studio version.
Maybe the version of the NUnit Project is higher than the version of the task.
You can specify the path of the vstestconsole if that is the case.
The error indicated “Could not load type 'Microsoft.VisualStudio.TestTools.UnitTesting.ExecutionScope' from assembly 'Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0 …”
As 'Microsoft.VisualStudio.TestTools.UnitTesting.ExecutionScope' only applies to MSTest.TestFrameWork.1.3.2 or higher. Your test project might reference to the wrong assembly.
Both of the package MSTest.TestAdapter.1.3.2 and package Microsoft.VisualStudio.TestPlatform.14.0.0 have Microsoft.VisualStudio.TestPlatform.TestFramework assembly. But only the one in package MSTest.TestAdapter.1.3.2 have 'Microsoft.VisualStudio.TestTools.UnitTesting.ExecutionScope
You can try to point your “Microsoft.VisualStudio.TestPlatform.TestFramework” reference to the folder where MSTest.TestFramework.1.3.2 resides in your test csproj file.
In my own .net framework test project I changed the value of tag "HintPath" which resides under tag "reference Microsoft.VisualStudio.TestPlatform.TestFramework….." like below:
<Reference Include="Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\MSTest.TestFramework.1.3.2\lib\net45\Microsoft.VisualStudio.TestPlatform.TestFramework.dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\MSTest.TestFramework.1.3.2\lib\net45\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.dll</HintPath>
</Reference>
Apparently there was something wrong with my visual studios. Not very sure which part of my vs it was that affected my testing, but after reinstalling vs and building from scratch, i am able to build on devops without any error.
The Problem
The Microsoft.Win32.Registry nuget package is giving me a lot of issues . We had .NET Framework 4.7.2 library that had a helper class that used that package and worked fine from a .NET Framework 4.7.2 unit test project. We recently converted the library to target .NET Standard 2.0, and now this class breaks when used with the following error:
ERROR: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Win32.Registry, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.Win32.Registry, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at NetStandardRegistryLib.RegistryUtil..ctor(String remoteMachineName)
at NetStandardRegistryLib.Program.Main(String[] args) in C:\src\Microsoft.Win32.Registry-IssueRepro\FrameworkRegistry\RegistryEditor\Program.cs:line 21
When I look at output of the Console project, I don't see the Microsoft.Win32.Registry.dll in the output.
Using ILSpy and loading my .exe - it seems it would try to resolve the .dll from my dotnet core installation, which wouldn't work since it's a .NET Framework app.
To Reproduce
I've created a repo that reproduces for me on my Windows 2010 machine. You can find it here: https://github.com/TylerNielsen/Microsoft.Win32.Registry-IssueRepro
Clone the repo, then open and build the RegistryEditor project.
Using Powershell or your favorite editor - call the tool with three required arguments [remoteMachineName] [Environment variable name to set] [Value to set on the environment variable] **
** Note, this actually requires a remote machine you can reference by IP address. For some reason using 127.0.0.1 doesn't work for me, but I'm unsure why. The use case for this utility is for accessing remote machine environment variables.
Other Notes
When I create a .NET Framework Class Library to use for unit tests and reference the same .NET Standard Library - the Microsoft.Win32.Registry package is included and the utility runs just fine.
In your repo, if you look into both csproj files you'll see they are quite different. The NetStandardRegistryLib.csproj is the new format, the RegistryEditor.csproj is the old one.
Your problem is that old style projects do not resolve dependencies transitively. RegistryEditor will not copy dependencies of its own dependency NetStandardRegistryLib.
There are at least two ways to solve your problem:
Just add Microsoft.Win32.Registry Nuget package to RegistryEditor project explicitly. That'll make the Microsoft.Win32.Registry.dll to appear in the RegistryEditor build folder.
Convert the RegistryEditor.csproj to new format. It's not limited to netstandard builds, you can use it for builds targeting .Net Framework versions as well. And it does resolve dependencies transitively!
Here's a long guide for how to do the conversion in general https://natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/
Since your project is quite simple, I've converted it for you. Just replace the content of RegistryEditor.csproj with the code below. It's still targeting net472.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<AssemblyName>RegistryEditor</AssemblyName>
<RootNamespace>RegistryEditor</RootNamespace>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\NetStandardRegistryLib\NetStandardRegistryLib.csproj" />
</ItemGroup>
</Project>
Note that several properties that used to be in AssemblyInfo.cs file are provided by csproj file properties now, so you need to remove them from AssemblyInfo.cs to fix compilation errors:
[assembly: AssemblyTitle("RegistryEditor")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("RegistryEditor")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
After updating an assembly, my xUnit tests fail to run.
My project was using System.Web.Http version 5.2.3. I replaced this using Nuget with a fork of System.Web.Http version 5.2.4. Inspecting the reference shows the correct path to the new DLL.
When I run xUnit, it discovers the tests, but gives me the following warning:
[11/04/2018 10:43:30 AM Warning] [xUnit.net 00:00:00.9421698] Skipping: API.IntegrationTests (could not find dependent assembly 'System.Web.Http, Version=5.2.4')
It then skips all tests.
I'm at a loss. Any help is very appreciated.
I'm using Visual Studio 2013 Premium and trying to "Add Fakes Assembly" to a test project. The initial build gives me this error:
error : Could not resolve assembly 'System.Runtime.Serialization,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e,
Retargetable=Yes'. Are you missing an assembly reference?
The test project and the project it's targeting are both using .net 4.0. My target project does indeed use System.Runtime.Serialization, but the 4.0 version (naturally).
Why am I getting this error and how can I resolve this issue?
This is one of those slightly odd semi-ephemeral quasi-bugs that pop up from time to time. I encountered it this week through FxCop and was unable to find any resolution to it (although I didn't install Silverlight as I couldn't risk bringing down our build server).
People say that it might be to do with binding redirection for Silverlight, others have said it has something to do with portable class libraries.
Your mileage may vary; but there other people with the same problem and it seems there is no definitive cause or solution at the moment.
FxCop analysis not finding indirectly-referenced assemblies - GAC issue?
FxCop indirect reference to System.Core version 2.0.5.0
https://github.com/AutoMapper/AutoMapper/issues/383
I added an existing project to my solution. When I run all unit tests with MSTest runner, I get the following error on a couple of tests:
Message: Test method soandso threw exception:
System.IO.FileLoadException: Could not load file or assembly 'log4net, Version 1.2.12.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a' or one of it's dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT:0x80131040)
I know others have had the same problem and there is other questions and answers about this topic. But I tried many things, but nothing helped.
The version of log4net we use is 1.2.13.0.
I checked with FUSLOGVW.exe for binding errors. The log4net shows up with the added assembly and some Unknown assembly.
The reference of log4net in the assembly shows version 1.2.13.0 which was added with NuGet. So it is probably a dependent assembly that is causing all this trouble.
I tried changing log4net back to version 1.2.12.0, but I still get the same error message.
When I run all the tests with MSTest testrunner, these errors show up. When I only run the failed tests, they pass. When I run them individually, they also pass.
I tried binding redirection, but I did it for the assembly that is tested not the testing assembly. I did not know how to do that for a test assembly - there is no config.
When I run the tests with Resharper test runner they also pass (but other tests fail). The TFS Build server runs the MSTest-runner, therefore I need to get it working with MSTest.
Does anyone know how I can get this resolved?
The culprit was found. Like I was suspecting, a dependent assembly was referencing log4net 1.2.12.0. The tool used to find out was dotPeek. Luckily we do have the source code for the dependent assembly and we can change it to reference the latest log4net. This solves this issue.
So if anyone has a similar problem, use dotPeek or a similar tool to go through the dependent assemblies to find out what versions of assemblies it is referencing.