Best practices on using 32-bit PowerShell on 64-bit and 32-bit systems

Hi, I’m using PowerShell 2.0/3.0 locally and remotely for software testing and are going to use assemblies of the application under test to substitute GUI clicks (locally) with programmatic calls to objects (remotely). However, there is a problem: many assebmlies, just by historical reasons, are compiled as 32-bit, not any cpu.
Nothing appeals to me, running a separate 32-bit process nor forcing scripts to run in 32-bit mode.

Maybe, the PowerShell community could recommend whether use or don’t use 32-bit shell, and how to use? I want to decide whether move to 32-bit PowerShell is worth attempting or isn’t.

Here are my current state:

  • Running code remotely via PSRemoting (Invoke-Command) - how to force 32-bit? I found this and didn’t try it yet in PSRemoting. Is there a practive to force WinRM to run code in a specific architecture?

  • Running code remotely via RemoteApp. I can fix it as RemoteApp I use is a mere .cmd that runs powershell ("powershell.exe … -command “& {… }”). I need to generate different command files for hosts with different architectures, however it seems not a big evil.

  • Running code locally. This could be also a nightmare: I use many server-oriented modules like ActiveDirectory, Exchange snap-in, Sharepoint snap-in, etc, etc. among others.

Questions:

  • how to run PowerShell x86 in WinRM on 64-bit operating systems?
  • do many Microsoft’s modules support the 32-bit mode?
  • does anybody have similar experience? How such things (a separate 32-bit process or forcing to always use 32-bit PowerShell) work at a whole, reliably?

The problem was solved by using the Start-Job cmdlet with the -RunAs32 parameter (the most of my use cases are to work on a server (i.e. 64-bit) and call api/cmdlets that support only 32-bit architecture. Sometimes, vice versa).
A short good example is . I never before needed this parameter, so I forgot completely about it.