I am trying to use ReSharper TaskRunner to run unit tests on a 64-bit assembly. However, for some reason ReSharper keeps starting JetBrains.ReSharper.TaskRunner.CLR4.exe which is a 32-bit app.
I made sure that my assembly specifies 64-bit architecture, I even tried setting default platform architecture to "Force tests to run in 64-bit process" via ReSharper Options dialog.
Nothing helps. It still starts the 32-bit version of TaskRunner.
The only way I was able to make it work is by renaming files as suggested here: nunit debugs in 64-bit, application is in 32-bit
However, we need to run unit tests on both 32-bit and 64-bit assemblies so renaming files every time is not practical.
Any suggestions?
It just started working for no apparent reason. Must be some of those things are are fixed by reboot/reinstall. Although in this case it took multiple reboots.
Related
My Visual Studio 2012 solution has C# projects, VB.NET projects, C++/CLI projects and C++ projects. Currently, I have three platforms: x86, x64 and Win32. When I added x64, I noticed it was used by all projects. I'd like to do the same with x86, so that I can remove Win32.
So I went to Configuration Manager, selected a C++ project and in the platform combo box I only had the options: Win32, x64, New and Edit. If I selected New, the only option available is ARM.
So then I thought of just replacing Win32 with x86 in my .vcxproj. Didn't work (it defaulted to x64). Then I looked at the .sln file, but couldn't see how x64 manages to work for every project.
The IDEs differ too much to get a common platform name for 32-bit code. Otherwise reflective of managed code being rather fundamentally different from C++ code. Managed project platform names can only be AnyCPU, x86, x64. C++ project platform names can only be Win32, x64 and ARM. History plays a role, Win32 comes from the early 1990s, back when Windows NT introduced the 32-bit version of the winapi. Distinguished from the 16-bit version. There was no real opportunity to ever change it again without risking breaking existing projects.
The x86 platform name for managed projects isn't exactly standard either, that was a mistake in VS2010 that you appear to have inherited. VS2012 creates new projects with the AnyCPU platform name like old VS versions used to do. Which pretty accurately describes the true platform for managed code, it runs on any thanks to the jitter. The name is otherwise irrelevant, only the Project + Properties, Build tab settings matter to force a specific jitter to be used at runtime. In other words, if you don't force x86 there then your program is still going to run as a 64-bit process, even though the platform name is x86. That was the VS2010 mistake, it caused a lot of misery.
So you're pretty stuck with this. It is not a real problem, the IDE can handle the mix just fine. You already know about the Build + Configuration Manager dialog, it unambiguously shows which platforms are going to be built when you use Build + Build or press F5.
I have written an application that uses CR for Visual Studio. It deploys and runs fine on 32 bit systems. I want it to work on 64 bit systems too, so I ran CRRuntime_64bit_13_0_7.msi to install the redistributable.
When I select my prerequisites in VS 2012, should I see an entry for CR 64 bit? I don't.
In VS, I set the target CPU to x64 and publish (Clickonce). When I try to install it on my Win 7 64 bit system, I get an error:
Unable to install or run the application. The application requires that assembly CrystalDecisions.ReportAppServer.CommonObjectMode Version 13.0.2000.0 be installed in the Global Assembly Cache (GAC) first.
How can I deploy the 64 bit CR runtime with my application?
Thanks
Maybe there's a bug with the Service Pack 7 version of the files? Have you tried with the Service Pack 8 version that was recently released?
SAP Crystal Reports, Developer version for Microsoft Visual Studio
Is your development environment 32-bit or 64-bit? Because that might have a bit to do with it also. Installing and deploying Crystal has always been a pain (I've been working with it since version 7.0) and to introduce the complexity of 32/64-bit makes it even more fun!
Another thing to point out on that link was that you have to run the "Install executable" to get it to integrate into VS properly. When I did so, it asked me if I wanted to install the 64-bit runtime as my PC was 64-bit, did you get to this point and if so, which version did you choose?
In the app we're working on, we have a routine that inspects all assemblies in the dependencies folder and auto-loads classes with a certain attribute, but when I went to run the app targeting a 64-bit CPU (or even Any CPU) it would give me exceptions when trying to load the Crystal Reports assemblies on start-up, but it would work fine when targeting a 32-bit CPU.
Which leads me to think that perhaps they either don't have their 32/64-bitness sorted properly, or their installer isn't doing what it says it is.
In VS2012, I resolved a BadImageException from running a unit test by going to: TEST-> TEST SETTINGS -> DEFAULT PROCESSOR ARCHITECTURE -> x64.
This works in the built in Visual Studio test window but I cannot find the equivalent settings for ReSharper and so I cannot run the unit tests by clicking on the little nodes to left of the test. This is obviously not critical but really annoying.
Does anyone know where these settings are?
ReSharper will run tests with the bit-ness of the test project. So if your test project is AnyCpu, it will run in an AnyCpu host process, which means 32bit on a 32bit system or 64bit on a 64bit system. If you set your project to be 32bit or 64bit specific, ReSharper will run it in a 32bit or 64bit host process.
So, if your production code is 32 bit specific, you should make your test project 32 bit specific, too. If your production code is 64 bit specific, it should work fine, as long as your test project is 64 bit or AnyCpu.
Similarly, it will use the .net runtime of the test project - .net 2 or .net 4.
These defaults work for the vast majority of cases. I've never had to set it manually, but you can override this behaviour, and force a bit-ness or .net framework version. ReSharper 8 has these settings in the Options dialog (Options -> Tools -> Unit Testing). If you set this when a solution is open, it sets it for the current solution. If there isn't a solution open, it becomes the default for all solutions. You can also set this on a per-test run basis in the unit test sessions window. This setting doesn't persist.
I tried different things that I found in Google and on StackOverflow (including other answers in this topic), but what worked for me is:
ReSharper's Unit Test Sessions window -> on the top panel set Platform dropdown to 64-bit.
My solution is too hacky, but thats the only thing which worked for me
I placed a copy of vstest.executionengine.x86.exe for backup and placed a renamed vstest.executionengine.exe (64bit version) instead of old 32 bit version.
We had a similar issue when trying to setup MSTEST for Sharepoint 2007 - it would keep running in x86 instead of x64. Instantiating SPSite kept saying "The Web application at http://server:port/ could not be found".
Option 1 - Assign Proper Active TestSettings
I started with replacing the EXEs suggested by #valentin-kuzub to confirm it would work - but then realized that we had the wrong Test Settings file active - there were (2) Local.testsettings and TraceAndTestImpact.testsettings. One of them was set to use x86 instead of targeting x64.
Option 2 - Configure RunSettings
Another option is switching from testSettings to runSettings and assigning TargetPlatform.
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<!-- [x86] | x64 - You can also change it from menu Test, Test Settings, Default Processor Architecture -->
<TargetPlatform>x64</TargetPlatform>
<!-- Framework35 | [Framework40] | Framework45 -->
<TargetFrameworkVersion>Framework40</TargetFrameworkVersion>
</RunConfiguration>
Option 3 - Use Test Settings Default Architecture
The last option (which you already tried) is in the XML comments from option #2 -> You can also change it from menu Test->Test Settings->Default Processor Architecture->x64.
When working with high memory code you may find you need to alter the R# test runner config to include
<runtime>
<gcAllowVeryLargeObjects enabled="true" />
</runtime>
You can find this file located at
%localappdata%\JetBrains\Installations\ReSharperPlatformVs12\
JetBrains.ReSharper.TaskRunner.CLR45.x64.exe.config
This path is likely dependudant upon Visual Studio version and may vary upon R# version. This specific path is Visual Studio 2013 with Resharper 9.1. Recurrent issue with Resharper 10. Location of config file is unchanged. https://youtrack.jetbrains.com/issue/RSRP-446178
I just ran into this with ReSharper and MsTests - error "unit test runner failed to run tests incompatible target platform".
Our issue was that the test project wasn't being built.
To fix:
Build
Configuration Manager
Confirm that Build is ticked.
Switch between your Solution Configurations to confirm it's being built in all configurations.
With, Visual Studio 2015, I've found that both x86 and x64 settings will cause this. The solution was to close and restart Visual Studio.
I am working on a project which captures all User Interactions. MSDN tells (this)
SetWindowsHookEx can be used to inject a DLL into another process. A
32-bit DLL cannot be injected into a 64-bit process, and a 64-bit DLL
cannot be injected into a 32-bit process. If an application requires
the use of hooks in other processes, it is required that a 32-bit
application call SetWindowsHookEx to inject a 32-bit DLL into 32-bit
processes, and a 64-bit application call SetWindowsHookEx to inject a
64-bit DLL into 64-bit processes.
My Question is, what happens if an application was built against Any CPU. Do I need to call SetWindowsHookEx from a DLL built against Any CPU.
I have written HookLogger_32.exe loading HookFunctions_32.dll (both x86) and HookLogger_64.exe loading HookFunctions_64.dll (both x64) setting WH_CBT and WH_MOUSE globally (not a specific thread).
The HookLogger_32.exe, HookLogger_64.exe, HookFunctions_32.dll and HookFunctions_64.dll are written in C++.
When I click on a .NET application built against Any CPU, these DLLs get injected (through SetWindowHookEx). The Windows OS hangs & I have to forcefully restart my machine.
When the same .NET application is built against x86 or x64, and when I click on the application after the HookLoggers (both 32 & 64 bit) are started everything is working fine.
Any reasons for this undefined behavior.
The platform on which I am working is a 64-bit machine.
You need to inject from a DLL with a corresponding bitnse - i.e. "any CPU" becomes either 32 or 64 bit at runtime... and your DLL must match the runtime bitness !
Something useful in your situation is known as "side-by-side assembly" (two versions of the same assembly, one 32 and the other 64 bit)... I think you will find these helpful:
Using Side-by-Side assemblies to load the x64 or x32 version of a DLL
http://blogs.msdn.com/b/gauravseth/archive/2006/03/07/545104.aspx
http://www.thescarms.com/dotnet/Assembly.aspx
Here you can find a nice walkthrough which contains lots of helpful information pieces - it describes .NET DLL wrapping C++/CLI DLL referencing a native DLL
UPDATE:
To make hooking really easy and robust see this well-tested and free library - among other things it works with AnyCPU !
I guess your main problem is that you are trying to inject a .NET assembly to native process and that surely won't work. I'm not even sure if SetWindowsHookEx supports injecting .NET assembly in CLR process. The solution to your problem is:
Rewrite/Recompile your dll using native compiler such as C++/Delphi/VB etc, for x86 and x64 platform.
Make sure your dll depends on system libraries only. For example, it shouldn't depend on any dll that doesn't ship with windows, because you may crash target process. You can use "Dependency Walker" tool to identify dependencies.
As mentioned in MSDN, you should have an executable injector for each cpu you wish to support. In this case x86 and x64.
Or you could use a better injection/hooking library such as madCodeHook or Detours. This way you will overcome problem #3, not to mentioned dozens of pros they provide.
Just from your description of the problem my guess is...
Your Any CPU compiled program is loading an x86 stub which is firing your 32bit hook, then the x86 stub checks and sees that the environment has 64bit support and launches the 64bit CLR version.
In this scenario your 32bit hook dll is getting the WH_SHELL message and is trying to inject into a process (the x86 stub) that has already ended OR its injecting the 32bit hook into the 64bit CLR process. Thus your "very ambiguous and needs to be elaborated on" system crash.
If you care to elaborate about what your code is actually doing, then more help (and less generalizations and 'just use program A') will be given. Are you actually injecting code into the process or are you calling SetWindowsHookEx with the dwThreadId of the process.
On a 32-bit computer, it should be pretty obvious was bitness an Any CPU application takes on.
A 64-bit computer gets two separate installations of the .NET Framework: one for each bitness. A .NET application compiled as with Any CPU as the target normally runs on the 64-bit installation, but it can also run on the 32-bit installation if referenced by another application that directly targets x86. Thus, you can only be sure what you're getting if you know how the application is being run: as an independent process, or via reference.
I wouldn't make any assumptions. Don't assume the process is 64-bit on a 64-bit computer: it can potentially be 32-bit. Check it properly to see which mode it is running in. Then, inject from 32-bit or 64-bit accordingly.
The reason that you must use the same bitness as the target process is that, for technical reasons into which I won't get, such hooks cannot cross what is called the SysWOW barrier. SysWOW is what allows 32-bit applications to run on a 64-bit computer, 16-bit applications to run on a 32-bit computer, etc. You are "crossing the barrier" when you communicate between applications running on different sides of SysWOW--that is, one is running within SysWOW (32-bit), and the other is not (64-bit). Simply put, a process must be entirely in or out of SysWOW. Thus, you cannot have add 32-bit code to a 64-bit process, and vice versa.
We are getting new dev machines and moving up to Vista 64 Ultimate to take advantage of our 8gb ram. Our manager wants us to do all dev in 32bit virtual machines to make sure there will be no problems with our code moving into production.
Is there any way to guarantee the resultant programs will work on 32bit os's?
I don't mind using virtual machines, but I don't like how they force you back into a "Single" monitor type view. I like moving my VS toolbars off to my other monitor.
EDIT: We are using Visual Studio 2005 and 2008, VB.NET and/or C#
EDIT: Using Harpreet's answer, these are the steps I used to set my Visual Studio IDE to compile x86 / 32bit:
Click Build and open Configuration Manager
Select Active Solution Platform drop down list
Select x86 if it is in the list and skip to step 5, if not Select <New...>
In the New Solution Platform dialog, select x86 and press OK
Verify the selected platform for all of your projects is x86
Click Close.
Enjoy.
Thank you,
Keith
I do development on 64 bit machines for 32 bit Windows. It's not a problem. You should make sure that your projects are set to compile in x86 mode in order to be conservative. You'll want to go through each project in the solution and double check this. You could also use the AnyCPU setting but that's a little riskier since it will run differently on your dev machine than a 32 bit machine. You want to avoid the 64bit mode, of course.
The problems I've run into are drivers that don't work when the app is compiled for 64 bit (explicitly 64 bit or AnyCPU compiled and running on 64 bit Windows). Those problems are completely avoidable by sticking with x86 compilation. That should reveal all flaws on your dev machines.
Ideally, you could set up a build and test environment that could be executed against frequently on a 32 bit machine. That should reassure your management and let you avoid the VM as your desktop.
As long as you compile your executables as 32 bit, they will run on both 32 bit and 64 Windows machines (guaranteed). Using 64 dev machines has the advantage that you can start testing your code with 64 bit compilation (to check for things like pointers casted to 32 bit integers), this way making the transition to 64 bit easier in the future (should you your company choose to do a 64 bit version).
Compiling for a 64bit OS is an option in the compiler. You can absolutely compile to a 32bit exe from within Vista 64 bit. When you run the app, you can then see in the TaskManager that there is a "*32" next to the process...this means it's 32bit ;)
I believe your managers need some more education on what 64bit OS really means :)
Not an answer to your question, but possibly a solution to your problem: VirtualBox (and probably others) supports "seamless integration" mode, which just gives you a second start bar and lets you drag windows around freely.
Also, and this is an answer to your question, it depends on your compile settings. You can compile for different environments, and you can perfectly compile 32-bit programs on a 64-bit system with Visual Studio. Can't tell you how, but I'm sure some Visual Studio guru could help you out.
We develop a 32-bit application using VS 2005 (2008 soon) and have just purchased some new machines with XP Pro x64 or Vista Business 64-bit on them so that we can take advantage of the extra RAM whilst holding a watching brief on the possibility of doing a 64-bit port if it becomes commercially necessary to do so. We haven't had any problems with doing this other than tweaking some scripts in our development environment etc.
Those developers who weren't included in this upgrade cycle still use 32-bit machines, so these should pick up problems when the unit tests and the application test suite are run as a matter of course before a check-in.
What we also do is to make sure that we have a set of "test build" machines made up of "typical" configurations (XP/Vista, 2/4/8 cores, etc.) that build and test sets of check-ins - we have various different test suites for stability, performance, etc. - before they are added to the integration area proper. Again, these haven't picked up any problems with running a 32-bit application built on a 64-bit OS.
Anyway, as others have already said, I wouldn't expect it to be a problem because it's the compiler that generates the appropriate code for the target OS regardless of the OS that the compiler is actually running on.
yeah, like adam was saying. There's 3 options: MSIL (default), x64, and x86. You can target x64 and it will generate dll's specifically for 64-bit systems, or you can do x86 which will run on 32-bit and 64-bit, but will have the same restrictions as 32-bit on a 64-bit system.
MSIL will basically let the JITer issue the platform specific instruction (at a slight performance penalty compared to a native image)
EDIT: no language, so i'm talking about .net framework languages like vb.net and c#, c++ is a completely different animal.
Found this today:
http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx
x64 Development with .NET
Earlier this year I made the switch to a 64-bit operating system - Vista Ultimate x64 to be exact. For the most part, this process has been relatively painless, but there have been a few hiccups along the way (x64 compatible drivers, mainly, but that's not the point of this discussion).
In the world of x64 development, there have been a few struggling points that I thought I'd outline here. This list will likely grow, so expect future posts on the matter.
In the wonderful world of .NET development, applications and assemblies can be compiled to target various platforms. By default, applications and assemblies are compiled as Any CPU in Visual Studio. In this scenario, the CLR will load the assembly as whatever the default target is for the machine it is being executed on. For example, when running an executable on an x64 machine, it will be run as a 64-bit process.
Visual Studio also provides for 3 specific platform targets: x86, x64 and Itanium (IA-64). When building an executable as a specific target, it will be loaded as a process of that type. For example, an x86-targeted executable run on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64 layer. When assemblies are loaded at runtime, they can only be loaded by a process if their target matches that of the hosting process, or it is compiled as Any CPU. For example, if x64 were set as the target for an assembly, it can only be loaded by an x64 process.
This has come into play in a few scenarios for me:
XNA - XNA is available as a set of 32-bit assemblies only. Therefore, when referencing the XNA assemblies, the executable/assembly using them must be targeted to the x86 platform. If it is targeted as x64 (or as Any CPU and run on a 64-bit machine), an error will be thrown when trying to load the XNA assemblies.
Microsoft Robotics Studio - The XInputGamepadService uses XNA internally to talk to the Xbox 360 controller. See above.
Managed DirectX - While this is already deprecated and being replaced with XNA, it still has its uses. The assemblies are not marked for a specific target, however I had difficulty with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.
Phidgets - Depending on what library you download and when, it may or may not be marked as 32-bit only. The current version (11/8/07) is marked as such, and so requires a 32-bit process to host it.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.