Fixing PowerShell Scripting Error in C# Code: "Exception calling ""ToString"" with ""0"" argument(s). There is no Runspace available to run scripts in this thread."

A bit of a niche post here, but maybe someone is searching the interwebs and this will help save some time. When running a PowerShell script in C# leveraging the System.Management.Automation library, you might run into some neuanced issues that behave differently than when running PowerShell commands directly via the command line. Here is one instance, take the following PowerShell command to install a new Windows Service:

New-Service -Name "MyWindowsService" -BinaryPathName "C:\SomePath\1.0.1\MyWindowsService.exe"

When running this in a PowerShell terminal, it will generate the following output which as documented is an object representing the new service:

Status   Name               DisplayName
------   ----               -----------
Stopped  MyWindowsService   MyWindowsService

This is actually helpful output for a human, and maybe even for logging, bu when running this same command in C# via a PowerShell instance, the command will technically work, but you'll get the following cryptic error:

"The following exception occurred while retrieving the string: ""Exception calling ""ToString"" with ""0"" argument(s): ""There is no Runspace available to run scripts in this thread. You can provide one in the DefaultRunspace property of the System.Management.Automation.Runspaces.Runspace type. The script block you attempted to invoke was: $this.ServiceName""""", System.Object,System.ServiceProcess.ServiceController,System.WeakReference`1[System.Management.Automation.Runspaces.TypeTable], System.Management.Automation.PSObject+AdapterSet,None,System.Management.Automation.DotNetAdapter,"",System.Management.Automation.PSObject+AdapterSet, System.ServiceProcess.ServiceController,System.ServiceProcess.ServiceController,"PSStandardMembers {DefaultDisplayPropertySet}",False,False,False,False,False, "","",None

OK not very helpful. It took a while but I deduced the output from the New-Service cmdlet was causing this issue. There are 2 ways I found to handle this.

1. Suppress the Output: Since this is running in C# without human intervention, pipe in the option to suppress the output if you are not logging it or using it for some meaningful purpose. Remember, you can still get the status by using Get-Service to inspect the newly installed service, as opposed to reading the output. Use the updated command to accomplish this:

   New-Service -Name "MyWindowsService" 
   -BinaryPathName "C:\SomePath\1.0.1\MyWindowsService.exe" | out-null
   

2. Return the Output to a Variable: The other option is simply to return the output of the cmdlet typically for use to inspect. This could be done with the following updated statement:

   $newServiceResult = New-Service -Name "MyWindowsService" 
   -BinaryPathName "C:\SomePath\1.0.1\MyWindowsService.exe"
   

   Keep in mind he return value is of type System.ServiceProcess.ServiceController, so you can use that as needed.

For my needs I prefer option #1, as I don't need to inspect the return of New-Service and as mentioned can use Get-Service to further inspect any Windows Service status at this point. With either method though you will no longer get the cryptic error as previously shown.

Visual Studio Code Error with TypeScript Project: "Option 'project' cannot be mixed with source files on a command line"

If you create a TypeScript project in Visual Studio code in a path that contains spaces, you might end up getting the following error after configuring your build task and building the application:

> Executing task: tsc -p "c:\Projects\Test Harness Applications\TypeScript\MyTypeScriptApp\tsconfig.json" <
error TS5042: Option 'project' cannot be mixed with source files on a command line.
The terminal process terminated with exit code: 1

Notice the path I used to create the application contained spaces: 
"c:\Projects\Test Harness Applications\TypeScript\MyTypeScriptApp"

After a little digging I found this GitHub open issue: https://github.com/Microsoft/vscode/issues/32400. The good news is according to the information within that link, this is in process to be fixed in an upcoming version of Visual Studio Code (currently 2/2018). In the interim the solution is just to make sure the full path to your application does not contain any spaces. I verified that by doing this, the compiler issue will go away, and the project build successfully.

Solving a "The section is marked as being protected..." Error When Decrypting a .config With aspnet_regiis.exe tool

If you use the aspnet_regiis tool to encrypt sections of a .config file then you are ahead of the game is securing sensitive information with the apps configuration. If you have not used it before, I suggest trying it out sometime. However recently I came across an error while decrypting the 'appSettings' section that was as follows:

"The section is marked as being protected, but it does not have the correct format. It should contain only the <EncryptedData> child node."

It turns out that a new key that was auto generated in this particular project dealing with WCF was injected between the <EncryptedData> nodes (as shown below).

      </CipherData>
    <add key="ClientSettingsProvider.ServiceUri" value="" />
  </EncryptedData>

Once I removed the new key and attempted the decryption, everything worked properly! So if you come across this error, see if any new keys have been added (or any other elements for that matter) between the <EncryptedData> nodes because it will cause this error.

Help! My .NET Setup Package Is Throwing a System.BadImageFormatException Error 1001

Recently I had a WCF service install package that was upgraded from VS.NET 2008 to VS.NET 2010 fail with the following error message upon installing it locally on my machine:

"Product: MyWCFService -- Error 1001. Error 1001. Exception occurred while initializing the installation: System.BadImageFormatException: Could not load file or assembly 'file:///C:\Program Files\MyApps\WCFServices\MyWCFService.WinServiceHost.exe' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.."

You might also see the following warning issues by the compiler:

"The target version of the .NET Framework in the project does not match the .NET Framework launch condition version '3.5.30729 '. Update the version of the .NET Framework launch condition to match the target version of the.NET Framework in the Advanced Compile Options Dialog Box (VB) or the Application Page (C#, F#)."

Well this was interesting to me because this was being displayed on a machine that has everything: .NET Framework 4.0, tools, you name it. There should be nothing missing. That's the 1st place to start obviously - make sure the .NET Framework is installed on the target machine.

However this was not the case in my scenario. It turns out even though all of my project comprising the setup package targeted the .NET Framework 4.0, and even the Setup package prerequisites indicated the .NET Framework 4.0, there was still 1 piece of the puzzle missing.

The problem: under the "Detected Dependencies" list for the setup project the 1st item listed was "Microsoft .NET Framework". Refreshing the dependencies does nothing for this value; it must be reconfigured manually. Double click the "Microsoft .NET Framework" item to bring up the "Launch Conditions" window and properties. In the 'Properties' window, change the 'Version' attribute to .NET Framework 4.0 (or whichever framework for your scenario). The Launch Conditions window is displayed below. After making the change, the installer package worked perfectly and installed without issues.