Context
I am an application with C# and C++/CLI dlls. The C++/CLI dlls reference pure C++ .dlls, e.g. the boost libraries.
Tests are compiled into Tests.dll, which is placed with all the other binaries in $(SolutionDir)\bin\Debug.
Problem
Trying to run the xunit tests using Visual Studio 2012 fails, with the following error:
xUnit.net: Exception discovering tests from C:\Dev\xu-tests\bin\Debug\Tests.dll:
> System.IO.FileNotFoundException: Could not load file or assembly 'ManagedCpp.DLL'
> or one of its dependencies. The specified module could not be found.
> File name: 'ManagedCpp.DLL'
I can reproduce the problem in two ways outside of visual studio:
When trying to run the console runner from outside this directory
..(longpath)..\xunit.console.clr4.exe Debug\Tests.dll
When trying to run the GUI runner from its installed directory.
I can get it to work however when I use the console to get to the bin\Debug directory, then start the console or GUI runner from there.
This makes me believe that the problem is that VS2012 tries to run the unit tests not using the bin\Debug directory as working directory.
Question
How can I set the working directory in which xunit is run to $(OutDir) (or any specific directory)?
Related
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).
When trying to run nunit3-console.exe on my testing dll project on jenkins machine
I'm Getting Invalid : E:\Jenkins\workspace\XXX.Tests.dll
Has no TestFixtures
the dll was created by jenkins using msbuild.exe
on my dev machine machine it works perfectly using the build from Visual studio
Turns out that i had another testing project in the solution with an older version of nunit
and on jenkins it was building the solution and copying the binaries to the same folder
making the nunit.framework.xml to be overwritten
the solution was making sure that both project referenced the latest nunit version.
I'm having an issue on teamcity (9.1.7). I don't have visual studio installed on the build server. I have installed visual studio test agents and msbuild tools. Building one of the project fails with this error-
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(694, 9): error APPX1639: File 'Windows.props' not found. See http://go.microsoft.com/fwlink/?prd=12395&pver=1.0&plcid=0x409&ar=MSDN&sar=PlatformMultiTargeting&o1=Portable&o2=7.0 for more information
The link doesn't work. After looking up the error, it seems i need to install Windows Kits and I need to add this to my csproj file under the first property group -
<_WindowsKitBinPath>C:\Program Files (x86)\Windows Kits\8.1\bin\x86</_WindowsKitBinPath>
<_WindowsPhoneKitBinPath>C:\Program Files (x86)\Windows Phone Kits\8.1\bin</_WindowsPhoneKitBinPath>
<MakePriExeFullPath>$(_WindowsKitBinPath)\makepri.exe</MakePriExeFullPath>
<MakeAppxExeFullPath>$(_WindowsKitBinPath)\makeappx.exe</MakeAppxExeFullPath>
<SignAppxPackageExeFullPath>$(_WindowsKitBinPath)\signtool.exe</SignAppxPackageExeFullPath>
<MakePriExtensionPath>$(_WindowsPhoneKitBinPath)\x86\MrmEnvironmentExtDl.dll</MakePriExtensionPath>
<MakePriExtensionPath_x64>$(_WindowsPhoneKitBinPath)\x64\MrmEnvironmentExtDl.dll</MakePriExtensionPath_x64>
I really don't want to add this to my csproj file. I don't know why it is required/what impact it has. Can someone explain to me why this is needed? When i build my solution locally with visual studio, it works fine.
The groups of settings are basically bootstrapping parameters that are required by MSBuild in order to compile the project (A native windows phone app??). You've probably got the kit installed locally and something already integrated into Visual Studio, which is why it builds. Uninstall the Visual Studio add-in and it'll probably start failing.
You can setup your compile step to pass in these parameters without requiring them in the .csproj file if you don't want them there.
I normally abstract additional build parameters to a variable in TeamCity
Hope this helps
I have this simple test project in vs 2013 I reference the Microsoft.TeamFoundation.Client in my library so added a Microsoft.Teamfoundation.Client.12.0.0.0.Fakes in the test project, using right click add fakes assembly.
Locally everything works fine but when i run the project trough the build server using the default template I get Fakes: code : assembly XXX\Microsoft.TeamFoundation.Client.dll failed to load properly.
The non fake dll's are included in a solution folder.
Any other assembly added by fakes working perfectly fine but as soon as I fake the Microsoft.Teamfoundation. my build breaks.
Using VS2013 with TFS 2012 update 2.
I had the similar issue. The problem is because TFS and Visual Studio versions are not the same. I installed VS 2013 to the server where TFS Build Server installed.
Then renamed C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Fakes folder and copied
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Fakes folder into C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Fakes. This will solve your problem I guess.
On a Windows Server 2003 R2 with .NET 4 SDK but without Visual Studio 2010, I have tried building a Visual Studio 2010 solution with
msbuild MySolution.sln /p:RunCodeAnalysis=true
but that fails.
What is required to run code analysis on such an environment?
I get this error message:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(129,9): error MSB6003:
The specified task executable "FxCopCmd.exe" could not be run.
Could not load file or assembly
'Microsoft.VisualStudio.CodeAnalysis.Sdk, Version=10.0.0.0, Culture=neutral, PublicKeyToken= b03f5f7f11d50a3a'
or one of its dependencies.
The system cannot find the file specified.
I have installed FxCop from the SDK and without luck pointed the variable FxCopDir to the installed location of FxCopCmd.exe, and also setting this registry entry to that location:
HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\EDev#FxCopDir
I had the same problem on my MSBuild server and fixed it by:
Installing Windows SDK 7.1
Setting up the registry keys FxCopDir and StanDir in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\EDev (in Win32).
I then copied over from the dev PC, to the FxCop folder on the build server, the following:
The folder Rule Sets (default installation target is here: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\FxCop)
Microsoft.VisualStudio.CodeAnalysis.Sdk.dll
Microsoft.VisualStudio.CodeAnalysis.Phoenix.dll
phx.dll
Do a search for them on your dev PC with Visual Studio installed to locate them.
Then use the .NET 4.0 version of gacutil.exe to install Microsoft.VisualStudio.CodeAnalysis.Sdk.dll to the GAC.
You should then be able to run code analysis as part of an MSBuild build and have it work properly.
An alternative to FxCop would be to use the tool NDepend that lets write Code Rules over C# LINQ Queries (namely CQLinq). Disclaimer: I am one of the developers of the tool
More than 200 code rules are proposed by default. Customizing existing rules or creating your own rules is straightforward thanks to the well-known C# LINQ syntax.
Rules can be verified live in Visual Studio and at Build Process time, in a generated HTML+javascript report.
Another option might be calling FxCop executable as a build task (from msbuildtasks), saving the result as an XML file that can be parsed within most of the CI tools (like Hudson and CC.NET)