We are building a C# application that uses different Powershell modules:
- ActiveDirectory Module
- Exchange 2010 cmdlets
- 3 custom made modules that use a mix of the AD module cmdlets and the Exchange 2010 cmdlets
Testing was going smoothly until we got to test PS functions that are using Exchange 2010 cmdlets.
In command-line mode, the modules functions were working perfectly. When invoked in C# code, we ran into what I would call the "deserialized objects" wall.
Many functions that depended on specific properties and methods of the actual .NET objects weren't working anymore due to this.
My question:
Is it possible to use the real (non deserialized) objects when invoking Exchange 2010 PS cmdlets within C# code, assuming the following:
- We are running the code directly on a 2008 R2 server with the Exchange management Tools installed (Exchange 2010 SP3 UR5)
- The "real" .NET objects are fully available when running the PS functions with EMS on that same server.
We have extensively searched for a solution but most of the suggestions and info we found point to C# code to connect to Exchange via Remote PS, thus yielding deserialized objects.
Is there a way to do this or are we wasting our time and should change the PS code to work with the deserialized version of the objects (that would be a serious bummer BTW)?
If it's possible, we would very much appreciate to know which code is necessary to properly create and configure a PS session / runspace that would allow full access to the Exchange .NET objects.
Thanks in advance
====
Michel Dube
P.S. I am the PS developper, not the C# one. So be gentle with me... ;). I am helping a collegue (the C# developper) to properly use the module I developped in the C# application.