Xunit not working using Visual Studio Team Services Build VNext - asp.net-core

After following several blogs detailing how to get xUnit working with Team Services Build vNext:
http://tech.trailmax.info/2014/01/run-xunit-in-hosted-team-foundation-service/
Running unit tests in TFS/VSO Build vNext using xUnit adapter
http://www.donovanbrown.com/post/2015/06/15/how-to-run-xunit-test-with-vnext-build
None of which worked for me. From examining the build logs I get the following warnings for each of my test assemblies.
--------------------
Warning: [xUnit.net 00:00:00.1644156] Exception discovering tests from CHO.SAM.Business.Test: System.BadImageFormatException:
Could not load file or assembly 'c:\_Work\473cef3c\CHO\CHO.ALL\Tests\CHO.SAM.Business.Test\CHO.SAM.Business.Test\bin\Debug\xunit.execution.desktop.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
--------------------
Has anyone seen this before? and if so did you figure out a solution?
My thoughts are; my test projects are compiled using .NET Framework 4.6, I was wondering if this could be causing the problem? If so I would have to move over to nUnit or something as I don't feel it's right to change the compilation just to use a single test framework.

Add "/Framework:Framework45" to "Advanced/Other console options" (to run under .NET 4.5)
or
Add "/Framework:Framework40" to "Advanced/Other console options" (to run under .NET 4.0)
or
Change "Advanced/VSTest version" to "Visual Studio 2013" (to run under .NET 3.5)

This error is normally caused by a x64 compiled assembly running on x86 test runner or vice versa. Check the solution build configuration that is being run.

I had this same issue. Adding a UI test did not fix it for me. I found two alternatives that work:
use .net 4.5
OR
Set the advanced options of the VSTest task to use 2013 instead of 2015.
Hopefully this will be fixed soon.

In the end, I added a Visual Studio Coded UI test project and removed all it's contents (a class), it's empty!
I'm assuming it's added a reference or something that the build server felt it needed.
I am now getting my unit tests discovered, running and with code coverage.
Wierd!
It works, but I don't know why...

I ran into this issue when using a .Net Core class library to run my xUnit tests against a .Net Core Web Project (.Net Framework). What solved the issue for me was to change the default processor for running test to X64 in VS2015 via:
Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
This solution was posted by #RehanSaeed here https://github.com/dotnet/cli/issues/3103

Related

Is it possible to build a project with a com reference with the dotnet CLI? [duplicate]

I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?
https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.
Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao
I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.
I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE
I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)

How to successfully run/debug NUnit + SpecFlow tests using Visual Studio Mac

I have a cross platform automation solution based on SpecFlow and NUnit 3.
This solution succeeds to run Web (Selenium) and Android (Xamarin.UITest) automated tests on Windows, unfortunately, it does not works on OS X in Visual Studio Mac.
When I use the command line NUnit console runner OR Rider (JetBrains IDE), tests seems to be working, but when I use VS Mac, it does not.
All my issues seems to be related to VS Mac, the first I had was because assemblies dynamically loaded by SpecFlow were not found.
Someone gave me a workaround on GitHub (TestRunnerSupportAssembly key to add in .csproj so that test runner can find assemblies).
And now that the assemblies are loaded, it is the App.config file which seems to be loaded but whose keys do not appear in AppSettings object.
Here is a part of the log I get from the IDE during test run :
Mono: Config attempting to parse: '/Users/.../Automation/AutomationMobile/bin/Debug/AutomationMobile.dll.config'.
I really think the issue is because of the test runner used by VS Mac, but I can't find how to configure it appropriately.
PS : I cannot migrate to .NET core, because few assemblies does not support it (Xamarin.UITest for instance).

Where is FrameworkUap10 used in VSTest.Console.exe for Win Universal Apps Unit testing

I've been tasked with adding Unit Testing to our WinUA. The developer said he added a new unit test for UWP project to his solution and I'm to add calling this at build time. He wasn't sure how to do it and pointed me to this article: Set up automated builds for your UWP app
I've added a "Visual Studio Test" step and set the following:
Test Assembly = **\*.UnitTests.build.appxrecipe
Other console options = /framework:FrameworkUap10
Running it throws the following error:
[error]Error: Invalid .Net Framework version:FrameworkUap10. Supported .Net Framework versions are Framework35, Framework40 and Framework45.
If I remove the invalid framework, no error is thrown but also no tests are run.
I cannot find any information on the /framework:FrameworkUap10 option. Searched MS, here and web and all that comes up is its use in this article... nothing about installing it on the build machine.
How does one install FrameworkUap10?
I was able to get this to work using the following using the following msbuild args for the msbuild step:
/p:AppxBundlePlatforms="$(BuildPlatform)"
/p:AppxPackageDir="$(Build.BinariesDirectory)\AutoBuildPackages\"
/p:AppxBundle=Always
/p:UapAppxPackageBuildMode=StoreUpload

TFS2010 build with unit test

I am trying to convert a build system setup with TeamCity and Nant scripts to use TFS2010 (We bought the license and might just as well make use of it) After some work I get the web project to build and deploy to the web-server. We have a domain, API, test and web project in our solution.
How do I configure TFS to run the unit tests that we have written so far? I did configure the build to look for ***.UnitTest.dll in(VS2010) Edit build definition>Process>Automated Tests
Now the build fails with a message that says:"Could not load file or assembly 'nunit.framework, Version=2.5.3.9345" Am I correct when I say that TFS is trying to run NUnit on the build server? I did install NUnit-2.5.3.9345 on that TFS2010 build server and still nothing?
Thank you
Jack
The build facility in TFS uses MSTest as test runner, with which it's tightly integrated.
If you want to run your unit tests with NUnit as part of your build, take a look at the NUnit for Team Build project on CodePlex.
The project started out for TFS 2008, however support for TFS 2010 has been added in version 2.0. Note that this feature is still in early stages of development, so your mileage may vary.
I'm late to the game, because I've had to deal with this issue recently. I found this article helpful for me in this. It didn't work right off the bat, but I found if I added it into my buildscript via the controls in a similar manner/pattern, it would work.
My only problem now has been getting it to actually error (right now it warns) even when flagging them to cause the build to error
Link: http://blog.gfader.com/2011/06/running-nunit-tests-in-tfs-2010.html

teamcity NUnitLauncher .net 4

Using TeamCity 6.5.1
NUnit version 2.5.10
Win2008 x64
Project is using .NET 4.0
Trying to execute the built-in TeamCity NUnit test runner, I receive the following error:
NUnit error running tests in 'E:\TeamCity\LocalBuildAgent\BuildAgent\work\698a8f459eac8cd9\MyProject\bin\Release\MyProject.Tests.dll' assebmly
System.BadImageFormatException: Could not load file or assembly 'E:\TeamCity\LocalBuildAgent\BuildAgent\work\698a8f459eac8cd9\MyProject\MyProject.Tests\bin\Release\MyProject.Tests.dll' or one of its dependencies. This
assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
My stack is pretty much identical to yours...so, I am going to take a shot in the dark here.
If you go into the Build Step you designated in Team City for running NUnit and find the .NET Runtime section and make sure Platform is set to "auto(MSIL)" and most importantly check to make sure version is set to v4.0.
I have seen your exact error when attempting to run unit tests for a 4.0 project against the 2.0 framework setting.
If it isn't that, I would suggest checking directory permissions and that the System or Network Service accounts which I think team city runs on (unless specified otherwise) can access the directory that your tests.dll resides in.