CODEWITHSUNDEEP
.netpowershell
user2525514
user2525514

Reputation: 3

Custom PowerShell Commandlet Not Importing

I'm having an issue loading a custom PowerShell commandlet on one of our environments. Now, I do know that in my local environment, I can both load and execute the commandlet just fine. I have been searching for hours now, and have found nothing--so I apologize if this is answered out there, but I haven't found an answer yet. The situation:

1) I have written a PowerShell commandlet in .NET, deriving from the System.Management.Automation.Cmdlet class. I was originally targeting .NET 4.5, but am now targeting .NET 4.0. Everything I will go on to describe was tried under both targets.

2) Running the command "Import-Module -Verbose -Name C:\path\to\commandlet.dll" results in the following output locally (where it works): VERBOSE: Loading module from path 'C:....\myDLL.dll' VERBOSE: Importing cmdlet 'Read-Version' versus the output on the 'faulty' environment': VERBOSE: Loading module from path 'C:....\myDLL.dll'

It clearly is not importing my 'Read-Version' cmdlet.

3) I've added the 'powershell.exe.config' and 'powershell_ise.exe.config' files with the following contents: 

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
  <!-- http://msdn.microsoft.com/en-us/library/w4atty68.aspx --> 
  <startup useLegacyV2RuntimeActivationPolicy="true"> 
    <supportedRuntime version="v4.0.30319" /> 
    <supportedRuntime version="v3.5" /> 
    <supportedRuntime version="v3.0" /> 
    <supportedRuntime version="v2.0.50727" /> 
  </startup> 
</configuration>

to the following directories: C:\Windows\System32\WindowsPowerShell\v1.0 and C:\Windows\SysWOW64\WindowsPowerShell\v1.0

4) I realize the security implications of the following, but went ahead and disabled the verification of strong named assemblies via the following PowerShell function:

Function DisableStrongSignValidation
{
   reg DELETE "HKLM\Software\Microsoft\StrongName\Verification" /f
   reg ADD "HKLM\Software\Microsoft\StrongName\Verification\*,*" /f
   if ($env:PROCESSOR_ARCHITECTURE -eq "AMD64")
    {
       reg DELETE "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification" /f
       reg ADD "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification\*,*" /f
    }
    Restart-Service msiserver
}

I verified, the registry entries were created.

5) I have verified that Code Access Security is not the issue, by verifying that 'myDLL.dll' and all of his dependencies have FullTrust.

6) I have attempted loading the assembly by explicitly launching the PowerShell process as an administrator, both the x64 and x86 variants.

7) Copying over the entirety of C:\Windows\SysWOW64\WindowsPowerShell\v1.0 (or even C:\Windows\System32\WindowsPowerShell\v1.0) from my working environment and launching that instance of powershell.exe resulted in no change in behavior.

Hopefully that clearly lays out the situation so far. To recap, this failure is only one environment, and for the life of me I cannot figure out how it differs from my local environment. Obviously there's something, but what? The complete lack of additional information from PowerShell (even with 'Verbose') is quite frustrating. To restate the opening to my question, I did do a heck of a lot of searching (both here and elsewhere)--the CAS solution in Step (5) even came from a StackOverflow post. So if I've missed something, I do apologize in advance.

Upvotes: 0

Views: 395

Answers (1)

Keith Hill
Keith Hill

Reputation: 201622

You're targeting .NET 4.x but PowerShell v2 runs on .NET 2.0 (up to 3.5) by default. Perhaps the app config trick isn't working as advertised? While this is an OK thing to do on your system, I would be hesitant to add an app config file for Powershell.exe to someone else's machine. If you're going for reach, why not just compile against .NET 2.0? If you need .NET 4.0 then require the user to have at least PowerShell v3.

Upvotes: 2

Related Questions