2010-11-17 2 views
33

Я развертывании пакета веб-приложения из командной строки MSBuild к MSDepSvc на IIS6, который работает отлично с помощью следующей команды с использованием базовой аутентификации:Можно ли развертывать MSBuild с помощью встроенной проверки подлинности или только базовой?

MSBuild.exe Web.csproj 
    /p:Configuration=Debug 
    /p:DeployOnBuild=True 
    /p:DeployTarget=MSDeployPublish 
    /p:MsDeployServiceUrl=http://[server name]/MsDeployAgentService 
    /p:DeployIisAppPath=DeploymentTestProject 
    /p:MSDeployPublishMethod=RemoteAgent 
    /p:CreatePackageOnPublish=True 
    /p:username=*** 
    /p:password=*** 

Однако то, что я действительно хотел сделать, это падение параметры имени пользователя и пароля и вернуться к интегрированному auth под идентификатором текущего пользователя. Эта команда переходит на сервер сборки, и я бы предпочел не видеть видимые текстовые учетные данные учетной записи с правами администратора в целевой среде (требуется для MsDepSvc). Я не могу найти какую-либо документацию о том, как это сделать, и при отключении учетных данных возвращается 401, когда я пытаюсь опубликовать.

Что особенно огорчает то, что я могу с радостью запустить команду deploy в пакете со встроенным auth (просто не включайте учетные данные), я просто не могу запустить его из командной строки MSBuild. Я пытаюсь инкапсулировать пакет и развертывать процессы в одну команду без редактирования файлов сборки, и это единственное, что существует в настоящее время.

Есть идеи?

Редактировать После некоторых обсуждений с Сайед и смотрит немного глубже в выходной командной строки после выполнения команды MSBuild выше (без имени пользователя и параметры пароля), следующая команда MSDeploy момент вызова метода:

msdeploy.exe 
    -source:package='[project path]\Web\obj\Debug\Package\Web.zip' 
    -dest:auto,ComputerName='http://[server]/MsDeployAgentService',UserName='***',IncludeAcls='False',AuthType='NTLM' 
    -verb:sync 
    -disableLink:AppPoolExtension 
    -disableLink:ContentExtension 
    -disableLink:CertificateExtension 
    -retryAttempts=2 

Вы можете видеть, что атрибут UserName установлен, а значение является именем пользователя текущего пользователя. Если я выберу это и запустим указанную выше команду, развертывание пройдет отлично.

Итак, почему исходная команда MSBuild вставляет атрибут UserName при вызове MSDeploy? Сейчас это единственный барьер.

+0

Если вы установили UseMSDeployExe в true, команда не включает AuthType = NTLM ??? –

+0

На самом деле, я получаю вызов при публикации из Visual Studio на другую машину в том же домене. После ввода учетных данных, к которым я уже подключился, публикация проходит через тонкую, а основная команда MSBuild DOES показывает AuthType = 'NTLM', но также включает мои учетные данные. Поэтому я возвращаюсь к первоначальной команде! –

+0

Для Visual Studio 2012 вам необходимо полностью опустить свойство/P: UserName. – bmavity

ответ

27

И ответ ...

После моего редактирования выше примерно пользователя текущий идентификатор, продолжающийся к команде MSDeploy, даже если не прошло в оригинальном вызове MSBuild, я попытался реконструировать параметры передать пустое имя пользователя следующим образом:

MSBuild.exe Web.csproj 
    /p:Configuration=Debug 
    /p:DeployOnBuild=True 
    /p:DeployTarget=MSDeployPublish 
    /p:MsDeployServiceUrl=http://[server name]/MsDeployAgentService 
    /p:DeployIisAppPath=DeploymentTestProject 
    /p:MSDeployPublishMethod=RemoteAgent 
    /p:CreatePackageOnPublish=True 
    /p:username= 

который затем генерирует следующую команду MSDeploy:

msdeploy.exe 
    -source:package='[project path]\obj\Debug\Package\Web.zip' 
    -dest:auto,ComputerName='http://[server name]/MsDeployAgentService',IncludeAcls='False',AuthType='NTLM' 
    -verb:sync 
    -disableLink:AppPoolExtension 
    -disableLink:ContentExtension 
    -disableLink:CertificateExtension 
    -retryAttempts=2 

Этот вызов больше не включает атрибут UserName. Короче говоря, если вы не добавите параметр имени пользователя в вызов MSBuild, он будет в любом случае вставлять текущий идентификатор и откладывать на базовый auth, который не будет работать, потому что пароля нет. Если вы укажете параметр имени пользователя, но не придадите ему значения, он не включит его вообще в команду MSDeploy.

+0

Есть ли способ получить диалоговое окно «Публиковать веб-интерфейс» для этого? Кажется непреклоненным при запросе учетных данных, прежде чем генерировать команду msdeploy.exe, поэтому она всегда устанавливает AuthType в Basic. –

+0

Есть очень простой способ решить этот Ядин - просто нажмите «Ввод», не набрав никаких учетных данных, когда вы получите вызов.Easy :) –

+0

Хм, попробовал это, и при использовании UseMsDeployExe = true я вижу, что он определенно оставляет параметры имени пользователя/пароля (наконец!), Но по-прежнему устанавливает AuthType в Basic. Это при использовании WMSvc-адреса (MsDeploy.axd) ... Кроме того, я должен сказать, что нажатие ОК без ввода чего-либо не является интуитивным вообще. –

3

Я посмотрел в Microsoft.Web.Publishing.targets и увидел это:

<PropertyGroup> 
    <NormalizePublishSettings ...> 
    <AuthType Condition="'$(AuthType)'==''" >Basic</AuthType> 
    <!--Supported value for $(MSDeployPublishMethod): WMSVC, RemoteAgent, InProc--> 
    <MSDeployPublishMethod ... >WMSVC</MSDeployPublishMethod> 
    ... 
</PropertyGroup> 

Таким образом, это выглядит по умолчанию Basic аутентификации при работе с MSBuild. Тогда я нашел это http://technet.microsoft.com/de-de/library/dd569001(WS.10).aspx

AuthenticationType определяет тип аутентификации будет использоваться. Возможные значения: - NTLM и Basic. Если указан параметр поставщика wmsvc , аутентификация по умолчанию имеет значение Basic; в противном случае тип аутентификации по умолчанию - NTLM.

Я не пробовал еще, но, возможно, это что-то вроде /p:AuthType=NTLM

+0

Хорошая находка, но то, что она объясняет, не соответствует тому, что я наблюдаю. Способ, которым я читал этот оператор, заключается в том, что развертывание по сравнению с MsDepSvc (т. Е. Не WMSvc), NTLM должно появляться по умолчанию. Я пробовал переключатель AuthType с NTLM, чтобы быть уверенным, но не повезло. –

+0

Я думал, что цель сборки переопределяет поведение MSDeploy по умолчанию, указав собственный по умолчанию для AuthType. Это было просто предположение. –

0

Мне удалось заставить NTLM работать следующим образом, когда служба работает под учетной записью с admin privs на [имя сервера].

Приложение "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ msbuild.exe" \ Test.Web \ Test.Web.csproj/T: Clean/T: Package/P: Configuration = Release

C: \ hudson \ jobs \ Test \ workspace \ app \ Test.Web \ obj \ Release \ Package \ Test.Web.deploy.cmd/Y "/ M: http: // [имя сервера]/MSDEPLOYAGENTSERVICE"/A: NTLM -allowUntrusted

, который генерирует:

"C: \ Program Files \ IIS \ Microsoft Web Deploy \ msdeploy.exe" -source: пакет = "C: \ Hudson \ работа \ Test \ рабочее пространство \ app \ Test.Web \ obj \ Release \ Package \ Test.Web.zip '-dest: auto, computerName =' http: // [имя сервера]/MSDEPLO YAGENTSERVICE ', authtype =' ntlm ', includeAcls =' False '-verb: sync -disableLink: AppPoolExtension -disableLink: ContentExtension -disableLink: CertificateExtension -setParamFile: "C: \ hudson \ jobs \ Test \ workspace \ app \ Test.Web \ obj \ Release \ Package \ RapidPrototypeRequestSystem.Web.SetParameters.xml "-allowUntrusted

-1

Это сработало, я изначально был отвлечен файлом-мишенью, но понял, что моя ошибка была в строке соединения, т. е. пыталась использовать https вместо HTTP.

MSBuild.exe Web.csproj/р: Конфигурация = отладки/р: DeployOnBuild = True/р: DeployTarget = MSDeployPublish/р: MsDeployServiceUrl = HTTP: // [имя_сервера]/MsDeployAgentService/р: DeployIisAppPath = DeploymentTestProject/р : MSDeployPublishMethod = RemoteAgent/p: CreatePackageOnPublish = True/p: username =

 Смежные вопросы

  • Нет связанных вопросов^_^