I'm developing a binary PowerShell module. I've setup the debug tab of the module's project to launch the PowerShell console and import my module. If I press F5 it does so as expected.
The issue that I'm having is that Visual Studio isn't really "attached" to the process. The Modules window is empty and none of my break points are hit.
If I launch PowerShell manually and attach to the process...BOOM! I can debug.
F5ing would be wayyyy better than Build+Launch+Attach over and over again :|
开发者_运维问答Any ideas?
EDIT:
I've found that if I enable unmanaged code debugging I will see modules loaded. This makes sense because PowerShell.exe is unmanaged. The issue now is that in the Modules window all of my assemblies Symbol States are "No native symbols in symbol file". The process "powershell.exe" is "Native" rather than "Managed (v2.0.50727)". It looks like VS is deciding to debug natively rather than in a managed mode. Any way to change this?
I resolved this problem long time ago and do not remember all the details but this trick should help, hopefully.
Create the file C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.config:
<?xml version="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
x64 machine: the file also needs to be copied to C:\Windows\SysWOW64\WindowsPowerShell\v1.0
Note: you may want to remove the line <supportedRuntime version="v4.0.30319"/>
to avoid .NET 4 loaded (on the other hand you actually may want exactly this, e.g. if PowerShell is about to work with .NET 4 assemblies).
If you use PowerShell in your application that hosts PowerShell then create the similar file your_app.exe.config
in the application home directory.
As far as I remember the line <startup useLegacyV2RuntimeActivationPolicy="true">
actually helps VS debugger to work properly.
精彩评论