I have a Visual Studio solution where i use MSTest for my Unit-Testing, and would like to use the ReSharper Testrunner as i think the Visual Studio Test Explorer is really painful to work with. My whole solution is built for x64, because i have some dependent assemblies that are specifically compiled for x64 and not available for x86.
My unit-tests run fine in the VS Test Explorer, but they fail in the ReSharper Testrunner.
The following exception is being thrown, right before it hits the first line of the unit-test:
Unable to get type xxx.xxx.xxx. Error: System.BadImageFormatException: Die Datei oder Assembly "file:///D:\path\to\unit\test\project\bin\Debug\xxx.xxx.xxx.dll" oder eine Abhängigkeit davon wurde nicht gefunden. Es wurde versucht, eine Datei mit einem falschen Format zu laden.
Sorry for the exception being in german. It's just a 'typical' BadImageFormatException where xxx.xxx.xxx is the type of my unit-test project.
The Stacktrace indicates that the exception is being thrown from
Microsoft.VisualStudio.TestPlatform.MSTestFramework.TypeCache.LoadType(String typeName, String assemblyName)
I know that there are already many similar questions on stackoverflow, but i already tried every possible solution i found (without any effect), and therefore i assume my problem lies somewhere else.
What i tried and checked so far:
I double checked every project in my solutions to be compiled to x64 (even in release mode) -- everyhting seems fine
Default processor architecture for MSTest is explicitly set to x64 (Probably that's why it's working with the built-in Test Explorer)
Though it should be decided based on the platform of the project, i explicitly set the platform in ReSharper Testrunner to x64
I even modified the Unit Testing settings for ReSharper to force the execution of the unit-tests in a 64-bit process
Disabled Shadow-Copy of the assemblies in ReSharper settings (Just because i'm pretty frustrated right now, and switched to trial & error mode just before i started creating this question)
It's irritating that the tests run fine with Test Explorer, but not with ReSharper, though both have been set to x64. Am i missing a specific setting i need to modify? Or are they some known problems when using ReSharper in combination with MSTest? I might also consider using nUnit instead, but i'd need to modify all tests, so preferably i'd stay with MSTest.
Additionaly some information about versions and stuff (don't know if it might be helpful):
Visual Studio Premium 2013 v12.0.30110.00 Update 1
.NET Framework 4.5 on every project in the solution
ReSharper 8.2 C# Edition, Build 8.2.0.2160
After some additional research i found a similar post in the ReSharper Community, that indicates that ReSharper is configured to create and use a testsettings file in MetaData of the application per default, which is not configured to use the x64 architecture. I had to create a custom TestSettings file on my solution (which is placed under Solution Items), set it to force running in x64 and then edit the ReSharper setting to use this custom TestSettings file instead of the default one. I still do not know why ReSharper isn't using the default processor architecture specified for MSTest and also ignoring the settings i specified explicitly in the ReSharper settings.
But anyway it's working now.
Related
I am using VS 2015 and I created a new “Unit Test App (Windows Universal)”.
If the Default Processor Architecture is set to x64 (under “Test -> Test Settings -> Default Processor Architecture”), the build works fine and the test is also discovered successfully and displayed by the Test Explorer
However, if I change the Default Processor Architecture to x86, the build still succeeds, but VS does not discover any tests.
Thoughts?
P.S. I have looked at some of the similar problems that have been asked here. If you think this is a duplicate, please confirm with me before flagging the question. thanks.
For the larger audience: It seems like there was something that I was missing while installing Visual Studio that resulted in this issue. I reinstalled VS from scratch, and everything works as expected.
I just hit this too.
For me the root cause was that the Build target must match the Test Settings Default Processor Architecture.
New Projects (even Universal Windows projects) always default to Any CPU.
If you are running on x64 machine then your Test Settings Default Processor Architecture has to be x64 too.
In my opinion Universal Windows projects should never have an "Any CPU" config.
Universal always has to build native now so stop the "Any CPU" option and make the user pick the target!
I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.
According to Li Shao's (of Microsoft) 2009 blog entry:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.
This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?
HELP!
Have a look at Daffodil: http://daffodil.codeplex.com/
After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.
I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.
When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.
Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?
I have developed a Win32 Console app DLL and a small tester application for it. As far as I know neither uses MFC, .COM, .NET or dot-anything else. Development platform is VS2009 on WinXP/SP3
When I give the DLL and EXE to someone else, they are unusable. Attempting to use them generates errors similar to "Application cannot be used, the application configuration is wrong." and "cannot find xxx.dll" (not exact wording on these error messages).
I have learned from reading that there are dependencies that must ship with the EXE and DLL. These dependencvies seem to be specific to VS 2009 abd should include the MSVCRT09, etc.
When I followed MS's instruction to make a setup.exe/MSI installer for a Setup and Deployment Project (http://msdn.microsoft.com/en-us/library/ms235317%28v=VS.90%29.aspx) I add the dll to the project, move it to the "MyLibrary" folder and no dependencies are found or listed in the Solution Explorer. Yet, I know there are dependencies, DEPENDS.EXE says so.
Can anyone walk me through this or name a better site with instructions. Once again, MS's help isn't all that helpful.
thanks,
Wes
Visual Studio 2008 is version 9.0. A program built with Visual C++ 2008 normally does have dependencies on the C run time library MSVCRT09, as you discovered. If the C run time library is not installed on the destination PC (either already installed or as part of your setup project) then your application fails, as you discovered. It is no surprise that DEPENDS.EXE displays the dependency. The only question seems to be why Visual Studio 2008 doesn't display the dependency in its Solution Explorer window.
Before building your Visual Studio setup project (MSI and setup file), Visual Studio might not have had any reason yet to search for dependencies. But after the setup project is built, in my experience the Solution Explorer does show the dependencies it found, next to other dependencies that you set explicitly. If those don't show up after building, something is weird.
I'm trying to move my VS 2008 solution to VS 2010. Everything works perfectly (compile and link) if I keep the target framework at 4.0.
When I change the framework 2.0 and change the platform framework v100 (to get past compile errors) only to run into metadata linking errors, like this one:
error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0000f7). C:\Development\Main\Filemaster\SoxService\MSVCMRTD.lib(managdeh.obj)
I've read that I'm supposed to use ILDAsm but it doesn't like my obj file and since the link didn't complete I don't have an exe to load.
Can anyone please provide some advice on how to find the sorts of errors?
I hate nothing worse than fighting the tool!
I was able to get around this problem by going into the project XML file itself and changing the TargetFramework to be 4.0 After that everything compiled and linked fine.
Hans he is referring to C++ Native Multi-Targeting which can be found at this location Platform Framework can be changed under project Properties > General and is advised by the article - however this does not work due to apparent bugs in VC++
I'm attempting to find the minimum installation requirements for getting WP7 projects compiling on a Windows 2008 R2 build server. I'll be looking into automated testing using the emulator at a later point, but right now I'm stuck on the build side.
I realise this approach won't be supported and I'm willing to trash the VM at a later date if an update proves to be incompatible (assuming I get it to work at all)
I'm also aware of the workaround for installing the entire SDK on Windows 2008 R2, but I'm trying to avoid installation of Visual Studio (it's now become a curiosity more than anything else)
As it stands, I've installed the following from the SDK ISO:
WCU\Silverlight4\silverlight_sdk.msi
WCU\WindowsPhone\WindowsPhoneExtensions.msi
WCU\WindowsPhone\VS_SDEProLightup-enu.msi
At this point, it is able to locate all the required MSBuild target files and even compiles the project. The problem appears at the end of the process during the XapPackager target, when it errors with:
Xap packaging failed. Unable to load DLL 'zlib114.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Using Process Monitor, I can see that MSBuild finds the dll in the WP7 MSBuild targets directory that installs with the SDK with the only error being "FILE LOCKED WITH ONLY READERS" error to a CreateFileMapping+SyncTypeCreateSection, which it then falls back to a SyncTypeOther, which succeeds. Despite this, MSBuild still continue to look for the dll is all the other standard locations (Framework directory, SysWOW64, etc).
Any thoughts to why it might be failing?
If you're using TFS, Justin Angel has a great post on TFS2010 WP7 Continuous Integration. Given that TFS is just wrapping around MSBuild, you may find this a particularly useful resource. When it comes to doing the unit test integration, Deyan Ginev from Telerik has a series of posts that covers this.
FYI, I ended up fixing the zlib problem by using the dll from the Silverlight SDK, rather than the WP SDK.