I got a problem using MSTest on x64: The test project depends on a couple of C++/CLI assemblies, and fails to load for some reason. In Visual Studio, I get (stripped down):
Error loading D:\xxx\Xxx.Test.dll: Unable to load the test container 'D:\xxx\Xxx.Test.dll' or one of its dependencies. Error details: System.BadImageFormatException: Could not load file or assembly 'Common.Geometry.Native, Version=1.1.4574.22395, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Running MSTest manually in a command prompt, I get:
Unable to load the test container 'D:\xxx\Xxx.Test.dll' or one of its dependencies. Error details: System.IO.FileNotFoundException: Could not load file or assembly 'Common.Geometry.Native, Version=1.1.4574.22395, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Details worth mentioning:
The test project itself is compiled using 'Any Cpu'.
I use a x64 specific testrunconfig
Dependency walker shows no missing native dependencies in the C++/CLI assembly (Common.Geometry.Native)
Even more interesting, there is another test project in the same solution using the same C++/CLI assembly (Common.Geometry.Native), and it runs without any problems.
I have also verified that there are no 32bit assemblies/dlls interfering.
Any suggestions is welcome !
I'd initially thought that microsoft didn't add a 64-bit capable test runner for MSTest until 2012... As it turns out, VS2010 is capable of this.
What I'd check then is if your native dll has any other native dependencies.
MSTest has a "mis-feature" where, before running your tests, it creates a temp directory, usually something like PC-NAME WORKSPACE_NAME 1782368124\Out, and it copies your code into that directory. For .NET assemblies, it can figure out the dependencies and is able to copy them, but for native code it does not appear to do this.
I've solved this in the past by adding the directory containing any other native dependencies to the PATH environment variable for my user account (remember if you do this to restart visual studio as it won't notice)
Related
I have a library used in various project and made with .net core 2.0; the library is called 'Coconut'; the test is done on Windows.
When I try to build a simple test project to test some functionalities, the test code will not run.
The test is very simple:
but when I run it:
And the output is:
An unhandled exception of type 'System.IO.FileNotFoundException' occurred in Unknown Module.
Could not load file or assembly 'Coconut, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
and the console shows the same problem:
What I don't understand is that the DLL that is not found is built in the same solution and everything was built through Visual Studio's tooling.
We can clearly see the dll in the same folder.
Edit:
When checking with procmon, there is not a single operation trying to load 'coconut.dll'; that string is completely absent from the log.
I'm creating a basic MSI installshield 2014 project. I've added a custom action which calls a public method present in a managed .Net assembly (MyCSharpAssembly.dll). Now my managed dll in turn calls a method present in an unamanged/native assembly (MyUnamanagedCPlusPlusAssembly.dll) written in C++. I used DllImport methodology to load the native assembly at run time.
I added the native dlls into support files ( [SUPPORTDIR]) based on the accepted answer of this thread. I also see those native assemblies getting copied in the temporary working directory of installshield when I run the MSI output. Still, it doesn't work? When installer runs I simply get following error in the logs-
Failed to load assembly. Dll not found.
This essentially means CLR/.net run-time is unable to see the native assembly dlls at run time. Does anyone have any idea on to specifically load native dll dependencies during installation process?
I have a web performance test, which uses web test plugin. Based on this web performance test, I created a load test. When I run the load test from the Visual Studio 2013, the load test runs correctly on all my remote agents. However when I run the same test by using MSTest command line, I get an error indicating that the PlugIn (C#) was not loaded. My question is whether it is possible to execute a load test (with plugin) by using the command line MSTest? If yes, then what I need to do to get rid of the error?
Please note that I have already referenced the plugin in my visual studio projects (both web performance project and load test projects)
Thx
Here is the error that I get:
Run has the following issue(s):
Could not run load test 'ABC' on agent 'XYZ': Could not load
file or assembly 'PlugIn, Version=1.0.0.0, Culture=neutral,PublicKeyToken=null
' or one of its dependencies. The system cannot find the file specified.
Could not load file or assembly 'PlugIn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
The system cannot find the file specified.
When Visual Studio runs a test from within a solution it understands deployment items, such as DLLs for plugins and it deploys them automatically. By contrast mstest.exe does not do any automatic deployment. Hence you need to deploy the files yourself. That is commonly done via the "deployment" sections of a .testrunconfig or a .testsettings file.
Having specified the DLLs to be deployed in one of these two file types, add the corresponding /testsettings:{file name} or /runconfig:{file name} options into the call of mstest.exe.
See, for example, section 3 of this Microsoft blog.
I have a C# 4.0 application that is referencing a type library from a C++ application. This is used for some secure COM interop, a question I originally had asked here.
On my development machine this second application is installed so I can compile without any issues. If I attempt to compile on our automated build server, or any machine with Visual Studio installed but without this second program, I receive the following errors and compilation fails:
Text for google:
The type or namespace name could not be found (are you missing a using directive or an assembly reference?)
Cannot get the file path for type library "guid...." version 1.0. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
The referenced component 'SecurityAgentLib' could not be found
Picture for readability:
I'm not sure how to get around this other than by installing the application that registers the actual dll that implements these types, but I don't want to do that on our build server. The code that uses these types are wrapped in a class that is never instantiated unless prerequisite checks are run to verify the app is actually installed, so there is no chance of a runtime error. In fact I can run my app just fine on a machine without the second app installed - I just can't compile it there.
In visual studio the reference points to the .tlb file which is included in the solution directory, so the tlb file itself is present.
I can't imagine it should work this way, and I've searched around, but I'm apparently not searching for the right terms.
EDIT:
Running tlbimp.exe generates a dll but the type library should be sufficient for compilation, I thought at least. There is also an issue of broken references. I was reading this article Troubleshooting Broken References and it says that if the reference was to a COM component that is not installed than installing the component corrects the error, which is true.
Installing it on the build server really isn't an option. Opening visual studio and re-adding a reference if the path was broken doesn't work either.
I was able to use tlbimp to create a dll and used visual studio add a reference to that dll. That let me compile, but how would this work in an unattended build server?
EDIT
Okay I came up with two solutions that worked given my requirement of this all being unattended
Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.
In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.
I also removed the tlb and added the dll in visual studio and did a diff on the .csproj file. I don't see any downside to just having a reference to the dll instead of the tlb but if needed the build server could make modifications directly to this file to remove the tlb section and add a reference to the dll following a build of the second product.
Here are a couple options that each worked.
Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.
In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.
I also removed the tlb and added the dll and did a diff on the .csproj file. I don't see any downside to just having a reference to the dll instead of the tlb but the build server could make modifications directly to this file to remove the tlb
I have a solution containing my main project and a test project using NUnit. Everything compiles but when I run NUnit I get the exception below after the tests load, and the tests fail. I've added the main project as a reference, and I have $(ProjectDir)bin/Debug/$(TargetName)$(TargetExt) in the arguments for NUnit in the external tools setup, with a blank initial directory.
MyMainProjectTests.Database.TestAddDelete:
System.BadImageFormatException : Could not load file or assembly 'MyMainProject,
Version=1.1.1.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. An attempt was made to load a program with an incorrect format.
TearDown : System.Reflection.TargetInvocationException : Exception has been
thrown by the target of an invocation.
----> System.BadImageFormatException : Could not load file or assembly
'ChickenPing, Version=1.1.1.0, Culture=neutral, PublicKeyToken=null' or one
of its dependencies. An attempt was made to load a program with an incorrect
format.
After scouring for hours the only thing I've found is a bug in VS2005 which mentions the /bin and /obj directories, but the answer provided didn't help.
Any solutions?
Instead of setting up NUnit as an External Tool, I set the unit test project as the StartUp project. In the project's Properties screen, set the Start Action to "Start external program" and point it to nunit.exe. In the Start Options section, I specify the test assembly (no path necessary) in the "Command line arguments" box. At this point, simply press F5 to start up NUnit.
Use the nunit-x86.exe instead of nunit.exe as your runner.
A better longer term solution may be to buy ReSharper that includes a much nicer test runner for NUnit that fully integrates into Visual Studio. It auto detects your .NET project type (x68 or x64). ReShaper comes with tons of other features of which unit testing is just one. Their test runner also integrates with their DotCover code coverage analyser.
You may find that you'll need a later version of Visual Studio to use ReSharper. The latest version works with Visual Studio 2013 Community Edition that you can get for free though I understand you may have issues upgrading some project features from such a rather old VS2005 project.
I don't have any affiliation with ReSharper.
Are you running on x64? You will get that error if loading a x64 bit from x86 and vise versa. Also, the path you are trying to create should be the $(TargetPath) macro.
Just set "Platform target" of Tests project to "x86".
Is your main project a .exe or a .dll? Older versions of .NET couldn't reference an .exe, so that might be the problem.
In either case, I'd expect problems if the main assembly didn't end up somewhere accessible by your test assembly (for example, in the same directory). You could check that, and if not make it so, perhaps by having Visual Studio copy the referenced (main) assembly to the local directory.
The "An attempt was made to load a program with an incorrect format." makes me wonder if the "missing assembly" theory is right, but without more info, it's the best guess I can think of.
Go the the NUnit install (example: C:\Program Files (x86)\NUnit 2.6.3\bin) location and open nunit-86.exe.