TIL – July 7 2016

I am starting a new mini-series called “Today I Learned” to start blogging a bit more about simpler topics, not so much about things that will definitely help you as much as things that helped me (and I will probably forget about in 3 months.)

Today’s topic is about how to get VS Code working with PowerShell 2.0.

Today I learned that VS Code (while awesome) has a few kinks to work out if you want to mix old and new powershell idioms, and its not 100% straightforward how to fix it.

To get to this point I already downloaded Windows Management Framework 5.0 (the announcement on the VS Code site points to a dead link), got VS Code, upgraded Git, and installed the Posh utility when I opened my first file and it suggested I download the extension (pretty cool that.)

I started off having a blast, but as soon as I used Invoke-SQLCommand things got a bit messy:

"Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information."

I have seen this error before and it usually involves modifying an app.config to say “I am totally ok with you mixing modes or whatever, just do what magic I need.”

I found a few related errors until I stumbled on https://github.com/adamdriscoll/poshtools/issues/192 which broke down where I should be looking (~/.vscode) and that I could create a file named

C:Users\%USERNAME%.vscodeextensionsms-vscode.PowerShell-0.4.1inMicrosoft.PowerShell.EditorServices.Host.exe

and place the following content within it:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
      <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
</configuration>

This did not work.

After a second scratching my head I found that it looks like VS Code’s new version of powershell is using a different folder name within the hidden vscode folder, so if you check

C:Users\%appdata%.vscodeextensions

and navigate to the bin folders within it before you make your file you will be fine.

Also, make sure the app.config file matches the name of the executable being invoked (plus the extension .config) in this case I had both Microsoft.PowerShell.EditorServices.Host.exe and Microsoft.PowerShell.EditorServices.Host.x86.exe, made both files, and now I can run everything without issue.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.