I have the following code that creates a PowerShell runspace with the Exchange 2010 snap in loaded.
Dim runspaceConfig = RunspaceConfiguration.Create()
Dim snapInException As PSSnapInException = Nothing
runspaceConfig.AddPSSnapIn("Microsoft.Exchange.Management.PowerShell.E2010", snapInException)
Dim runspace = RunspaceFactory.CreateRunspace(runspaceConfig)
runspace.Open()
Since installing Visual Studio 2012 I started getting the following error when executing the line that adds the snap-in to the runspace config.
System.Management.Automation.Runspaces.PSSnapInException occurred
HResult=-2146233087
Message=Cannot load Windows PowerShell snap-in Microsoft.Exchange.Management.PowerShell.E2010 because of the following error: The type initializer for 'Microsoft.Exchange.Data.Directory.Globals' threw an exception.
Source=System.Management.Automation
WasThrownFromThrowStatement=False
StackTrace:
at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.LoadCustomPSSnapIn(PSSnapInInfo mshsnapinInfo)
at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.LoadPSSnapIn(PSSnapInInfo mshsnapinInfo)
at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.LoadPSSnapIn(PSSnapInInfo mshsnapinInfo, PSSnapInException& warning)
at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.DoAddPSSnapIn(String name, PSSnapInException& warning)
at System.Management.Automation.Runspaces.RunspaceConfiguration.AddPSSnapIn(String name, PSSnapInException& warning)
I have been able to confirm that nlog is somehow causing this issue. The combination of creating an nlog logger prior to creating the powershell runspace results in the error.
If I remove the nlog config section from my app config and just create an empty nlog logger then the snap-in is loaded with no error. Also, If I leave the nlog config present in my app config but don’t create an nlog logger the snap-in is also successfully loaded.
- I have tried building the project in both x64 and x86.
- I have re-installed the exchange management tools.
- I have tried testing on another machine in the exchange environment.
If anyone can provide any suggestions that may help me solve this problem I will be greatful.
Thank you
It appear to be a know bug. There is a Microsoft connect report:
https://connect.microsoft.com/VisualStudio/feedback/details/770748/powershell-exception-after-4-5-upgrade#tabs
Microsoft's response is that they have "logged [the] issue with the Exchange team"
As a workaround you can do one of the following:
I have investigated the actual bug in the Microsoft Exchange assemblies, and the problem was the ExTraceConfiguration class (internal) from the Microsoft.Exchange.Diagnostics.dll assembly enumerates all loaded assemblies in the current app domain. If it finds System.IdentityModel or System.ServiceModel, it uses reflection to configure some tracing for them. But the reflection code is not compatible with the .net 4.5 ServiceModel and an error occurs. After the error is detected (a null condition is checked) a trace is tried, but the code is currently in the process of configuring tracing so => hard crash.
The solution is to use reflection on the Microsoft.Exchange.Diagnostics.dll, load up the ExTraceConfiguration type and run it's type initializer:
before System.ServiceModel has had a chance to load yet in your app domain. This initializer is a static constructor which can only run once per process, so after that you are safe to load ServiceModel if you need it.
I have exactly the same issue with the same error output with my production server. However, I have a test server with the same configuration using .Net 4.5 framework but not having this issue. So i dont think uninstalling .Net 4.5 will resolve my issue.
My solution is I've found that in the production server ASP.Net Impersonation setting in IIS was enabled.
After i disable it, my powershell runspace can be created, the "Microsoft.Exchange.Management.PowerShell.E2010" snapin can be added an my application is working fine!
Seems like it having some sort of a permission issue.
After further investigation I figured out that .NET 4.5 is an in place update meaning that .NET 4.0 is overwritten and replace with .NET 4.5 when installed. I don't know what changed in .NET 4.5 that causes this but the issue is resolved by uninstalling .NET 4.5 and switching back to Visual Studio 2010. Hopefully Microsoft will have some update in the near future that will resolve the issue and allow me to use Visual Studio 2012 again.
See the following article for more info about the in place update. http://www.devproconnections.com/article/net-framework/net-framework-45-versioning-faces-problems-141160