كيف يمكنني الحصول على TFS2010 لتشغيل msdeploy بالنسبة لي من خلال msbuild؟

StackOverflow https://stackoverflow.com/questions/2636153

سؤال

هناك حديث PDC ممتاز متاح هنا من Vishal Joshi الذي يصف ميزات MSDePloy الجديدة في Visual Studio 2010 - وكذلك كيفية نشر تطبيق داخل TFS. (هناك أيضًا حديث رائع من سكوت هانسلمان لكنه لا يذهب إلى TFS).

يمكنك استخدام MSBuild داخل TFS2010 للاتصال بـ MSDeploy لنشر الحزمة الخاصة بك إلى IIS. يتم ذلك عن طريق المعلمات إلى MSBuild.

يشرح الحديث بعض معلمات سطر الأوامر مثل:

/p:DeployOnBuild
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=InProc
/p:MSDeployServiceURL=localhost
/p:DeployIISAppPath="Default Web Site"

ولكن أين الوثائق لهذا - لا يمكنني العثور على أي؟

لقد قضيت طوال اليوم في محاولة للحصول على هذا العمل ولا يمكنني الحصول عليه بشكل صحيح والاستمرار في الانتهاء من أخطاء مختلفة. إذا قمت بتشغيل الحزمة cmd ملفه ينشر تماما. إذا قمت بتشغيل WebDeploy من خلال Visual Studio ، فهو يعمل أيضًا بشكل مثالي.

لكني أريد أن أحصل على النشر بالكامل msbuild استخدام هذه الحجج وليس دعوة منفصلة ل msdeploy أو تشغيل الحزمة .cmd ملف. كيف يمكنني أن أفعل هذا؟

ملاحظة. نعم لدي Web Deployment Agent Service ادارة. لدي أيضا خدمة الإدارة تعمل تحت IIS. لقد حاولت استخدام كليهما.


args أنا أستخدم:

/p:DeployOnBuild=True 
/p:DeployTarget=MsDeployPublish 
/p:Configuration=Release 
/p:CreatePackageOnPublish=True  
/p:DeployIisAppPath=staging.example.com   
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd 
/p:AllowUntrustedCertificate=True

إعطائي:

C: Program Files (x86) msbuild Microsoft VisualStudio v10.0 web microsoft.web.publishing.targets (2660): فشل VSMSDeploy. https://staging.example.com:8172/msdeploy.axd؟site=staging.example.com) لا يمكن الاتصال بها. تأكد من تثبيت خدمة الوكيل عن بُعد وبدء تشغيله على الكمبيوتر المستهدف.) تفاصيل الخطأ: الوكيل البعيد (URL https://staging.example.com:8172/msdeploy.axd؟site=staging.example.com) لا يمكن الاتصال بها. تأكد من تثبيت خدمة الوكيل عن بُعد وبدأت على الكمبيوتر المستهدف. تم استلام استجابة غير مدعومة. كان رأس الاستجابة "msdeploy.response" هو "" ولكن كان من المتوقع "V1". أعاد الخادم البعيد خطأ: (401) غير مصرح به.

هل كانت مفيدة؟

المحلول

IIS7 + إجابة ذات صلة ....

حسنًا - هذا ما انتهى بي الأمر. أكثر أو أقل ، متابعة المنشور بواسطة سيمون ويفر في هذا الموضوع/السؤال.

ولكن عندما يتعلق الأمر بإعدادات MSBuild .. يستخدم معظم الأشخاص هنا إعداد التالي: /p:MSDeployPublishMethod=RemoteAgent الذي ليس صحيحا ل IIS7. استخدام هذا الإعداد يعني أن TFS يحاول الاتصال بعنوان URL: https://your-server-name/MSDEPLOYAGENTSERVICE ولكن للوصول إلى عنوان URL هذا ، يجب أن يكون المستخدم للمصادقة هو المسؤول. وهو محفور. (وتحتاج إلى الحصول على قاعدة admin-override thingy). هذا عنوان URL هو IIS6 على ما أعتقد.

إليك رسالة الخطأ القياسية عند محاولة الاتصال باستخدام RemoteAgent:-

القياسي 401 Frak Off U Suck RemoteAgent ، خطأ

C: Program Files (x86) msbuild Microsoft VisualStudio v10.0 web microsoft.web.publishing.targets (3588): فشل مهمة نشر الويب. http: // الخاص بك web-server/msdeployagentservice) لا يمكن الاتصال بها. تأكد من تثبيت خدمة Agent Remote وبدأت على الكمبيوتر المستهدف.) تأكد من صحة اسم الموقع واسم المستخدم وكلمة المرور. إذا لم يتم حل المشكلة ، فيرجى الاتصال بمسؤول محلي أو خادم. تفاصيل الخطأ: الوكيل البعيد (عنوان URL http: // الخاص بك web-server/msdeployagentservice) لا يمكن الاتصال بها. تأكد من تثبيت خدمة الوكيل عن بُعد وبدأت على الكمبيوتر المستهدف. تم استلام استجابة غير مدعومة. كان رأس الاستجابة "msdeploy.response" هو "V1" ولكن كان من المتوقع "V1". أعاد الخادم البعيد خطأ: (401) غير مصرح به.

لذا .. تحتاج إلى تغيير MSDeployPublishMethod الى هذا:

/p:MSDeployPublishMethod=WMSVC

ال WMSVC تعني خدمة Windows Manager. إنه في الأساس غلاف أحدث على الوكيل البعيد ولكنه يسمح لنا الآن بتصحيح توفير اسم المستخدم وكلمة المرور .. حيث لا يجب أن يكون المستخدم مسؤولًا! (Joy!) حتى الآن يمكنك تصحيح تعيين المستخدمين الذين تريد الوصول إلى .. لكل موقع ..

enter image description here

كما يحاول الآن ضرب عنوان URL: https://your-web-server:8172/MsDeploy.axd <- وهو بالضبط ما The Visual Studio 2010 Publish نافذة لا! (OMG -> Penny Drops !! Boom!)

enter image description here

وإليك إعدادات MSBuild النهائية:

/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish 
/p:MSDeployPublishMethod=WMSVC
/p:MsDeployServiceUrl=your-server-name
/p:DeployIISAppPath=name-of-the-website-in-iis7    
/p:username=AppianMedia\some-domain-user 
/p:password=JonSkeet<3<3<3
/p:AllowUntrustedCertificate=True

لاحظ اسم المستخدم لديه اسم المجال فيه؟ يا بحاجة إلى ذلك ، هناك. أيضًا ، في صورتي ، سمحت لمستخدمي المجال لدينا بالوصول إلى موقع الويب الخاص بالإدارة. على هذا النحو ، فإن حساب المستخدم الجديد الذي أضفته (TFSBUILDService) لديه عضوية في Domain Users المجموعة ... لذلك هذا هو ما يعمل كل شيء.

الآن - إذا كنت قد قرأت كل هذا ، فاحصل على lolcat (لأنها Soooooooo 2007) ....

enter image description here

نصائح أخرى

إليك الخطوات التي عملت لي أخيرًا. أردت الحصول على العمل مع RemoteAgent ، لكنني لم أستطع الحصول على هذا العمل بغض النظر عن ما جربته.

ليس عليك أن تفعل مثل هذا بالضبط ، لكن هذا هو ما جعلته يعمل

  • تكوين WMSVC
  • تأكد من بدء الخدمة
  • قم بتكوين مستخدم IIS (انقر على أفضل اسم ServerName في IIS) وانتقل إلى "مستخدمي IIS Manager". أقترح جعلها مختلفة عن اسم Windows الخاص بك.
  • تأكد من أن حساب المستخدم لـ WMSVC (الخدمة المحلية بالنسبة لي) لديه أذونات الكتابة إلى دليل IIS الذي تستخدمه
  • في حالتي ، أستخدم شهادة SSL (على الرغم من أنها تضرب المضيف المحلي).

تذكر أن هذه كلها حجج إلى MSBuild المضافة ضمن تعريف بناء TFS

/p:DeployOnBuild=True 
/p:DeployTarget=MSDeployPublish 
/p:MSDeployPublishMethod=WMSVC 
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd 
/p:username=sweaveriis 
/p:password=abcd1234 
/p:DeployIisAppPath=staging.example.com/virtual_directory_name
/p:AllowUntrustedCertificate=True

ملاحظة: Traging.example.com هو في الواقع المربع المحلي مع أ ملف المضيفين الإدخال يشير إلى 127.0.0.1. من المحتمل أن يعمل LocalHost هنا أيضًا.

مقالات مفيدة:

استكشاف الأخطاء وإصلاحها MSDeploy قضايا

مزيد من استكشاف الأخطاء وإصلاحها

لسوء الحظ ، لا يوجد الكثير من المعلومات حول هذا الوقت. سأعطيك بعض التلميحات في نهاية هذه الرسالة رغم ذلك.


حول مشكلتك ، لقد رأيت هذا من قبل عندما كنت أحاول النشر باستخدام MSDeploy والحساب الذي كنت أقوم بتشغيله لم يكن لديه أذونات لتنفيذ النشر على الجهاز المستهدف. لذلك تحتاج إلى إلقاء نظرة على الحساب الذي تعمل ببناءك ، ومعرفة ما إذا كان لهذا الحساب حقوق النشر على الجهاز المستهدف. إذا لم يكن الأمر كذلك ، فلديك بعض الخيارات ؛ امنح مستخدم البناء الحقوق ، أو تمرير اسم المستخدم/كلمة المرور فيه.

إذا كنت ترغب في تمرير القيم في ذلك ، فسيتعين عليك تحديد عنصر يسمى MsDeployDestinationProviderSetting وسيتعين على البيانات الوصفية احتواء القيم اللازمة.

لذلك في ملف المشروع الخاص بك (أو عبر الخصائص التي تم تمريرها) ، حدد شيئًا مثل ما يلي.

<PropertyGroup>
    <UserName>USERNAME-HERE</UserName>
    <Password>PASSWORD-HERE
</PropertyGroup>

حول أين يمكنك أن تجد الوثائق ، كما قلت من قبل ، لا يوجد الكثير بعد. ولكن نظرًا لأن خط أنابيب نشر الويب بأكمله يتم التقاطه في أهداف MSBuild والمهام ، يمكنك تعلم الكثير بمفردك إذا كنت على دراية بـ MSBuild. إذا ألقيت نظرة على ملفات .csproj (أو .vbproj) لمشاريع الويب التي تم إنشاؤها باستخدام Visual Studio 2010 ، ستلاحظ عبارة مثل ما يلي:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

هذا يستورد الملف الموجود في%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, ، وهذا الملف بدوره يستورد%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets

لذلك لتعلم هذا الموضوع بالتفصيل في الوقت الحالي ، عليك فحص تلك الملفات والتعلم بنفسك.


سأعمل على شيء سيغطي هذه التقنيات بالتفصيل ، لكن لن يكون ذلك لفترة طويلة ، ولا يزال لدي الكثير لمعرفة نفسي عن هذه الأشياء.

هل يمكنك تجربة صفقة اسم المستخدم/كلمة المرور واسمحوا لي أن أعرف ما إذا كانت تعمل من أجلك؟

واجهت مشكلة مماثلة وكان الحل هو الحصول على المعلمة التالية:

/P: msdeploypublishMethod =عن بعد

فيما يلي جميع المعلمات التي استخدمتها.

/P: deployonBuild = true /p: deploytarget = msDeploypublish /p: msdeploypublishmethod =عن بعد /P: msdeployserviceurl =http: // my-server-name /P: اسم المستخدم = myusername /p: password = myPassword

ملاحظة: أنا لا أستخدم DePloyiisapPath لأنني أقوم ببناء حل وأحاول إنشاء ثلاثة تطبيقات ويب في وقت واحد. كما أعتقد أن msdeployserviceurl يجب أن يكون فقط http://staging.example.com

يبدو أنه عند استخدام INPROC (الذي قد يكون الافتراضي) لـ MSDePloyPublishMethod MSBuild يتجاهل msdeployserviceurl ويحاول دائمًا نشره على الخادم المحلي. لقد قمت بتغييره إلى RemoteAgent ونشرت جميع تطبيقات الويب الثلاثة بنجاح. لقد لاحظت أن ملف الحزمة هو Nolonger الموجود في مجلد myWebApplication_Package ، لكن هذا ليس مشكلة كبيرة بالنسبة لي.

لاحظ أنه يمكنك أيضًا تعيين DeployTarget = Package - سيؤدي ذلك إلى إعداد الحزمة ولكن لا يتم نشرها على الفور. لمزيد من المعلومات انظر منشور المدونة هذا.

بالنسبة لي كانت المشكلة Web Deployment Agent Service لم يبدأ.

بسيط net start msdepsvc تم التصليح. يمكنك أيضًا تعيين وضع بدء التشغيل على هذه الخدمة التلقائية.

الحجج التي أستخدمها هي:

/p:DeployOnBuild=True 
/p:DeployTarget=MsDeployPublish 
/p:MSDeployPublishMethod=RemoteAgent 
/p:MSDeployServiceUrl=stagingserver 
/p:DeployIisAppPath=test.local 
/p:UserName=

تحتاج فقط إلى تحديد اسم الخادم ، وليس المسار الكامل (لا حاجة إلى HTTP).

لاحظ أن اسم المستخدم يترك فارغًا للعمل حول خطأ مع مصادقة NTLM (وبهذه الطريقة يستخدم بيانات اعتماد وكيل بناء TFS للنشر). يرى الجواب المقبول هنا

إليكم كيف حصلت على العمل. كان هذا مع WebDeploy 2.0. أنا أنشر على نفس المجال من جهاز الإنشاء الخاص بنا إلى جهاز WebServer Windows Server 2008 R2. الحساب الذي أستخدمه لنشر هو حساب خدمة على المجال الذي يحتوي على أذونات المسؤول على كلا الجهازين. يتضمن الحل الخاص بي اثنين من مشاريع اختبار الوحدة ، ومشروع MVC3 ، واثنين من المكتبات تحت الحل. إذا لم تقم بتثبيت MVC3 على الخادم ، فأنت تنشر للنظر في http://www.iwantmymvc.com للارشاد.

/p: deployonbuild = true /p: deploytarget = msdeploypublish /p: deployiIsapPpath = "موقع الويب الافتراضي /yourpplicationnamehere" /p:MSDePloyServiceurl=https://devserver02:8172/msdeploy. = yourdomain buildAccount /p: كلمة المرور = كلمة المرور

  1. العنصر الذي ناضلت معه في البداية كان الاقتباسات حول "موقع الويب الافتراضي/الخاص بك الخاص بك" الذي يعطي الخطأ الجزئي:

    MSBuild: خطأ MSB1008: يمكن تحديد مشروع واحد فقط.

    يحدث هذا عندما لا يكون هناك عروض أسعار حول موقع الويب الافتراضي/yourapplicationNamehere

  2. كان الخطأ التالي الذي حصلت عليه بسبب اسم المستخدم وكلمة المرور الخاطئة في بيانات اعتمادي للنشر. أعطت هذا الخطأ:

    C: Program Files (x86) msbuild Microsoft VisualStudio v10.0 web microsoft.web.publishing.targets (3588): فشل مهمة نشر الويب. https: // devserver02: 8172/msdeploy.axd؟ site = افتراضي موقع الويب) لا يمكن الاتصال به. تأكد من تثبيت خدمة Agent Remote وبدأت على الكمبيوتر المستهدف.) تأكد من صحة اسم الموقع واسم المستخدم وكلمة المرور. إذا لم يتم حل المشكلة ، فيرجى الاتصال بمسؤول محلي أو خادم. تفاصيل الخطأ: الوكيل البعيد (عنوان URL https: // devserver02: 8172/msdeploy.axd؟ site = افتراضي موقع الويب) لا يمكن الاتصال به. تأكد من تثبيت خدمة الوكيل عن بُعد وبدأت على الكمبيوتر المستهدف. تم استلام استجابة غير مدعومة. كان رأس الاستجابة "msdeploy.response" هو "" ولكن كان من المتوقع "V1". أعاد الخادم البعيد خطأ: (401) غير مصرح به.

    كان ذلك لأن اسم المستخدم وكلمة المرور لدي في /p: اسم المستخدم = /p: password = لم يتضمن المجال للمستخدم. على الرغم من أنه كان البناء يعمل تحت هذا المستخدم ، إلا أنه لن يتم نشره. لذلك ضربت عنوان URL مباشرة https: // devserver02: 8172/msdeploy.axd في متصفح للتأكد من أنه كان يعمل والتأكد من عمل اسم المستخدم وكلمة المرور. هذا هو المكان الذي لاحظت أنه يجب علي وضعه في المجال/المستخدم للحصول عليه.

آمل أن يكون هذا جيدًا للرد ، لقد تصورت بعض الروح الفقيرة الأخرى مع العثور على هذه الأخطاء وهذا يمكن أن يساعد ...

إذا كان يمكنك نشر تطبيقاتك باستخدام FileCopy ، فمن السهل تخصيص سير عمل TFS للقيام بذلك.

لقد استخدمت نشاط CopyDirectory ، بمساعدة هذه المقالات:

http://www.ewaldhofman.nl/post/2010/11/09/part-14-execute-a-powershell-script.aspx

و

http://geekswithblogs.net/jakob/archive/2010/09/01/tfs-team-build-2010-how-to-place-t-build-utput.aspx

بسيطة جدا وإلى الأمام على التوالي.

  • قمت بتكوين خدمة الإنشاء بحساب مستخدم يحتوي على امتيازات الكتابة على المشاركة المطلوبة.

  • بعد ذلك ، قمت بإنشاء خطوة سير عمل CopyDirectory ، وتكوين المصدر باسم BuildDetail.droplocation + "_publishedWebsites" وللوجهة التي قمت بإنشائها وسيطة ، أسماها "DeployPath" ، والتي يمكن ملؤها في تكوين البناء.

  • الآن لا يزال يتعين علي تنفيذ اختبار للتحقق مما إذا كان البناء ناجحًا قبل استدعاء نشاط CopyDirectory. المقالات التي ذكرتها تظهر كيفية القيام بذلك. كما أنهم يعلمون كيفية استدعاء نص PowerShell بدلاً من CopyDirectory.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top