Delete application pool using Powershell command

Powershell is the best way to remove an application pool for SharePoint. Sometimes you may need to remove unused application pool accounts.

Below are the steps:

Open SharePoint 2013 management PowerShell, Make sure you are running as administrator mode.

Run the below command which will display all the application pools.

Get-SPServiceApplicationPool

Then run the below command to get the particular Application Pool.

Get-SPServiceApplicationPool -Identity <Name of the application pool>

Now we can to delete whatever the application pool we want by using the below command

Remove-SPServiceApplicationPool 'Name of the Application Pool'

Packaging your external dependencies to another solution

Sometimes we may need to use some third party tools that create external dependencies to our SharePoint projects. For example if you use common third party DLL in your SharePoint project in visual studio and build WSP, then  WSP package will include these SharePoint Guidance libraries also. However, this might create problems related to deployment. To explain the issue, let’s consider how SharePoint solution retraction/removal might affects other WSP package deployed in the same SharePoint environment.

Example: Two WSPs sharing a Common Dependency

Let’s consider you have two Visual studio SharePoint project: SharePoint Project 1 and SharePoint Project 2. Both projects are using (i.e., referencing) a third party dll (i.e., thirdparty.dll). Now if you generate WSP from two different Visual Studio projects, both WSP will include the thirdparty.dll in their WSP package.

 

                                    

Figure 1: A single thirdparty.dll is shared by two WSP solutions

As shown in the image above, a single third party dll is referenced by two Visual studio SharePoint projects. Now when you will build two different WSP solutions the same third party dll will be included to two different WSPs. If these two WSPs are deployed in a single SharePoint server/farm with GAC deployment, then both WSP will deploy the same ThirdParty.dll in the GAC. Everything will work fine till now.

Problem: retracting/removing one solution will fail other WSP to work

Now consider a scenario. After deploying the two WSPs in the production with GAC deployment, you have found a problem with Project 1 WSP. So you want to remove the Project 1 WSP while you will keep Project 2 WSP. So you will remove the Project 1 WSP. Removing the Project 1 WSP will remove all the assemblies from GAC/BIN related to the WSP. So removing the Project 1 WSP will remove thirdparty.dll also from GAC. As soon as you remove the Project 1 WSP from SharePoint server/farm, Project 2 WSP will fail to work as it will not find the referenced thirdparty.dll in GAC. So removing Project 1 WSP or project 2 WSP will remove the thirdparty.dll from GAC and other dependent WSPs which are using the same dll will fail to work.

Solution: Package your external dependency to new WSP

The solution to this problem is to exclude thirdparty.dll from both WSPs and create a new solution package for thirdparty.dll and deploy as prerequisite for both project. You can do it easily with SharePoint 2010 Package editor. As a result the thridparty.dll will not be included in any of the two WSPs.To package a new WSP for the thirdparty.dll you need to create another new Visual Studio SharePoint projects which will just include the thirdparty.dll (or any other prerequisites). The new architecture is shown below:

 

Figure 2: Shared thirdparty.dll is included in separate WSP

As shown in the figure 2, now the shared dll (thirdparty.dll) is excluded from Project 1 and Project 2 WSP. Whether you use WSPBuilder or SharePoint 2010 project template in Visual studio, you can exclude one more dlls from the WSP. Then create a new Visual Studio project which will include the thirdparty.dll and the output WSP package will include the shared/external dll. Now you will have three WSPs and the new WSP will be prerequisite WSP for other two WSPs or any other future projects which use this 3^rd Party dll.

Now with this model, you can remove Project 1 WSP or Project 2 WSP from your server without affecting each other. Even if you remove Project 1 WSP from the Farm/Server, the thirdparty.dll will not be removed from GAC as it’s not deployed as part of Project 1 WSP. Later if you want to redeploy the Project 1 WSP again then you don’t need to redeploy the prerequisite WSP as it’s already deployed in the server. If needed you can package your external dependency in more than one WSP packages.

Conclusion

If you are developing a SharePoint custom product that will be deployed in some client’s environment, then you should care about creating one or more dependency WSP packages. If your SharePoint solution is developed for a specific client or as an in-house product then you might not face the problem even if you don’t create a prerequisite WSP package. However if you are developing a SharePoint solution as a custom product and you don’t know the client yet, you should create prerequisite WSP package. And then when you will deploy your product in client server, you can deploy the perquisite or not depending on if the client has the prerequisite dlls install or not. If the client has the dlls/prerequisites installed in the farm, you don’t need to deploy the prerequisite WSP. This will make your SharePoint product more independent and will have less impact on other SharePoint solution deployed in the farm.

Powershell Tutorials

I found a good website for beginners to learn Powershell command and scripting

 

 Here is the website http://www.powershellpro.com/

 

Windows PowerShell for SharePoint 2013 reference 

 

 http://technet.microsoft.com/en-us/library/ee890108.aspx 

 

 hope you enjoy!!!!! 

What is the difference between Item.Update() and Item.System.update()?

Generally when we try to add/edit a SPListItem using SharePoint Object Model? 

Almost everybody have common answer to this (which is similar to what is provided below).

 

       SPListItem item = SPList.Item.Add();

       Item[“Column1”] = “Value for Column1”;

       Item[“Column2”] = “Value for Column2”;

       Item.update();

 

The last line in the code above "item.Update()" does the final task of updating all the assigned value for that specific item within the SPList.

But is this the only way to update an item? No, we can also update the same item using item.SystemUpdate();

Then what is the difference between the two?

With item.update(), we update the changes that are made to the list item. Is that all what it does? No, internally it also updates the “ModifiedBy” and “ModifiedOn” fields as per the current logged in user and current server time. Optionally it also updates the version of the item if the versioning option is turned on for that specific list.

So, at any point if we wish not to update these extra things I.e. the “ModifiedOn” , “ModifiedBy” and the “Item Version”, then the solution for it is to use item.SystemUpdate() instead of item.Update().This will help you in updating only those fields which are specified within your code blocks.

 Conclusion: 

 

 item. Update () will update the changes that are made to the list item as well as “ModifiedBy”, “ModifiedOn” and “ItemVersion” If Version is enabled.

item.SystemUpdate() will updates the changes that are made to the list item only, it will not update the “ModifiedBy”, “ModifiedOn” and “ItemVersion”.

How to create a Quick Step and Custom Action to start SharePoint 2013 workflow

Today, I will share with you a feature for creating a Ribbon button on a SharePoint server UI. This button will start a SharePoint 2013 workflow when pressed. As a matter of fact, you can achieve this by two different features which actually share many things in common – they are Quick Steps and Custom Actions. I will go with Quick Steps first which provides a more tailored user experience for this goal and then explain Custom Actions briefly.

If you are already used to Custom Actions or Quick Steps to start SharePoint 2010 workflow, then you can just try to create one to start a SharePoint 2013 workflow. Since the UX is, basically, the same, it should be easy for users who have done this before.

Quick Steps

I will explain in detail how you can create a Quick Step to start a SharePoint 2013 workflow.

Preparation

Creating a Quick Step requires some prerequisites.

First, you need to prepare a Ribbon icon file to show up in the Ribbon for the Quick Step you will define in the following steps. I decided to use the Site Assets document library and uploaded an image file there.

Second, you must have a list or document library you want to create the Quick Step in. In this example, I will use a Vacation Request list and create a quick step which starts a workflow to request an approval for the vacation.

Create a Quick Step

Now that you have the list to use, it is time to create a Quick Step. It is very easy. Just click the New Quick Step button under Customize List group in LIST Ribbon tab as highlighted below.

 

If you used a document library, you can find it under Customize Library group in the LIBRARY Ribbon tab as below.

 

 Clicking the button will lead you to this dialog where you just need to choose Allow.

SPD is then launched with the Vacation Request list shown with the following dialog popped up.

Take some time to explore the UIs on this dialog. You will find that you can create a new workflow based on SharePoint 2013 Workflow or SharePoint 2010 Workflow, or use some existing workflows. You will also notice that you can define the button label and button image. As we will create a new workflow based on SharePoint 2013 Workflow, choose the Start a new workflow option and then choose SharePoint 2013 Workflow as the Platform Type. Type in ‘Vacation Approval’ for the Button Label field. Lastly, click the Browse button to locate the icon image we uploaded in the Preparation section. Your dialog should look like below:

 

Once you click OK, a workflow designer for SharePoint 2013 Workflow will be presented as below. Feel free to complete the workflow logic. In this example, as mentioned before, we will create a Vacation Approval workflow.

Once you publish your workflow, you’ve finished creating a new Quick Step. If you go to the ITEMS Ribbon tab, you will find a new Ribbon group Quick Steps is created and a new Ribbon menu Vacation Approval is created as well.

And if you go to the list summary page for the Vacation Request list in SPD, you will find that a workflow named ‘Button – Vacation Approval’ is present and a Custom Action named ‘Vacation Approval’ is created. As a matter of fact, Quick Step is a specific kind of Custom Actions. So if you are familiar with the Custom Actions’ features, you can apply them to your Quick Steps as well.

 

Modify Quick Step (Advanced)

As Quick Step is a mixture of Custom Action (‘View Ribbon’ type Custom Actions) and a list workflow, you can apply some Custom Action features to modify the created Quick Step. If you click ‘Vacation Approval’ in the Custom Actions slab, the following dialog will be presented.

You can change the name of the button and even update the Quick Step to do a different job such as navigation to some forms or web pages, or starting a different workflow.

 

And if you scroll down a bit, you can find some advanced settings. If you use the Ribbon Location field and Sequence number field, you can change the location of the Ribbon button.

 

Let’s say, we want the button to show up in Workflows group rather than in Quick Steps group and want it to show up last in the group. Then you can easily achieve this by modifying the values to followings: 

This will make the button show on the targeted location as below.

If you want to know more about the values available in the Ribbon Location, please refer to following article or search for some other blog articles explaining Custom Actions.

http://msdn.microsoft.com/en-us/library/ee537543.aspx

For Rights mask, you can use the values from the below site separated by semicolons to allow only permitted user to see/use the Custom Action.

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spbasepermissions.aspx

Custom Actions

Let’s say now, that after you have a new Ribbon menu to start the Vacation Request workflow, you want a similar menu on the List Item Menu so that users can start a workflow by right-clicking over an item, like below:

To do this, you need to create a new Custom Action of type List Item Menu. You can find the Custom Action Ribbon button in the list summary page for the Vacation Request list in SPD. If you click it, you will be presented with the following options. In this example, please choose List Item Menu.

In the dialog that follows, please choose Initiate workflow option and select the ‘Button – Vacation Approval’ workflow which was created during the creation of Quick Step so that two UIs will start the same workflow. And Click OK.

That’s it. You created the menu. If you go to the Vacation Request list, choose one item, and see the list item menu, you can find it.