Проблемы с использованием расширений SQL Server 2008 R2 PowerShell вне SQLPS

Question

Мне бы хотелось, чтобы расширения SQL Server PowerShell были доступны мне всякий раз, когда я запускаю PowerShell, загружая оснастки в моем скрипте profile.ps1.Я нашел статью здесь с примером скрипта, который показывает, как это сделать, и это прекрасно работает на моем 32-битном Windows XP.

К сожалению, на моем 64-битном компьютере с Windows 7 это взрывается.Если я пытаюсь запустить этот сценарий с 64-разрядной оболочкой PowerShell, я получаю:

Add-PSSnapin : No snap-ins have been registered for Windows PowerShell version 2.
At C:\Users\xxxx\Documents\WindowsPowerShell\profile.ps1:84 char:13
+ Add-PSSnapin <<<<  SqlServerCmdletSnapin100
+ CategoryInfo          : InvalidArgument: (SqlServerCmdletSnapin100:String
[Add-PSSnapin], PSArgumentException
+ FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand

Если я запускаю его вместо этого в 32-разрядной оболочке PowerShell, я получаю:

Get-ItemProperty : Cannot find path 'HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds \Microsoft.SqlServer.Management.PowerShell.sqlps' because it does not exist.
At C:\Users\xxxx\Documents\WindowsPowerShell\profile.ps1:39 char:29
+     $item = Get-ItemProperty <<<<  $sqlpsreg
+ CategoryInfo          : ObjectNotFound: (HKLM:\SOFTWARE\...owerShell.sqlps:String) [Get-ItemProperty], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetItemPropertyCommand

Я хотел бы иметь возможность запустить это в 64-битной PowerShell, если это возможно.С этой целью я отследил то, что, как мне показалось, было расширением PowerShell, и в 64-разрядном PowerShell с повышенными правами администратора я запустил:

cd "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn"
installutil Microsoft.SqlServer.Management.PSProvider.dll
installutil Microsoft.SqlServer.Management.PSSnapins.dll

Без кубиков.Хотя казалось, что installutil показывал успех, я все равно получаю сообщение об ошибке «Никаких оснасток не зарегистрировано для Windows PowerShell версии 2» при запуске сценария.

У всех есть какие-либо предложения относительно того, куда я иду отсюда

Answer 1

Я без проблем использовал этот скрипт на машинах x64. Проблема с вызовом x86 заключается в том, что скрипт ищет разделы реестра, которые в экземпляре x64 доступны только из PowerShell x64. Для вызова x64 вы можете попробовать зарегистрировать оснастки, так как это сообщение об ошибке, которое вы получаете. Запуск от имени администратора ...

Изменить это:

cd $sqlpsPath
Add-PSSnapin SqlServerCmdletSnapin100
Add-PSSnapin SqlServerProviderSnapin100 

к этому:

cd $sqlpsPath
$framework=$([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory())
Set-Alias installutil "$($framework)installutil.exe"
installutil Microsoft.SqlServer.Management.PSSnapins.dll
installutil Microsoft.SqlServer.Management.PSProvider.dll
Add-PSSnapin SqlServerCmdletSnapin100
Add-PSSnapin SqlServerProviderSnapin100    

Еще лучшее решение - не использовать add-pssnapin, а превратить sqlps в модуль. У меня есть запись в блоге здесь: http://sev17.com/2010/07/10/making-a-sqlps-module

Обновление для SQL Server 2012 - теперь поставляется модуль sqlps, который можно установить вместо приведенного выше блога: http://www.microsoft.com/en-us/download/details.aspx?id=35580

Answer 2

Я понимаю, что это немного более старый вопрос, но со стандартной стандартной установкой Windows и SQL Server 2012 вы можете просто напрямую использовать команду Invoke-Sqlcmd , не загружая ничего заранее, поскольку она автоматически импортирует модуль sqlps. Однако, если позволить этому сделать это, это часто вызывает проблемы, поэтому импортируйте модуль самостоятельно со строками ниже в том же месте в вашем коде, которое вы использовали для использования команд add-pssnapin

$cur = Get-Location
Import-Module 'sqlps' –DisableNameChecking
Set-Location $cur

Аналогично тому, что размещено на этом веб-форуме MS .

Приведенная выше строка модуля импорта меняет текущий путь на что-то, что делает строки пути UNC, такие как "\\ server \ share \ path \ filename.ext", не работает с большим количеством командлетов cmd. Поэтому мы сохраняем текущий путь до и меняем его обратно после команды import-module.

Answer 3

Возможно, что сборки оснастки скомпилированы для x86 только из-за зависимостей от собственных 32-битных объектов SMO COM.Если бы было возможно запустить их в 64-битной оболочке, я почти уверен, что MS поставила бы управляющие оболочки x86 и x64.