Testing a WShell Object

Welcome Forums Pester Testing a WShell Object

Viewing 3 reply threads
  • Author
    Posts
    • #180717
      Participant
      Topics: 1
      Replies: 10
      Points: 94
      Helping Hand
      Rank: Member

      For a long time now, our admins have been creating desktop shortcuts using the WShell.Script Objects

      For example:

      # Create a Shortcut with Windows PowerShell
      $TargetFile = "$env:SystemRoot\System32\notepad.exe"
      $ShortcutFile = "$env:Public\Desktop\Notepad.lnk"
      $WScriptShell = New-Object -ComObject WScript.Shell
      $Shortcut = $WScriptShell.CreateShortcut($ShortcutFile)
      $Shortcut.TargetPath = $TargetFile
      $Shortcut.Save()

      Our developers (most of which are previous Java developers now using PowerShell) have been writing using TDD methodology and came across this scenario of creating desktop shortcuts. After some research on the topic, we've been unable to find a more testable (Powershell cmdlets) way to create the code. The question here is:

      1. What is a good way to make this testable?
        1. Maybe create a new mocking class within our tests?
        2. Maybe use New-MockObject but as of right now, we are unable to create it using a good type?
      2. Is there a PowerShell way to create a shortcut without using Wshell?

      We are continuing to research, just thought maybe someone has already come across this and give us a little direction as to the best approach to solve this.

      SideNote: All systems use Powershell 5.1.

    • #180743
      Senior Moderator
      Topics: 8
      Replies: 1136
      Points: 3,903
      Helping Hand
      Rank: Community Hero

      New-Item cmdlet can create shortcut. You can do Get-Help New-Item -Online and see example 7

    • #180767
      Participant
      Topics: 1
      Replies: 10
      Points: 94
      Helping Hand
      Rank: Member

      New-Item cmdlet can create shortcut. You can do Get-Help New-Item -Online and see example 7

      So this worked out great for creating the initial shortcut. The purpose of our shortcut now is to execute a function from a module that executes a form file using a Hidden PowerShell Console Window.

      Here is an example of what created our shortcut:

      New-Item -ItemType "SymbolicLink" -Path "C:\Users\Public\Desktop\powershell.lnk" -Target "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

      This works great for bringing up a PowerShell console. We were hoping to expand on the -Target to add a specific command that executes a form file while keeping the powershell console hidden. An example of what that command would look like is:

      powershell.exe -command "$ {Start-FormFile}" -windowsStyle Hidden

      Adding the extra parameters to the Target creates errors

      New-Item : Cannot find path 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "$ {Start-FormFile}" -windowsStyle Hidden' because 
      it does not exist.
      At line:1 char:1

      Just wondering if anyone would know how to add the extra arguments to the target path of the file.

      We appreciate everything so far, we are still researching for more ideas and we almost to where we need it to be. Testing a New-Item is exactly what we were looking for, just trying to get our tests to pass now.

    • #190426
      Participant
      Topics: 0
      Replies: 5
      Points: 7
      Rank: Member

      Personally, I don't think it will be possible. A symbolic link is a form of file system re-direction that started in Unix/Linux, hence the reason you get drive related errors. Once you add arguments, you have destroyed the normal structure of a symbolic link. It is explained in more detail here:

      https://stackoverflow.com/questions/9701840/how-to-create-a-shortcut-using-powershell

      I would think you could accomplish what you wish by reading the linked document on the binary structure of the .lnk file and using PowerShell to create the link. Likely way more hassle than its worth.

      Just my $.02.

       

Viewing 3 reply threads
  • You must be logged in to reply to this topic.