STEP 1 :Copy the PowerShell scriptlet below and paste it in a notepad, modify your Site Collection URL in the code marked in red below and save it with a .ps1 extension.
=======================================================================
Add-PsSnapin Microsoft.SharePoint.PowerShell
#Site Collection URL - Give your site collection url in quotation marks
$SiteUrl="http://localhost"
#Do not modify anything in the script from here onwards
function Get-ScriptDirectory
{
$Invocation = (Get-Variable MyInvocation -Scope 1).Value
Split-Path $Invocation.MyCommand.Path
}
#solutions to deploy
$SolutionName="PrintListItem.wsp"
$SolutionPath = Join-Path (Get-ScriptDirectory) $SolutionName
echo "Extracting information from $SolutionPath"
$SolutionPath= $SolutionPath
$FeatureName="PrintListItem_Feature1"
#Feature name
$FeatureID= $(Get-SPFeature -limit all | ? {($_.displayname -eq $FeatureName)}).Id
$SingleSiteCollection = Get-SPSite $SiteUrl
#Admin service
$AdminServiceName = "SPAdminV4"
$IsAdminServiceWasRunning = $true;
if ($(Get-Service $AdminServiceName).Status -eq "Stopped")
{
$IsAdminServiceWasRunning = $false;
Start-Service $AdminServiceName
Write-Host 'SERVICE WAS STOPPED, SO IT IS NOW STARTED'
}
Write-Host 'DEACTIVATING FEATURE ...'
Disable-SPFeature -Identity $FeatureName -Url $SiteUrl -Confirm:$false
Write-Host 'FEATURE HAS BEEN DEACTIVATED SUCCESSFULLY.'
#Uninstall
Write-Host 'UNINSTALLING SOLUTION ...'
$Solution = Get-SPSolution | ? {($_.Name -eq $SolutionName) -and ($_.Deployed -eq $true)}
if ($Solution -ne $null)
{
if($Solution.ContainsWebApplicationResource)
{
Uninstall-SPSolution $SolutionName -AllWebApplications -Confirm:$false
}
else
{
Uninstall-SPSolution $SolutionName -Confirm:$false
}
}
while ($Solution.JobExists)
{
Start-Sleep 2
}
Write-Host 'SOLUTION HAS BEEN UNINSTALLED SUCCESSFULLY.'
Write-Host 'REMOVING SOLUTION ...'
if ($(Get-SPSolution | ? {$_.Name -eq $SolutionName}).Deployed -eq $false)
{
Remove-SPSolution $SolutionName -Confirm:$false
Write-Host 'SOLUTION HAS BEEN REMOVED SUCCESSFULLY.'
}
Write-Host 'ADDING SOLUTION ...'
Add-SPSolution $SolutionPath | Out-Null
Write-Host 'SOLUTION HAS BEEN ADDED SUCCESSFULLY.'
Write-Host 'DEPLOYING SOLUTION ...'
$Solution = Get-SPSolution | ? {($_.Name -eq $SolutionName) -and ($_.Deployed -eq $false)}
#use '-force' paramater to install all commands in this if statement
if(($Solution -ne $null) -and ($Solution.ContainsWebApplicationResource))
{
Install-SPSolution $SolutionName –AllwebApplications -GACDeployment -Force -Confirm:$false
}
else
{
Install-SPSolution $SolutionName -GACDeployment -Force -Confirm:$false
}
while ($Solution.Deployed -eq $false)
{
Start-Sleep 2
}
Write-Host 'SOLUTION HAS BEEN DEPLOYED SUCCESSFULLY.'
Write-Host 'ACTIVATING FEATURE ...'
if ($FeatureName -ne $null)
{
Enable-SPFeature -Identity $FeatureName -Url $SiteUrl -Confirm:$false
}
#message
Write-Host 'FEATURE HAS BEEN ACTIVATED SUCCESSFULLY.'
if (-not $IsAdminServiceWasRunning)
{
Stop-Service $AdminServiceName
}
Remove-PsSnapin Microsoft.SharePoint.PowerShell
Echo Finish
Step 2 :
Now create a new notepad file and copy the code mentioned below, and then save the below mentioned code in a .bat file to automate the PowerShell deployment.
cd /d %~dp0
powershell -noexit -file ".PrintListItemDeploymentScript.ps1" "%CD%"
pause
Monday, June 20, 2011
How to 2 : Deploy SharePoint 2010 Solutions (WSP) files from Team Foundation Server 2010 Build
In part one we configured our build machine, executed a basic build and then added some msbuild switches to out put a WSP file. Now we are going to custom the build template to allow us to execute a custom powershell script and deploy our SharePoint solution package on our build server. The steps are very involved and it was difficult to put them to words without being too wordy. If you need some assistance drop a comment on the post and I will try to get back to you. Hope you enjoy!
Step 4: Wire Up a Simple PowerShell script
Fire up notepad and type into it: Write-Host "Hello World!"
Save the file as HelloWorld.ps1.
1.Open the command prompt
2.To test the script the execution policy needs to be changed by executing the command: powershell set-executionpolicy remotesigned
3.Now execute the command: powershell "& 'C:\[PathToFile]\HelloWorld.ps1'"
Note: remember to replace the [PathToFile] with the actual path of the file
Verify the output says Hello World!
Now drop the PowerShell script into the root of your project and check it into Source Control. Next we need to customize the Build process template to accept a parameter to execute our PowerShell script.
Open up the Build Template again and navigate to the Process Tab. In here click the Show details down arrow under the Build process template: heading.
Click the New... button
Copy the Default Template and name your new file name SharePointDeployment.xaml; Click OK.
Save your Build Definition and then switch over to the Source Control Explorer. Beneath the Project you are working on should be a folder named BuildProcessTemplates. Take a look inside this folder to find your new build process template. Double click your new template to open up the workflow designer.
Locate the Try Catch Action which says "Try Compile, Test, and Associate Changesets and Work Items." I like to click the up arrows in the top right corner so this entire action is collapsed. This will make it easier to find your place in the future and add items.
Now, before we can start to add new elements to our workflow we need a way to indicate which script to run when the build executes. To do this, we will use an Argument. I like to think of arguments like constructor overloads. They can optionally be set when the build is executed. This is just one aspect of arguments, for now add a new one by clicking Arguments in the bottom right and scrolling down to the bottom row. The type should be string and direction should be in.
Now, go to the toobox in the visual studio and from the Control Flow group add an if statement just below the Try block we collapsed previously.
Click into the Condition text box and begin typing… whoa! Intellisense, now we are getting back to familiar ground. If you have a VB.NET background you will feel at home because this workflow is implemented using VB.NET. Your condition is checking if a DeploymentScript value was given so in VB we write "DeploymentScript IsNot Nothing".
Drop a Sequence activity into the Then box of our If statement which will encapsulate our actions. For the Sequence activity name it Start Deployment.
Now drop a ConvertWorkspaceItem activity into the Sequence activity, followed by an InvokeProcess activity.
Before we can use our DeploymentScript value we are passing into our build we need to convert it to something the build process can find in the file system. We use the ConvertWorkspaceItem activity to change our path to something the build will recognize. But we will need a variable to store the value. Variables are exactly what you think they are, variables like in any other coding language. They are scoped to a location so click on the Start Deployment Sequence activity and click Variables in the bottom left. Go to the bottom and create a new one named "DeploymentScriptFilename" of type String. Notice the scope is pre-set for you to Start Deployment.
Now, right-click on the ConvertWorkspaceItem and choose properties, set the properties like you see in the screenshot below.
This activity takes our Argument "DeploymentScript" and converts it to a path the build process can find and then stores it in the "DeploymentScriptFilename" variable. Now we are ready to execute the script.
Now, it is time to setup the properties of the InvokeProcess activity exactly like the screenshot below.
I've pulled the full text for the Arguments property out for you here: String.Format(" ""& '{0}'"" ", DeploymentScriptFilename)
To see the output of our elegant script, drop a WriteBuildMessage activitie below the handle standard output and handle error output. For the message properties set each one to be the value of the textbox immediately above the activity.
Save your changes; the workflow should look like this:
We need to set the value of the Argument "DeploymenScript" we created. Save and check-in the Deplo
Now it is time to save and check-in our build template and PowerShell script. Open Source Control Explorer and check-in the NewBuildProcessTemplate.xaml. In solution explorer right click on your project and choose Add Existing Item. Browse to the PowerShell script and click Add. It should appear in your project root now. Check the file into source control.
Open up your build definition to the Process tab and notice the new Misc grouping with the value DeploymentScript. Before we enter a value here navigate to the Workspace tab and verify there is an entry for the project you are currently working on. It should look something like $/FOLDER/ProjectName.
Go back to the process tab and type the path to your PowerShell script file into the DeploymentScript field (eg. $/FOLDER/ProjectName/HelloWorld.ps1).
Save your build definition and queue up a new build. Before submitting it, click the Parameters tab and change the Logging Verbosity to Detailed. This will give us the output of our PowerShell script file.
When the build finishes, expand the log and locate the Hello World message. Tip: you can watch the build by double clicking on it in the Queue.
Step 5: Wire Up a SharePoint Deployment PowerShell script
Once this is working, it is time to expand on our PowerShell Script to deploy the SharePoint solution. In order to do this we will need to have a fairly powerful SharePoint deployment script and know 2 things:
1.The location of the solution files
2.The solution file name
Let's dissect the script first. Comments are preceded with the # character. The solution does quite a few things.
1.Sets up some parameters which can be passed into the script and stores them in variables
2.Adds the SharePoint PowerShell snap-in so we have SharePoint script context
3.Checks for the solution in the solution store
4.Checks if the solution is deployed and retracts it
5.Removes the solution
6.Adds the solution
7.Deploys the solution
1: #Store the name of the file we will use this later to add the solution 2: 3: param ( $solutionName, $solutionFileLocation ) 4: 5: $solutionPackageName = [System.String]::Format("{0}", $solutionName) 6: 7: $path = [System.String]::Format("{0}", $solutionFileLocation) 8: 9: Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue" 10: 11: write-host "Checking for solution:" $solutionPackageName 12: 13: $solution = Get-SPSolution | where-object {$_.Name -eq $solutionPackageName} 14: 15: if ($solution -ne $null) { 16: 17: write-host "Solution found" 18: 19: if ($solution.Deployed -eq $true) { 20: 21: write-host "Solution Installed, Uninstalling" 22: 23: Uninstall-SPSolution -Identity $solutionPackageName -Local -Confirm:$false 24: 25: } 26: 27: write-host "Solution Uninstalled" 28: 29: Remove-SPSolution -Identity $solutionPackageName -Confirm:$false 30: 31: write-host "Solution Removed" 32: 33: } 34: 35: write-host "Adding New Solution" 36: 37: Add-SPSolution -LiteralPath $path 38: 39: write-host "Installing Solution" 40: 41: Install-SPSolution -Identity $solutionPackageName -Local -GACDeployment 42: 43: write-host "Solution Installed"It is always a good idea to test scripts in the PowerShell ISE before adding them to your build. In my scenario I am deploying a Farm solution with GAC resources so my deployment script might be different from yours.
Now that we've dissected the script we are ready to add it to the project and deployment. Copy and paste the above script into a new PowerShell script file and add it to your project root as DeployFarmSolution.ps1 (remember to check it in).
Now to the two information challenges we face.
Solution File Names
I did not find a way to get these dynamically so I coded them into an Argument in the build process template. This gives me the flexibility of updating them from the GUI of the Build Definition if I decide to change the name. The name of the Argument I use is "SolutionName". It should look like the below screenshot.
To set the variable we need to save AND check-in the template. Then open up the build definition from Team Explorer by right-clicking on the Build and choosing Edit Build Definition. In the Process tab there should be another item in the Misc grouping named SolutionName. Put the name of the solution into this field (eg. Solution.name.wsp). While you are in here go ahead and change the DeployMent script Argument to be your new DeployFarmSolution PowerShell script.
Location of the Solution files
There is probably a better way to do this but I know solutions are copied into the Binaries directory right off of the root of the workspace. I can use the built in workspace variable to find its location and append the string literal "Binaries\SolutionName.wsp" to the end.
If you don't already, open up the Build Process Template (workflow designer) we created earlier and get the properties for the Execute Deployment Script action. Change the Arguments property value to be:
String.Format(" ""& '{0}' {1} '{2}\Binaries\{3}'"" ", DeploymentScriptFilename, SolutionName, BuildDirectory, SolutionName)
We are using the String.Format function to call our script {0}, pass in the solution name {1}, and finally concatenate the Build directory with the string literal "\Binaries\" and our solution name to get the full path to our solution file. It is that simple!
Go ahead and queue up another build with the Logging Verbosity set to detailed
I've used this process with a few modifications to execute multiple scripts which can be stored in a string[] Attribute. Here is a screenshot of the multiple deployment log.
Step 4: Wire Up a Simple PowerShell script
Fire up notepad and type into it: Write-Host "Hello World!"
Save the file as HelloWorld.ps1.
1.Open the command prompt
2.To test the script the execution policy needs to be changed by executing the command: powershell set-executionpolicy remotesigned
3.Now execute the command: powershell "& 'C:\[PathToFile]\HelloWorld.ps1'"
Note: remember to replace the [PathToFile] with the actual path of the file
Verify the output says Hello World!
Now drop the PowerShell script into the root of your project and check it into Source Control. Next we need to customize the Build process template to accept a parameter to execute our PowerShell script.
Open up the Build Template again and navigate to the Process Tab. In here click the Show details down arrow under the Build process template: heading.
Click the New... button
Copy the Default Template and name your new file name SharePointDeployment.xaml; Click OK.
Save your Build Definition and then switch over to the Source Control Explorer. Beneath the Project you are working on should be a folder named BuildProcessTemplates. Take a look inside this folder to find your new build process template. Double click your new template to open up the workflow designer.
Locate the Try Catch Action which says "Try Compile, Test, and Associate Changesets and Work Items." I like to click the up arrows in the top right corner so this entire action is collapsed. This will make it easier to find your place in the future and add items.
Now, before we can start to add new elements to our workflow we need a way to indicate which script to run when the build executes. To do this, we will use an Argument. I like to think of arguments like constructor overloads. They can optionally be set when the build is executed. This is just one aspect of arguments, for now add a new one by clicking Arguments in the bottom right and scrolling down to the bottom row. The type should be string and direction should be in.
Now, go to the toobox in the visual studio and from the Control Flow group add an if statement just below the Try block we collapsed previously.
Click into the Condition text box and begin typing… whoa! Intellisense, now we are getting back to familiar ground. If you have a VB.NET background you will feel at home because this workflow is implemented using VB.NET. Your condition is checking if a DeploymentScript value was given so in VB we write "DeploymentScript IsNot Nothing".
Drop a Sequence activity into the Then box of our If statement which will encapsulate our actions. For the Sequence activity name it Start Deployment.
Now drop a ConvertWorkspaceItem activity into the Sequence activity, followed by an InvokeProcess activity.
Before we can use our DeploymentScript value we are passing into our build we need to convert it to something the build process can find in the file system. We use the ConvertWorkspaceItem activity to change our path to something the build will recognize. But we will need a variable to store the value. Variables are exactly what you think they are, variables like in any other coding language. They are scoped to a location so click on the Start Deployment Sequence activity and click Variables in the bottom left. Go to the bottom and create a new one named "DeploymentScriptFilename" of type String. Notice the scope is pre-set for you to Start Deployment.
Now, right-click on the ConvertWorkspaceItem and choose properties, set the properties like you see in the screenshot below.
This activity takes our Argument "DeploymentScript" and converts it to a path the build process can find and then stores it in the "DeploymentScriptFilename" variable. Now we are ready to execute the script.
Now, it is time to setup the properties of the InvokeProcess activity exactly like the screenshot below.
I've pulled the full text for the Arguments property out for you here: String.Format(" ""& '{0}'"" ", DeploymentScriptFilename)
To see the output of our elegant script, drop a WriteBuildMessage activitie below the handle standard output and handle error output. For the message properties set each one to be the value of the textbox immediately above the activity.
Save your changes; the workflow should look like this:
We need to set the value of the Argument "DeploymenScript" we created. Save and check-in the Deplo
Now it is time to save and check-in our build template and PowerShell script. Open Source Control Explorer and check-in the NewBuildProcessTemplate.xaml. In solution explorer right click on your project and choose Add Existing Item. Browse to the PowerShell script and click Add. It should appear in your project root now. Check the file into source control.
Open up your build definition to the Process tab and notice the new Misc grouping with the value DeploymentScript. Before we enter a value here navigate to the Workspace tab and verify there is an entry for the project you are currently working on. It should look something like $/FOLDER/ProjectName.
Go back to the process tab and type the path to your PowerShell script file into the DeploymentScript field (eg. $/FOLDER/ProjectName/HelloWorld.ps1).
Save your build definition and queue up a new build. Before submitting it, click the Parameters tab and change the Logging Verbosity to Detailed. This will give us the output of our PowerShell script file.
When the build finishes, expand the log and locate the Hello World message. Tip: you can watch the build by double clicking on it in the Queue.
Step 5: Wire Up a SharePoint Deployment PowerShell script
Once this is working, it is time to expand on our PowerShell Script to deploy the SharePoint solution. In order to do this we will need to have a fairly powerful SharePoint deployment script and know 2 things:
1.The location of the solution files
2.The solution file name
Let's dissect the script first. Comments are preceded with the # character. The solution does quite a few things.
1.Sets up some parameters which can be passed into the script and stores them in variables
2.Adds the SharePoint PowerShell snap-in so we have SharePoint script context
3.Checks for the solution in the solution store
4.Checks if the solution is deployed and retracts it
5.Removes the solution
6.Adds the solution
7.Deploys the solution
1: #Store the name of the file we will use this later to add the solution 2: 3: param ( $solutionName, $solutionFileLocation ) 4: 5: $solutionPackageName = [System.String]::Format("{0}", $solutionName) 6: 7: $path = [System.String]::Format("{0}", $solutionFileLocation) 8: 9: Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue" 10: 11: write-host "Checking for solution:" $solutionPackageName 12: 13: $solution = Get-SPSolution | where-object {$_.Name -eq $solutionPackageName} 14: 15: if ($solution -ne $null) { 16: 17: write-host "Solution found" 18: 19: if ($solution.Deployed -eq $true) { 20: 21: write-host "Solution Installed, Uninstalling" 22: 23: Uninstall-SPSolution -Identity $solutionPackageName -Local -Confirm:$false 24: 25: } 26: 27: write-host "Solution Uninstalled" 28: 29: Remove-SPSolution -Identity $solutionPackageName -Confirm:$false 30: 31: write-host "Solution Removed" 32: 33: } 34: 35: write-host "Adding New Solution" 36: 37: Add-SPSolution -LiteralPath $path 38: 39: write-host "Installing Solution" 40: 41: Install-SPSolution -Identity $solutionPackageName -Local -GACDeployment 42: 43: write-host "Solution Installed"It is always a good idea to test scripts in the PowerShell ISE before adding them to your build. In my scenario I am deploying a Farm solution with GAC resources so my deployment script might be different from yours.
Now that we've dissected the script we are ready to add it to the project and deployment. Copy and paste the above script into a new PowerShell script file and add it to your project root as DeployFarmSolution.ps1 (remember to check it in).
Now to the two information challenges we face.
Solution File Names
I did not find a way to get these dynamically so I coded them into an Argument in the build process template. This gives me the flexibility of updating them from the GUI of the Build Definition if I decide to change the name. The name of the Argument I use is "SolutionName". It should look like the below screenshot.
To set the variable we need to save AND check-in the template. Then open up the build definition from Team Explorer by right-clicking on the Build and choosing Edit Build Definition. In the Process tab there should be another item in the Misc grouping named SolutionName. Put the name of the solution into this field (eg. Solution.name.wsp). While you are in here go ahead and change the DeployMent script Argument to be your new DeployFarmSolution PowerShell script.
Location of the Solution files
There is probably a better way to do this but I know solutions are copied into the Binaries directory right off of the root of the workspace. I can use the built in workspace variable to find its location and append the string literal "Binaries\SolutionName.wsp" to the end.
If you don't already, open up the Build Process Template (workflow designer) we created earlier and get the properties for the Execute Deployment Script action. Change the Arguments property value to be:
String.Format(" ""& '{0}' {1} '{2}\Binaries\{3}'"" ", DeploymentScriptFilename, SolutionName, BuildDirectory, SolutionName)
We are using the String.Format function to call our script {0}, pass in the solution name {1}, and finally concatenate the Build directory with the string literal "\Binaries\" and our solution name to get the full path to our solution file. It is that simple!
Go ahead and queue up another build with the Logging Verbosity set to detailed
I've used this process with a few modifications to execute multiple scripts which can be stored in a string[] Attribute. Here is a screenshot of the multiple deployment log.
How to 1 : Deploy SharePoint 2010 Solutions (WSP) files from Team Foundation Server 2010 Build
This article is a two part series which will explain how to Configure Team Build 2010 to Build a SharePoint Solution package and then deploy the solution package to a SharePoint server. In this scenario the build agent is running SharePoint Foundation 2010.
Step 1: Prepare the Build Machine
There are lots of good articles on MSDN which cover the basics of setting up a Build Environment. Once you are done preparing, the best pen test I have come across is to login to the build machine (as the build service account) and set it up exactly like you were going to develop on it. For instance, you would want to install:
•· SharePoint Foundation 2010 – or SharePoint Server 2010, whatever your shop is developing against
•· Visual Studio 2010 + Extensions for SharePoint Products
•· Any additional 3rd party libraries you use like NUnit
•· Grab the latest solutions and project files from Team Foundation’s Source Control
•· Configure the project to deploy to the server and try to deploy your solution
•· If everything builds, you are ready to proceed with deployment automation
Rather than re-create the content for creating a custom build I would recommend you take a look at this series of posts from Ewald Hofman. He put together some great information on customizing the Team Build process. I HEAVILY relied on his tutorials to get the build process going. You can either read his posts, specifically Part 1, Part 2, and Part 14. Or, I am going to attempt to summarize the necessary steps below. Now that the build machine is ready, let's move to the next setup.
Step 2: Wire Up a Basic Build
First we should make sure the build works. Navigate to Team Explorer and right-click on the Builds node for your project: choose New Build Definition…
Name it Build SharePoint, click on the Build Defaults section. Choose your Build Controller from the dropdown and put in the UNC path for where the built files will be placed. Leave the defaults for Triggers. If you don’t already have a workspace setup, then configure the locations for the projects you are going to build.
Click on the Process tab.
Verify the correct solution or project is selected in the Items to Build field. Go ahead and Save the Build and queue up a new build. It should output the assemblies for your project/solution into the drop folder.
Once the build finishes go ahead and double click the build to see the entire overview. Click the Open Drop Folder to view the output of the build. You might be asking, "Where is the Solution file?." That is our next task.
Step 3: Get a Solution Package
Right-click on your BuildSharePoint from Team Explorer and choose Edit Build Definition.
In the Process section, expand the Advanced grouping. Find the MSBuild Arguments field and enter /p:IsPackaging=true. Save the build definition and queue up another build. This time you should have a nice .wsp file in your drop folder.
Step 1: Prepare the Build Machine
There are lots of good articles on MSDN which cover the basics of setting up a Build Environment. Once you are done preparing, the best pen test I have come across is to login to the build machine (as the build service account) and set it up exactly like you were going to develop on it. For instance, you would want to install:
•· SharePoint Foundation 2010 – or SharePoint Server 2010, whatever your shop is developing against
•· Visual Studio 2010 + Extensions for SharePoint Products
•· Any additional 3rd party libraries you use like NUnit
•· Grab the latest solutions and project files from Team Foundation’s Source Control
•· Configure the project to deploy to the server and try to deploy your solution
•· If everything builds, you are ready to proceed with deployment automation
Rather than re-create the content for creating a custom build I would recommend you take a look at this series of posts from Ewald Hofman. He put together some great information on customizing the Team Build process. I HEAVILY relied on his tutorials to get the build process going. You can either read his posts, specifically Part 1, Part 2, and Part 14. Or, I am going to attempt to summarize the necessary steps below. Now that the build machine is ready, let's move to the next setup.
Step 2: Wire Up a Basic Build
First we should make sure the build works. Navigate to Team Explorer and right-click on the Builds node for your project: choose New Build Definition…
Name it Build SharePoint, click on the Build Defaults section. Choose your Build Controller from the dropdown and put in the UNC path for where the built files will be placed. Leave the defaults for Triggers. If you don’t already have a workspace setup, then configure the locations for the projects you are going to build.
Click on the Process tab.
Verify the correct solution or project is selected in the Items to Build field. Go ahead and Save the Build and queue up a new build. It should output the assemblies for your project/solution into the drop folder.
Once the build finishes go ahead and double click the build to see the entire overview. Click the Open Drop Folder to view the output of the build. You might be asking, "Where is the Solution file?." That is our next task.
Step 3: Get a Solution Package
Right-click on your BuildSharePoint from Team Explorer and choose Edit Build Definition.
In the Process section, expand the Advanced grouping. Find the MSBuild Arguments field and enter /p:IsPackaging=true. Save the build definition and queue up another build. This time you should have a nice .wsp file in your drop folder.
Subscribe to:
Posts (Atom)