I wrote a PowerShell script that uses the ReportingServicesTools to deploy reports to a PowerBI Report Server after a project build has terminated. When logging onto the server as myself and executing the script the module is imported successfully and the script executes.
When i execute the target script in a Azure DevOps release pipeline using a Powershell task the following error is returned:
import-module : The specified module 'ReportingServicesTools' was not
loaded because no valid module file was found in any module directory.
At D:\DevOps Agent\DeploySSRS2.ps1:3 char:1 import-module -Name
ReportingServicesTools
We are using a Self-Hosted agent for our releases and builds and the server has PS 5 installed.
I tried:
Moving the module into C:\Program Files\WindowsPowerShell\Modules as MSDN stated this would make the module visible to all users.
Adding the module into C:\Windows\system32\WindowsPowerShell\v1.0\Modules
Referencing the whole path instead of just the module name in the script.
Related
I have created a PowerShell test script, Common.tests.ps1, using Pester against some functions in a PowerShell script, Common.ps1, in the same directory.
There is a TestInitializer.ps1 script, also in the same directory, which uses the Microsoft.Xrm.Data.PowerShell module to create and get records in a Dynamics CRM instance.
When running the PowerShell test script from Visual Studio, the test fails in the Test Explorer with a message:
CommandNotFoundException: The module 'Microsoft.Xrm.Data.PowerShell' could not be loaded. For more information, run 'Import-Module Microsoft.Xrm.Data.PowerShell'.
The same test when run from the PowerShell ISE, however, runs without issue. This would seem to be as if the module is not installed for the instance as run by Visual Studio (I confirmed this when running Get-Module -ListAvailable and seeing that the output did not include the Microsoft.Xrm.Data.PowerShell module for the Visual Studio test), though even explicit calls like Import-Module Microsoft.Xrm.Data.PowerShell -Global -Force don't seem to load the module during the script execution with Visual Studio.
Here's Common.test.ps1:
$here = (Split-Path -Parent $MyInvocation.MyCommand.Path)
. $here\Common.ps1
. $here\TestInitializer.ps1
Describe "SelectionToSingleCharString" {
Context "StringTransforms" {
It "Retrieves a CRM record and uses the optionset value to retrieve a single character" {
SelectionToSingleCharString($crmRecord.new_type) | Should Be "I"
}
}
}
Snippet from TestInitializer.ps1:
# Whether or not this is uncommented does not matter
#Import-Module "$env:SystemRoot\System32\WindowsPowerShell\v1.0\Modules\Microsoft.Xrm.Data.PowerShell\Microsoft.Xrm.Data.PowerShell.psd1" -Global -Force
#$modules = Get-Module -ListAvailable
#Write-Host $modules
# Failing here
Microsoft.Xrm.Data.PowerShell\Connect-CrmOnPremDiscovery -ServerUrl $loginServerUrl -OrganizationName $loginOrgName -Credential $cred
I may instead design the test to use Mock instead of actually attempting to create/read records, though not being able to load external modules and run in Visual Studio would be limiting.
Regarding module install directories (skip this if you are interested in the actual problem):
First you should never install modules to $PSHome\Modules (%Windir%\System32\WindowsPowerShell\v1.0\Modules). This folder is reserved for modules shipped with Windows only.
You should always install your modules used only by your user under the following path:
$Home\Documents\WindowsPowerShell\Modules
And for a system-wide installation under:
$Env:ProgramFiles\WindowsPowerShell\Modules
Further reading regarding installing modules in PowerShell can be found on MSDN.
Regarding your actual problem:
What Visual Studio Version are you using? I have Visual Studio 2017 Community edition installed and can not reproduce your error. My PowerShell is also running as a 64-bit process. Your PowerShell could be running as a 32-bit process. For the 32-bit PowerShell the module directories are different. This would explain why the module you installed isn't showing up in Visual Studio.
You can verify if your PowerShell is running in a 64-bit process with the following command:
PS> [Environment]::Is64BitProcess
True
To make your modules accessible for the 32-bit PowerShell you need to install them under the following path as well:
{$Env:ProgramFiles(x86)}\WindowsPowerShell\Modules
Trying to set up my VSTS windows build agent to accommodate for powershell steps within VSTS but having some problems. Initially it reported that the AzurePS system capability was not present, so I made sure to install the latest Azure modules via the powershell gallery. Now, the AzurePS capability is present but certain powershell commands do not seem to work.
This may not be related to VSTS at all but rather just a configuration issue with my specific powershell installation / configuration. The full error is as follows:
The term 'Select-AzureRMSubscription' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
This error can be seen both in the VSTS release logs of the particular definition I am trying to execute, as well as when attempting to run the Select-AzureRMSubscription command directly on the box itself.
According to This MS Docs for Get-AzSubscription it's located in the module Az.Accounts.
So I had to run:
Install-module Az -AllowClobber -Force
Import-module Az
to make the command avaliable to me.
For me, updating the AzureRM module did the trick:
Update-Module -Name AzureRM
Depending on your system, you may get some messages while installing
Powershell requires NuGet provider version '2.8.5.201' or newer to
interact with NuGet-based repositories. The NuGet provider must be
available in 'C:\Program Files\PackageManagement\ProviderAssemblies'
or
'C:\Users\<...>\AppData\Local\PackageManagement\ProviderAssemblies'.
You can also install the NuGet provider by running
Install-PackagePovider -Name NuGet -MinimumVersion 2.8.5.201 -Force'.
Do you want PowerShellGet to install and import the NuGet provider
now?
[Yes] {No] [Suspend]
Choose "Yes"
You are installling the modules form an untrusted repository. If you
trust this repository, change its installationPolicy value by running
the Set-PSRepository cmdlet. Are you sure you want to install the
modules from 'PSGallery'?
[Yes] [Yes to All] [No] [No to All] [Suspend]
Choose "Yes to all"
Up to three modules will be installed/updated and directly after that, the Select-AzureRmSubscription should work immediately.
Select-AzureRmSubscription b0cabaca-1234-1337-abcd-bebedada1337
# note: this subscription GUID is completely fictional.
# To get the correct one, query your subscriptions with
# Get-AzureRmSubscription
You have to make sure that certain Azure Powershell modules are installed for certain cmdlets to work. You can check which modules are available by running Get-Module -ListAvailable. Select-AzureRMSubscription requires AzureRM module.
You could just install Azure Powershell with its modules using webPI - I've never had problems using it and I've heard that installing PS modules using gallery could cause problems (see here).
You can run azure PowerShell with Azure PowerShell step/task.
Edit your build definition
Click Add build step
Select Deploy catalog > Add Azure PowerShell step/task
the OS in question is server 2012
To install PowerShell on windows server 2012, we should add the .NET Framework 3.5 feature and add the windows PowerShell 2.0 Engine feature.
About how to add features, refer to the link.
Then we can download PowerShell installation package, and install it.
Then we can use windows server 2012 PowerShell to login azure.
You need to use the Set-AzContext,
Select-AzSubscription -SubscriptionName 'SubName' | Set-AzContext
I'm trying to run a release in TFS to Sharepoint Online and I can't seem to import and load the module.
I tried just a straight import-module statement:
Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking
I the found this solution but that's not playing ball either.
How to load PowerShell Module from custom script on vNext build agent?
You will have to load the assembly before you can use the types inside it.
You can use the loadfile method,
[Reflection.Assembly]::LoadFile(“c:\folderwhereyouhavesharepointassemblies/thedllname.dll”)
Import-Module Microsoft.Online.SharePoint.PowerShell
a build with Powershell++ (it comes from Extension Utilities Pack) step keeps failing when I try to run task containing following code Copy-Item -FromSession $cs to copy items from different machine. The error message is
A parameter cannot be found that matches parameter name 'FromSession'.
However, the code does not fail when run from PS console when I'm logged to that machine.
Then I included
(get-command copy-item).Version.ToString()
(get-command copy-item).ModuleName.ToString()
And got version 3.1.0.0 and module Microsoft.PowerShell.Management in PS console and 3.0.0.0 in TFS build step output (module is the same). The version of Powershell is identical in both - 5.0.10586.117.
Looks like the Powershell that is running inside TFS is using different modules.
Can anybody help? Thanks.
Shame on me for not knowing enough about Powershell providers. When wildcard was included in the source path I got this error, without the wildcard it worked fine.
The FromSession parameter is available in PS v5 and not limited to Microsoft.PowerShell.Management 3.0.0.0 (but that is still a mystery to me).
We have a TFS build process using a custom template. The build works fine with the crm solution files successfully being created. We are then attempting to run a powershell script on the post build. This script imports a module. But the commands in the module are not being exposed. Whenever we attempt to invoke a command, we get an error. Along the lines of
The term 'Get-XrmSolution' is not recognized as the name of a cmdlet,
function, script file, or operable program.
It doesn't matter which command we use in that module, we get the same kind of error.
To troubleshoot, we have logged onto the build server under the identity of the build account and can successfully run the script we are attempting to run.
Putting some more output into the script to troubleshoot...
Get-Module lists Xrm.Framework.CI.PowerShell. - Good.
Get-Command -Module "Xrm.Framework.CI.PowerShell" returns nothing. From the console, a number of commands are listed.
Is there something we need to do with the running of powershell post build scripts to enable the contents of an imported module to be seen?
Watch out for the bitness of PowerShell invoked by MSBuild and likewise, the bitness of MSBuild launched by Visual Studio. Certain modules only run in either 32-bit or 64-bit PowerShell and not both. You want to make sure the correct version of PowerShell is getting launched.
IIRC you have to explicitly import the module with no assumption of being loaded on user profile, nor on the script path.
Suppose Module1.psm1 is in the same folder as your script, use something like
Import-Module (Join-Path (Split-Path -Parent $MyInvocation.MyCommand.Definition) 'Module1.psm1')
I had the same problem.
The module was loaded in the 'C:\Program Files\WindowsPowerShell\Modules' folder (64 bits).
It all seemed fine when I logged on as the user, but it failed during TFS build.
Solution: I had to uninstall the module in PowerShell 64 bit and re-install in PowerShell 32 bit.
The module was then installed in 'C:\Program Files (x86)\WindowsPowerShell\Modules' folder.