I am trying to run some PowerShell commands and my script is failing on the following line:
$ipsr = New-Object Microsoft.Azure.IpSecurityRestriction
The error is:
Cannot find type [Microsoft.Azure.IpSecurityRestriction]: verify that the assembly containing this type is loaded
I am trying to run this “inline” in an Azure PowerShell task as part of my deployment pipeline. Is this supported or do I need to first import an assembly?
I can reproduce your issue. First, it should be Microsoft.Azure.Management.WebSites.Models.IpSecurityRestriction, not Microsoft.Azure.IpSecurityRestriction, then make sure you have installed the Az.Websites powershell module, just use the command below.
Import-Module -Name Az.Websites
New-Object Microsoft.Azure.Management.WebSites.Models.IpSecurityRestriction
Besides, actually we import the module just for the Microsoft.Azure.Management.Websites.dll, so you can also use the command as below, check the path of your .dll file.
Add-Type -Path 'C:\Program Files\WindowsPowerShell\Modules\Az.Websites\1.1.0\Microsoft.Azure.Management.Websites.dll'
New-Object Microsoft.Azure.Management.WebSites.Models.IpSecurityRestriction
Related
I am using VB.Net to open a Powershell runspace using WSManConnectionInfo. The connection works fine. I am trying to run a New-Item command in order to create a new virtual directory.
New-Item "IIS:\Sites\ExternalInventory FTP\TestVT" -Type VirtualDirectory -physicalPath "C:\"
The command works fine when running it locally on the server. However, when ran remotely through the runspace I get an error:
A parameter cannot be found that matches parameter name 'physicalPath'.
I initially tried to use use the New-WebVirtualDirectory command to create the virtual directory, but this led to other errors. I need to use New-Item.
What is causing the difference in behavior of the New-Item command, and how can I use it to create a new virtual directory through the runspace?
Note: I have tried other commands through the runspace and they seem to work as expected.
EDITS
I know that the New-Item command does not have the parameter "physicalPath" listed in the docs: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-item?view=powershell-6
The New-Item command is used in multiple places in the docs to create virtual directory with the physicalPath parameter. See links
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-item?view=powershell-6
https://forums.iis.net/t/1223546.aspx?New+WebVirtualDirectory+does+not+work+when+invoked+remotely+and+a+UNC+path+is+used
As pointed out in the comments, I needed to include the WebAdministration module in my script.
Thanks TheMadTechnitian
I created a VSTS Release Definition with that contains a Azure Powershell script
When I create a release from the following definition everything works until I get to the Azure Powershell script, I get the following log:
2016-08-02T19:06:33.1625377Z ##[command]Import-Module -Name C:\Program
Files (x86)\Microsoft
SDKs\Azure\PowerShell\ResourceManager\AzureResourceManager\AzureRM.Profile\AzureRM.Profile.psd1
-Global 2016-08-02T19:06:37.8986980Z ##[command]Add-AzureRMAccount -ServicePrincipal -Tenant ******** -Credential System.Management.Automation.PSCredential 2016-08-02T19:06:39.0397286Z
[command]Select-AzureRMSubscription -SubscriptionId ******* -TenantId ******** 2016-08-02T19:06:39.1837302Z ##[command]& 'C:\a\e214cea58\ContinuousBuild\drop\Deployment\PrepareIoTSample.ps1'
-environmentName test -configuration debug -webPackageLocation "C:\a\e214cea58\ContinuousBuild\drop\Web\Web.zip"
-webJobPackageLocation "C:\a\e214cea58\ContinuousBuild\drop\WebJob\WebJobHost.zip"
2016-08-02T19:06:40.3037302Z ##[error]Cannot find path
'C:\a\e214cea58\ContinuousBuild\VERSION.txt' because it does not
exist. 2016-08-02T19:06:43.3880731Z ##[error]Version 1.3.2; update to
1.4.0 and run again.
I tried to google the errors but didn't find anything usefull, and I don't see an option to enter a version number. Can someone point me in the right direction?
You can't run a lower version of AzurePS because there can be only one version of Azure PS installed at a time on a single machine.
The online build machines being maintained by Microsoft they all have the same version of Azure PS. (I'm assuming you're using the hosted agent)
I'd suggest you upgrade your script so it runs properly with the new version of Azure PS
I'm using Powershell 4 to install SQL 2014. everything goes ok except at the very end where I have a function that will run a script from a .sql file using invoke-sqlcmd. I get the following error:
"The term 'invoke-sqlcmd' is not recognized as the name of a cmdlet, function, script file..."
If I try and import the sqlps module I get:
The specified module 'sqlps' was not loaded because no valid module file was found in any module directory.
But here's the kicker. If I open a separate PowerShell terminal, IT WORKS THERE. :/ and continues to fail in the initial terminal.
I'm trying to understand why this is so any assistance would be greatly appreciated. I'd like to avoid writing in a reboot once script.
Thanks,
Dan
Existing Powershell session isn't aware about Sql's modules that were just installed. Take a look at environment variable $env:PSModulePath. Compare new shell's variable to existing and you should see a missing path like ...\Microsoft SQL Server\110\Tools\PowerShell\Modules\.
For a work-around, modify the path to include module dir. Like so,
$env:PSModulePath += ";c:\some\path\to\sql"
I'm attempting to use a .NET 4.0 assembly in PowerShell ISE, and trying to change the config file which is used via:
[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $PathToConfig);
[Configuration.ConfigurationManager]::ConnectionStrings.Count always returns "1",and "[Configuration.ConfigurationManager]::ConnectionStrings[0].Name" always returns "LocalSqlServer", and that ConnectionString name is not in my ".config" file.
Note that executing the PowerShell script from a PowerShell command prompt functions as expected. It's just when I execute it from within PowerShell ISE, it doesn't work as expected.
It's because the path to app.config for PowerShell ISE has already been loaded and cached so changing the app.config path afterwards won't make a difference:
stackoverflow.com/q/6150644/222748
Here is an example script that will clear the cached path so it will work under PowerShell ISE:
[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $PathToConfig)
Add-Type -AssemblyName System.Configuration
[Configuration.ConfigurationManager].GetField("s_initState", "NonPublic, Static").SetValue($null, 0)
[Configuration.ConfigurationManager].GetField("s_configSystem", "NonPublic, Static").SetValue($null, $null)
([Configuration.ConfigurationManager].Assembly.GetTypes() | where {$_.FullName -eq "System.Configuration.ClientConfigPaths"})[0].GetField("s_current", "NonPublic, Static").SetValue($null, $null)
[Configuration.ConfigurationManager]::ConnectionStrings[0].Name
Taking off [0] works for me.
([Configuration.ConfigurationManager].Assembly.GetTypes() | where {$_.FullName -eq "System.Configuration.ClientConfigPaths"}).GetField("s_current", "NonPublic, Static").SetValue($null, $null)
I'm currently writing a library in C# and was using PowerShell to quickly test it on some occasions. However, this prevents me from re-building the project as PowerShell obviously still has the DLL open.
Is there a way of unloading the DLL again after adding it with Add-Type? The documentation doesn't seem to have clues on that and the obvious candidate would be Remove-Type (which doesn't exist – there is only one command anyway with Type as its noun). It gets cumbersome to close PowerShell and do all the stuff of navigating to the build directory and adding the type again each time I want to rebuild.
Like the others say, this is a .NET behavior. Assemblies loaded into an AppDomain cannot be unloaded. Only the AppDomain can be unloaded, and powershell uses a single appdomain. I blogged a bit about this some years ago:
https://web.archive.org/web/20170707034334/http://www.nivot.org/blog/post/2007/12/07/WhyAppDomainsAreNotAMagicBullet
When I test like this, I usually keep a shell open and use a nested shell to do tests. start powershell, cd to bin location then run "powershell" to start nested shell (new process.) "exit" to start over, and run "powershell" again.
I find the simplest way to get around this problem is to wrap the Add-Type and the test code inside of a Start-Job. Start-Job will create a background process, and the type will be loaded there. Once you are done, the process goes away and you're free to retry.
Here's an example of how it looks:
$job = Start-Job -ScriptBlock {
Add-Type -path 'my.dll'
$myObj = new-object My.MyTestClassName
$result = $myObj.TestMethod
$result
}
Wait-Job $job
Receive-Job $job
The output from the test method will be echoed to the console.
If your assembly doesn't require a binding context you can do this:
$bytes = [System.IO.File]::ReadAllBytes("Path_To_Your_Dll.dll")
[System.Reflection.Assembly]::Load($bytes)
Here is a complete example that allows to run the Add-Type command as a background job so that the assembly is unloaded once it finishes:
# Start-Job will not preserve the working directory, so do it manually
# Other arguments can also be passed to the job this way
$cd = Split-Path $MyInvocation.MyCommand.Path
$jobParams = #{
'cd' = $cd
}
Start-Job -InputObject $jobParams -ScriptBlock {
cd $Input.cd
Add-Type -Path assembly.dll
} | Receive-Job -Wait -AutoRemoveJob
Receive-Job -Wait will make sure that the output of the job is received since otherwise it will be lost.
I have been facing to similar problem. It is not possible to unload a type/assembly (that's because it applies to .NET framework).
In .NET you can solve it if you crate a new application domain (System.AppDomain) and load the assembly into that domain. It is possible to unload the app domain and that unloads all the dlls as well.
I haven't tried it yet, because for me it is much simpler to close a tab in Console and open new one.
Visual Studio Code:
Settings -> Extensions -> PowerShell Configuration -> Debugging: Create Temporary Integrated Console
Check checkbox: "Determines whether a temporary PowerShell Integrated Console is created for each debugging sessions, usefull for debugging PowerShell classes and binary modules."