This is an F# test project which I'm trying to 'share' between VS2013 and VS2012. I'm not referencing Lazy anything in my code, so I'm not sure what's up.
I believe it's to do with having the latest version of xunit (2.0) referenced.
The type 'Lazy`2' is required here and is unavailable. You must add a reference
to assembly 'System.ComponentModel.Composition, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'. FSC 1 1 MyProj
also
A reference to the type 'System.Exception' in assembly 'System.Runtime' was found,
but the type could not be found in that assembly
C:\MyProj\startup 1 1 MyProj
Never found a solution, I just abandoned VS2012 and recreated the project in VS2013 only.
Note that the project was x64, which may not have helped.
Related
On a project I am working on, I am maintaining some Feature Tests written in SpecFlow. Our team started using Visual Studio 2017 about a year ago, and we finally got around to doing some upkeep on our tests!
Our tests for the project I'm working on were originally written in SpecFlow 2.3.2, and were last updated in Visual Studio 2015.
The SpecFlowSingleFileGenerator is known to not work on VS 2017, so I spent the better part of yesterday changing our suite to use the MSBuildSingleFileGenerator instead as detailed in this article in SpecFlow's official documentation
Problem:
Locally, I can build my solution, including the Feature Test project just fine.
However, I keep getting the following error when I try to build the project on our build server:
[exec] C:\CheckoutDirectory\My Awesome Project\packages\SpecFlow.Tools.MsBuild.Generation.2.3.2\build\SpecFlow.Tools.MsBuild.Generation.targets(45,5):
error MSB4036: The "GenerateAll" task was not found.
Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin" directory. [C:\CheckoutDirectory\My Awesome Project\AwesomeProject.FeatureTest\AwesomeProject.FeatureTest.csproj]
I should point out that our team has no experience with writing MS Build tasks, as hitherto we haven't needed to; we use NAnt build scripts on TeamCity to manage our build work. It's clear that error message would be helpful...if we knew literally anything about it.
Now, normally the correct answer would be: Google it. I did that, and this specific error has no pertinent results.
Additionally, this is blocking my team, since we need our build to work. I don't have the time to do the research and education necessary to properly understand how MS Build technology works. That wil have to come later.
Question:
Bearing in mind that SpecFlow has broken our process, and our team's lack of knowledge about the MS Build system: I need to know how to get around the "GenerateAll" task was not found error. What do I do to get around it?
Secondary Question:
I'm also open to lateral thinking. Is there some way to hack either VS 2017 or SpecFlow to make the SpecFlowSingleFileGenerator "compatible" with each other? The objective here is NOT to avoid making changes, but to control the changes. I need a path towards transitioning from the old file generator to the MS build generation system.
Additional Information:
So, I did some digging, and I found a place where "GenerateAll" is being called in the SpecFlow.Tools.MsBuild.Generation.targets file:
<Target Name="UpdateFeatureFilesInProject"
DependsOnTargets="BeforeUpdateFeatureFilesInProject"
Inputs="#(SpecFlowFeatureFiles)" Outputs="#(SpecFlowFeatureFiles->'%(RelativeDir)\%(Filename).feature.cs')">
<GenerateAll
ShowTrace="$(ShowTrace)"
BuildServerMode="$(BuildServerMode)"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
ProjectPath="$(MSBuildProjectFullPath)"
ForceGeneration="$(ForceGeneration)"
VerboseOutput="$(VerboseOutput)"
DebugTask="$(SpecFlow_DebugMSBuildTask)"
>
<Output TaskParameter="GeneratedFiles" ItemName="SpecFlowGeneratedFiles" />
</GenerateAll>
</Target>
Because I've confirmed that this is being copied out to the build server, the situation is yet more mysterious. It appears that the NuGet package is being pulled down faithfully. Therefore, I can't figure out why my local copy is behaving differently than the copy on the build server.
I am not sure where you found this statement:
The SpecFlowSingleFileGenerator is known to not work on VS 2017
The SpecFlowSingleFileGenerator is working in VS2015, VS2017 and VS2019. We see it as a legacy feature, but it's still there. Since some weeks it is disabled by default, but you can enable it in the options.
It works for SpecFlow >= 2.3.2 and 2.4. For SpecFlow 3 you have to use the MSBuild integration. There are some problems with older versions of SpecFlow, but with them it can also work. It depends on your setup.
About your MSBuild error:
The MSBuild Task for SpecFlow < 3.0 is in the specflow.exe. Is it on your build server?
It is part of the SpecFlow NuGet packages. Normally you get this kind of error if MSBuild can't find the assembly where the task is.
For "debugging" problems with MSBuild, I can highly recommend to use the MSBuild Structured Log Viewer (http://msbuildlog.com/). With it, it makes it easy so see what is happening in your build.
We have an example for MSBuild Code- Behind- Generation with SpecFlow 2.3.2 here: https://github.com/techtalk/SpecFlow-Examples/tree/master/MSBuild/OldCSProj_SpecFlow232
You could compare your project with this example.
Full disclosure: I am one of the maintainers of SpecFlow.
I am using VS 2017. I have this line in my packages.config file.
<package id="System.IdentityModel.Tokens.Jwt" version="4.0.4.403061554" targetFramework="net461" />
I got this error my trying to start my .net application.
System.TypeLoadException: Could not load type 'System.IdentityModel.Tokens.NamedKeySecurityKeyIdentifierClause' from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Because System.IdentityModel.Tokens.NamedKeySecurityKeyIdentifierClause really does not exist in version 5.2.1.0. But it seem NuGet simply ignores the version specification, and always loads the latest version.
I have tried to clean NuGet caches, clean and rebuild entire solution, and restart computer...
Is there anything else I can do?
Update
One strange thing I observed in VS 2017. Notice the differences of the icons for System.Data and System.IdentityModel.Tokens.Jwt. When I try to check the properties of the latter, VS says the package is not installed, which it clearly did. The build went successful, but the application just wont load the right version.
There are a couple of steps you can perform to check that the right version is loaded:
Rebuild your solution to make sure all NuGet packages are restored and that the started application is up to date (You already did that).
Check the tag HintPath for the reference in the project file that references the package. Just open the file in a text editor and look for an XML tag starting with <Reference Include="System.IdentityModel.Tokens.Jwt. Make sure that no version-specific reference is set or that the version matches the version in the packages.config file.
Check in the properties of the according reference in Visual Studio that it is resolved correctly. That means, there must be no yellow exclamation-mark icon on the reference in the solution explorer and in the properties of the reference, the Path entry must point to the installed package. Hence, the path should point to the packages directory inside your solution directory and therein into a directory System.IdentityModel.Tokens.Jwt.4.0.4.403061554.
In most cases (from my experience), there is some mismatch between the reference in the packages.config file and in the project file. If that does not help, make sure that no other module is loaded by your application that has a reference to System.IdentityModel.Tokens.Jwt in version 5.2.1.0.
So far, it is still unclear why VS cannot handle the changes of the NuGet packages, and why it thinks my project is using both .Net Framework and .Net Standard at the same time. I bet it is a but in VS, and hope MS can fix it soon.
Before that, installing Rider and use it to fix the packages, then went back to VS, and everything went back to normal.
Environment:
.Net Core 2.0
visual Studio Professional 2017
NUnit3
OpenCover (For code coverage)
ReportGenerator(For code coverage report)
Hi Nunit Team,
I am pretty familiar with MS Test framework and have worked on that extensively but was testing how suitable NUnit framework would be and so wanted to do a small POC around that. I created a small classlibrary and a unit test project. Below are the NuGet package been installed:
NUnit 3.7.1
But when I try to run the test cases from console runner like below I get exception saying System.Runtime, Version=4.2.0.0 assembly not found.
C:\Users\UN\.nuget\packages\nunit.consolerunner\3.8.0\tools>nunit3-console.exe D:\Code_Trials\BoMLibrary\BomTest\bin\Debug\netcoreapp2.0\BomTest.dll
Exception detail:
Errors, Failures and Warnings
Invalid : D:\Code_Trials\BoMLibrary\BomTest\bin\Debug\netcoreapp2.0\BomTest.dll
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
----> Could not load file or assembly 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Run Settings
DisposeRunners: True
WorkDirectory: C:\Users\Smukherjee.nuget\packages\nunit.consolerunner\3.8.0\tools
ImageRuntimeVersion: 4.0.30319
ImageTargetFrameworkName: .NETCoreApp,Version=v2.0
ImageRequiresX86: False
ImageRequiresDefaultAppDomainAssemblyResolver: False
NumberOfTestWorkers: 4
Am really not sure why so? No matter what I try not able to pass through this error. Moreover, when I try to install the assembly from Nuget I don't even find a assembly with version 4.2.0.0.
Tried installing the version 4.3.0.0 of System.Runtime but no luck. Can you please help on this.
Strange thing, I have got a sample unit test project (as part of opencover nuget install) which targets .Net Framework 4.5 and have NUnit2.6.7 package installed and when I try to run that using NUnit3 console it works like charm.
Even, installing NUnit3 latest stable version 3.10.1.0 doesn't help either. Also, it's surely not an Opencover issue since opencover console just passes the test run request to NUnit console. So the issue has to be around NUnit.
Let me know if you need more information around this.
Found the answer to this here https://github.com/nunit/nunit/issues/2763
NUnit Console doesn't run .NET Core tests - you need to use dotnet test instead. Take a look at this page:
https://github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard
I am developing an app for Windows Phone, and also have a Test project for creating and running tests. This was working fine, but suddenly I am getting an error that the reference System.Runtime.Serialization cannot be found.
Specifically the error is:
System.IO.FileNotFoundException: Could not load file or assembly
'System.Runtime.Serialization, Version=2.0.5.0, Culture=neutral,
PublicKeyToken=7cec85d7bea7798e' or one of its dependencies.
First of all, shouldn't it be 4.0 not 2.0.5?
I attempted to add a reference to the 4.0 version of System.Runtime.Serialization, but now the error is this:
System.IO.FileLoadException: Could not load file or assembly
'System.Runtime.Serialization, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference.
I looked all over the projects to find where this reference (2.0.5) is defined so I can update it (not sure how it ever got changed) but have had no luck.
I am using JSON.NET if that matters (5.0.6)
If it is supposed to be 2.0.5 is there any way the project could have been accidentally or automatically changed to be 4.0?
this was working before, so SOMETHING changed, and it certainly wasn't deliberately done by me...
EDIT
After looking at the error above, I took another look at my code, and it appears the culprit is this attribute I put on one of my properties:
[JsonProperty(PropertyName="NameType")]
because the property name differs from the name in the JSON. It runs perfectly, but fails during tests. If I comment it out, the test passes (but the application fails to get this property).
EDIT2:
So it appears to me the problem is that Windows Phone has a Windows Phone JSON.NET version, while the test project loads the standard .net40, but the windows phone assembly being tested wants the phone version so it's getting all mucked up...
or something. I feel like I just screwed up the references somehow, but I cannot figure out what.
I tried setting "Copy Local" to true/false, and adding the JSON.NET reference for windows phone to the test project, but then it tells me it's the wrong version...
How do I tell the test project (which is not a windows phone project) to use the windows phone assemblies for test? Do I have to make a new test project that is a windows phone type or something?
Everything was working perfectly until I added an attribute that uses the System.Runtime.Serialization library...
It turned out being a problem with my code, which is weird because obviously that's not the error message I got...
anyway, the problem appears to be that the JSON property was "NameType" and I was using "Type" with a JsonProperty(Name="NameType") and I guess the compiler didn't like that.
Changing the property name to match appears to have fixed the issue.
many thanks to all for your input!
I converted a solution from VS2008 to VS2010 SP1, and changed the unit test project to target the 3.5 framework. Other than having to fix a few references in the unit test project, everything worked ok and the solution built successfully. Most of the tests run successfully, but there were a handful that failed. The ones that failed are using a private accessor. Personally, I'd rather just remove these tests since I don't think they're necessary, but as long as it reveals a potential bug in SP1, I thought I'd see if anyone could figure out a work-around.
The error message that I receive when running the tests is "This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."
As best as I can tell, it appears that the private accessor assembly is being built by the 4.0 runtime (most likely via Microsoft.VisualStudio.QualityTools.UnitTestFramework), but since the 3.5 runtime is loaded by MSTest, the resulting error occurs.
I tried changing the reference for Microsoft.VisualStudio.QualityTools.UnitTestFramework to specifically use version 9.0 (currently it is 10.1). This results in a compile time error which says that the private accessor assembly uses version 10.0 of Microsoft.VisualStudio.QualityTools.UnitTestFramework, which is higher than version 9.0.
I've deleted the generated private accessor assembly and recreated it as well, and still have the same issue. It would seem that something is out of sync with VS2010 SP1 when the 3.5 framework is targeted in a unit test project.
Here is the code for one of the unit tests (again, not a very valuable test, but that's not the point of the post...):
[TestMethod()]
public void GetNullableCharValue_DBNull_ReturnsNull_Test()
{
object value = DBNull.Value;
Nullable<char> expected = null;
Nullable<char> actual;
actual = RepositoryBase_Accessor.GetNullableCharValue(value);
Assert.AreEqual(expected, actual);
}
I ran into this problem as well. Visual Studio 2010 SP1 adds support for unit test projects based on .NET v3.5; previously unit tests were forced to use .NET4.
There is a Microsoft Connect bug on the subject but it was just filed the day I'm writing this answer so there is no meaningful response from Microsoft yet.
The workaround I chose was to manually generate the private accessor assembly using Visual Studio 2008 toolchain and add a manual reference to it from the unit test project.
The steps are:
1) Remove the autogenerated accessor from the unit test .csproj file:
<ItemGroup>
<Shadow Include="Test References\Assembly.accessor" />
</ItemGroup>
2) Create the v3.5 compatible accessor assembly using Publicize VS2008:
"%VS90COMNTOOLS%vsvars32.bat"
publicize Assembly.dll
3) Copy the assembly to the source tree folder, e.g. under a folder Accessors:
copy Assembly_Accessor.dll ProjectDir\Accessors\Assembly_Accessors.dll
4) Add the accessor assembly as a reference to the unit test project using the Visual Studio interface:
Project -> Add Reference.. -> Browse...
5) Build your solution with Ctrl+Shift+B and run your tests.
You can now either check in the generated assembly or create it automatically in a pre-build event.
This solution does not work when the asseblies are signed and versioned or when there is a accessor class.
http://connect.microsoft.com/VisualStudio/feedback/details/677203/even-after-installing-vs2010-sp1-unit-tests-targeting-3-5-framework-fail-if-they-are-using-private-accessor
Try following these steps: http://blogs.msdn.com/b/vstsqualitytools/archive/2010/12/19/how-to-re-target-unit-tests-to-net-framework-3-5-in-vs-2010-sp1.aspx