4

I've created a web part, debugging it on a test Sharepoint 2010 install on my local workstation. I'd like to test it on our production server. It seems that I won't be able to use Build --> Deploy to accomplish this, and I have to deal with my assembly and .webpart file.

What are the steps to accomplish this?

Improve this question
1
  • You test it on a test/integration/acceptance server, not a production server.
    – Bart
    Commented Aug 13, 2011 at 9:14

3 Answers 3

Reset to default
13

SharePoint solution packages consist of a .WSP file that you can create using Visual Studio (or manually if you so wish).

Before deploying to a production environment, I recommend you take a look through Deploy solution packages (SharePoint Server 2010).

Basically you need to add your solution to the solution database of a SharePoint Server farm using the Add-SPSolution PowerShell cmdlet, then deploy the solution using either Central Administration or the Install-SPSolution PowerShell cmdlet.

Both installation options above provide a choice of installing to either a single Web application, or all Web applications.

Improve this answer
1
  • hahaha, we both answered the question with the same link. I'm whacking mine...you beat me to it. :)
    – Rob D'Oria
    Commented Aug 12, 2011 at 19:41
4

The deploy action creates a .WSP file in your bin\debug or bin\release folder...depending on what you built. You can use that file to deploy the solution...everything you need should be in that package assuming the package was built correctly.

MSDN reference on deployment here: http://technet.microsoft.com/en-us/library/cc262995.aspx

Improve this answer
1
  • there is nothing wrong with multiple answers, even if they are the same (especially since we try to improve our answer/question ratio on Area51 so we can get out of beta;-)
    – Anders Rask
    Commented Aug 12, 2011 at 21:08
1

Alternatively you can create some .bat files and then run them from command prompt as Administrator:

1. Add.bat

"C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm.exe" -o addsolution -filename "C:\YourSolution.wsp"

"C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm.exe" -o deploysolution -name "YourSolution.wsp" -immediate -url http://YourDomain -allowgacdeployment -allowcaspolicies

2. Retract.bat

"C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm.exe" -o retractsolution -name "YourSolution.wsp" -immediate -allcontenturls

3. Delete.bat

"C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm.exe" -o deletesolution -name YourSolution.wsp

Additional resources:

Index for Stsadm operations and properties

Improve this answer
4
  • 2
    I think powershell command are best practice and more flexiple to add custom commands to deploy scripts as well.
    – SAV
    Commented Aug 13, 2011 at 11:11
  • What's wrong with STSADM? Where does it say powershell is a best practice?
    – Kit Menke
    Commented Aug 13, 2011 at 17:20
  • @Kit Menke "In the SharePoint administration context, Windows PowerShell supersedes the Stsadm.exe administration tool. All current and future development of script and administrative files in SharePoint Foundation should use this new Windows PowerShell scripting technology that is exposed in the SharePoint Management Shell." - Sharepoint Foundation 2010 SDK Documentation
    – nfw
    Commented Aug 16, 2011 at 21:38
  • Ah! Very cool, I found this link too: msdn.microsoft.com/en-us/library/ee539977.aspx
    – Kit Menke
    Commented Aug 16, 2011 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.