locked
Test Fails Due to Moles Under 64-bit Process

    Question

  • I am using version 0.92 of the Pex and Moles framework with MSTest.  Everything runs fine when the Unit Tests settings are left as default for forcing the tests to run in a 32 bit process.  However, once I change it to run the tests in 64 bit process on a 64 bit machine then the test that has the [HostType("Moles")] Attribute fails with the following error: "The host type 'Moles' cannot be loaded for the following reason: The key 'Moles' cannot be found."  I did install the 64 bit version of the Pex and Moles framework.  Is there a registry value that is missing to make this work?  Or do I need to install both the x86 and x64 versions on the same PC to support this?
    Tuesday, June 08, 2010 9:14 PM

Answers

  • Not sure if you're still dealing with this, but FWIW:

    I was able to get our unit tests running in x64 mode by exporting the appropriate registry key to a text file, and then removing the path segment for the WOW 64 redirection.  This key will be there...export it to a .reg file:

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\EnterpriseTools\QualityTools\HostAdapters\Moles

    Then open the .reg file in a text editory (don't just double click...) and remove the "Wow6432Node" segment of the path.  Save and then execute the .reg file...this will setup the Host so 64bit processes can find it.

    The other thing I did (not sure if this was necessary) was add the [assembly:MolesAssemblySettings(Bitness=MolesBitness.x64)] attribute to the assembly properties for my moles projects.  Again, not sure if this was necessary.

    After doing this, the everything seems to work in 64bit mode.  The only problem seems to be that errors from the x64 hosts can be reported in a misleading way.  I had just updated my moles version, and kept getting errors from the VS test run saying that it could not reflect over certain assemblies.  Turned out I just needed to update the references to the latest moles versions and rebuild the existing moles.

    • Marked as answer by A. Gritt Tuesday, July 20, 2010 2:22 PM
    Saturday, July 03, 2010 11:47 PM
  • I think you should report this bug on the Visual Studio Unit Test forums.

    In order to make Moles work, revert the Host settings to 'Run tests in 32bit process', and use the MolesAssembliesSettings to tell Moles to launch the process as x64.


    Jonathan "Peli" de Halleux - Like Pex and Moles on Facebook!
    • Marked as answer by A. Gritt Wednesday, June 09, 2010 7:12 PM
    Wednesday, June 09, 2010 12:59 PM

All replies

  • This is a general issue with MSTest: Host types do not work when you specify to run on 64-bit. It is a bug where MSTest tries to read from the wrong registry. (Try the Asp.Net host, you'll get the same experience).

    In order to run the Moles in a x64 process, add the following attribute to your test project:

        [assembly: MolesAssemblySettings(Bitness = MolesBitness.x64)]

     

     


    Jonathan "Peli" de Halleux - Like Pex and Moles on Facebook!
    Wednesday, June 09, 2010 1:26 AM
  • Thanks for the information.  Sounds like a rather significant issue with MSTest.

    I have tried implementing the specified attribute and I am still getting the same error message.  I made sure to do a complete rebuild of the solution.  After running the tests I did find the following information in the Output Pane:

    2010-06-09 07_28_23.trx: (Line: 12, Position: 10). XSD violation: The element 'Hosts' in namespace 'http://microsoft.com/schemas/VisualStudio/TeamTest/2010' has invalid child element 'Host' in namespace 'http://microsoft.com/schemas/VisualStudio/TeamTest/2010'. List of possible elements expected: 'AspNet, DeviceHostRunConfigData' in namespace 'http://microsoft.com/schemas/VisualStudio/TeamTest/2010' as well as any element in namespace '##other'.

    Currently the settings I have in the Hosts tab of the Test Settings are:

    Run in default host

    HostType: Default

    Run tests in 64 bit process on 64 bit machine

    Wednesday, June 09, 2010 12:32 PM
  • I think you should report this bug on the Visual Studio Unit Test forums.

    In order to make Moles work, revert the Host settings to 'Run tests in 32bit process', and use the MolesAssembliesSettings to tell Moles to launch the process as x64.


    Jonathan "Peli" de Halleux - Like Pex and Moles on Facebook!
    • Marked as answer by A. Gritt Wednesday, June 09, 2010 7:12 PM
    Wednesday, June 09, 2010 12:59 PM
  • I put a post up in the Visual Studio Unit Test forums.  Changing it to the 32 bit process works but it would be nicer if I can get it working as a 64 bit process so that our unit testing matches our QA and Production environments.
    Wednesday, June 09, 2010 7:14 PM
  • Not sure if you're still dealing with this, but FWIW:

    I was able to get our unit tests running in x64 mode by exporting the appropriate registry key to a text file, and then removing the path segment for the WOW 64 redirection.  This key will be there...export it to a .reg file:

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\EnterpriseTools\QualityTools\HostAdapters\Moles

    Then open the .reg file in a text editory (don't just double click...) and remove the "Wow6432Node" segment of the path.  Save and then execute the .reg file...this will setup the Host so 64bit processes can find it.

    The other thing I did (not sure if this was necessary) was add the [assembly:MolesAssemblySettings(Bitness=MolesBitness.x64)] attribute to the assembly properties for my moles projects.  Again, not sure if this was necessary.

    After doing this, the everything seems to work in 64bit mode.  The only problem seems to be that errors from the x64 hosts can be reported in a misleading way.  I had just updated my moles version, and kept getting errors from the VS test run saying that it could not reflect over certain assemblies.  Turned out I just needed to update the references to the latest moles versions and rebuild the existing moles.

    • Marked as answer by A. Gritt Tuesday, July 20, 2010 2:22 PM
    Saturday, July 03, 2010 11:47 PM
  • Your fix is correct - our installer is not creating the registry entries for the x64 host.

    With respect to the confusing errors of Moles assemblies not being regenerated, we are working on a MSBuild integration of our compilation which should fix most of those issues - no more checked in .dlls.


    Jonathan "Peli" de Halleux - Follow Pex and Moles on Facebook!
    Tuesday, July 06, 2010 6:46 AM
  • Yes I was indeed still having the issue.  Thanks for the updated information.  This solution worked for me.  I have noticed this type of issue quite a bit with the release of Visual Studio 2010 even though it is not Visual Studio specific but rather 64 bit Windows that is the issue and how the various programs are handled by the registry.  The other instance I had was trying to use some PowerShell commandlets for AppFabric via a website which was running in Cassini which is a 32-bit only process and the Commandlets were installed for 64-bit only.
    Tuesday, July 20, 2010 2:25 PM