SharePoint: Differences Between Global and Web Application Targeted Solution Deployment

SharePoint solutions are either deployed globally or targeted to a particular web application. The decision of which is made automatically by the SharePoint Solution framework depending on the contents of the solution manifest. Certain items in the solution manifest such as SafeControl entries result in modifications to a Web application’s web.config file. Only when a solution manifest does NOT contain any of these types of entries will the solution be globally deployed.

The deployment process behaves differently based on the type of deployment for the solution, and these differences have caused me quite a headache. Here are my findings that I think any SharePoint developer or administrator should be aware of when performing solution deployments.

Globally Deployed Solutions
When a solution is deployed globally, all SharePoint application pools, including Central Administration’s, are recycled automatically. This can be good and bad. This is good because any GAC installed DLL that has been upgraded needs to be reloaded. This can be bad though with regards to the availability of your entire SharePoint Farm.

In my particular case, I am working with a SharePoint administrator to deploy a globally deployed solution that is used by only a single web application. It is fine for this web application to be unavailable, as we have cleared it with our change control process and made announcements of the downtime, but we haven’t announced to users of the other SharePoint web applications in the Farm that their sites will be coming down along with it. So be forwarned.

Web Application Targeted Solutions I have become fond of web application targeted solutions because they offer me a workaround to the above availability problem. When a web application targeted solution is deployed or retracted, only the application pools of the targeted web applications are recycled.

Enterprise Farm Strategies When upgrading solutions, the upgradesolution stsadm command only gets you so far. I’ve found it is best to fully retract and remove the old solution and then add and deploy the new solution in order to be sure your upgraded features actually take.

Avoid the -allcontenturls switch – When deploying and retracting a web application targeted solution, deploy or retract it only to those web applications that will use it … thus preventing unnecessary recycling of application pools. I was being lazy in my retraction script and instead of specifying the particular web application url, I used the -allcontenturls switch to retract my solution, hoping SharePoint would be smart enough to recycle only the application pools of the web applications the solution was actually retracted from. Bad assumption. They all get recycled.

A Big Gotcha that Got Me If you are upgrading a web application targeted solution using the retract, remove, add, deploy strategy mentioned above and your web application scoped Features have associated Feature Receivers, then you must recycle the Central Administration application pool after removing the old solution and before adding the new solution if you intend to use the Central Admin Web application features page to activate your solution’s Features. In this case, it is the Central Administration application pool that executes your web application scoped Feature Receivers, and if not recycled, it will continue to use the loaded cached old versions of assemblies updated by your solution.

The same also goes for powershell. If within a powershell console you deactivate a Feature having a Feature receiver, the assembly containing the Feature receiver will be loaded and cached by the powershell App domain. After retracting, removing, adding, and redeploying the solution in the same powershell console, it will still be the previous version of the assembly that is cached. If you were to attempt to script the activation of your Feature, your updated Feature receiver’s code is never executed, rather the previous version from the cached assembly is used. To get around this dilemma, you can either increment your assembly version or start a new powershell console before deploying and activating your updated solution’s Features.

Customize sharepoint notification bar

Sharepoint 2010 site provides an area called notification bar. This bar appears when you open Edit control box. Using sharepoint client side API, you can use it. Just paste the below code in content editor web part.

<script type="text/javascript">

var notifyid;

function CreateNotification() {

notifyid = SP.UI.Notify.addNotification(" My HTML Notification ", true, "My Tooltip", "HelloWorld");

alert("Notification id: " + notifyid);

}

function RemoveNotification() {

SP.UI.Notify.removeNotification(notifyid);

}

</script><input onclick="CreateNotification()" type="button" value="Create Notification"/> <br/><input onclick="RemoveNotification()" type="button" value="Remove Notification"/>

Change display name of sharepoint user

You can use below powershell command to change sharepoint user display name.


Set-SPuser -identity "User name" -DisplayName "Display Name" -web Web url


Note: for AD user username would be like domain name\username. For FBA user it would be like i:0#.f|providername|username (You can get the exact username from My Settings page.

In case you get access denied while changing the display name, run powershell as administrator/Farm admin. You can get this option by pressing shift key then right click on Sharepoint powershell management console icon.

The password supplied with the username was not correct sharepoint

Recently I encountered an error while creating web application from central admin site

"The password supplied with the username was not correct. Verify that it was entered correctly and try again".

The reason is that administrative password may have been modified but SharePoint farm is still using the old administrative credential.

To fix this issue execute below stsadm command:


stsadm -o updatefarmcredentials -userlogin <domain\username> -password <newpassword>

The Best Way to Add Custom JavaScript and jQuery to SharePoint

During extensive SharePoint user interface customization you'll likely encounter a scenario where you need to make a web part or user control do something it was not intended to do or have a look that cannot be accomplished using the CSS hooks provided out-of-the-box. The solution is to create a custom master page and include a reference to a JavaScript file where you can modify the Document object. While straight JavaScript will do, I prefer to use the jQuery JavaScript library, which is far more robust, easier to use, and allows for plugins. Follow the steps below to add jQuery to your master page.

       
Go to jquery.com and download the latest jQuery library to your desktop. You want to get the compressed production version, not the development version.
Open SharePoint Designer (SPD) and connect to the root level of your site's site collection.
In SPD, open the "Style Library" folder.
Create a folder named "Scripts" inside of the Style Library.
Drag the jQuery library JavaScript file from your desktop into the Scripts folder.
In the Scripts folder, create a new JavaScript file and name it (e.g. "actions.js").
Open your master page file in SPD.
Within the <head> tag of the master page, add a script reference to the jQuery library just above the content place holder named "PlaceHolderAdditonalPageHead" (and above your custom CSS references, if applicable) as follows:
<script src="/Style%20Library/Scripts/{jquery library file}.js" type="text/javascript"></script>
Immediately after the jQuery library reference add a script reference to your custom scripts file as follows:
<script src="/Style%20Library/Scripts/actions.js" type="text/javascript"></script>
       
 

Your custom master page now includes jQuery and a reference to your custom scripts file where you can add jQuery scripts. SharePoint includes a number of JavaScript files throughout the site, so be careful that the scripts you add do not conflict with SharePoint's; the jQuery library itself does not conflict with SharePoint.

The Best Way to Add Custom CSS to SharePoint

To thoroughly customize your SharePoint site, you'll need to use a custom CSS. SharePoint offers a way to specify a single CSS file to use via the "Master page" settings for the site. However, using this approach still limits you to customizing only those IDs and classes that are included on the pages by SharePoint. Moreover, using this setting applies to both site and system pages, which may not be desirable. With these downsides in mind,Follow the steps below to include a custom CSS file in your master page.

       

1. Open SharePoint Designer (SPD) and connect to the root level of your site's site collection.
2. In SPD, open the "Style Library" folder.
3. Create a new CSS file and name it (e.g. "customstyles.css").
4. Open your master page file in SPD.
5. In the  tag add a link to your custom CSS just above the content place holder named "PlaceHolderAdditonalPageHead" as follows:
<link href="/Style%20Library/customstyles.css" rel="stylesheet" type="text/css" />

       
 

Your custom master page is now using your new CSS file in addition to all of the CSS files SharePoint uses out-of-the-box. The idea is that you are taking advantage of the "cascading" property of cascading style sheets by layering your custom styles on top of what SharePoint creates in order to alter the SharePoint look-and-feel as desired—like a skin.

How to Create a Custom SharePoint Master Page

The first step in customizing your SharePoint site is to create a custom master page. The following steps will help you do just that (please note there are differences indicated between SP 2007 and SP 2010).

       

1. Open SharePoint Designer (SPD) and connect to the root level of your site's site collection.
2. In SPD, open the "_catalogs" folder, then open the "masterpage" folder.
3. Identify the out-of-the-box (OOTB) most like your ultimate design.
    i)(SP 2007) If your SharePoint's site design is to be fixed-width and centered on the page, select BlueBand.master and copy it.
   ii)(SP 2007) If your SharePoint's site design is to be a liquid layout that fills the page regardless of the user's screen resolution, select default.master and copy it.
  iii)(SP 2010 beta) You want v4.master.
4. In SPD, right-click on the master page you want to duplicate and select "Copy," then paste it back into the same folder.
5. Rename the new file something project-specific.  For instance, if this master page is to be used on the sales portal, you might rename the new master page SalesPortal.master.
6. Publish and approve the new master page.
7. In your browser, navigate to your site's Site Settings page.  Under the "Look-and-Feel" column click "Master page."
8. Select your new master page as the site master page (the need to set the system master page will vary by project).  Save the settings change.
   

Your site is now using the new master page you created. From here you modify the master page to your liking, including adding custom CSS and custom JavaScript and jQuery.

Error occurred in deployment step 'Add Solution': Property 'SiteUrl' contains an invalid URL

While deploying custom BDC from visual studio, we may receive error "Error occurred in deployment step 'Add Solution': Property 'SiteUrl' contains an invalid URL".

Workaround:
1. Edit feature template file say Feature1.Template.xml
2. add following property under <properties> element
<Property Key='SiteUrl' Value='http://your_site_url'/>

Why SharePoint site's first load is very slow

The sharepoint site is very slow when we access it first time. After that the response time is good. The reason is compilation and caching which takes time after application pool is recycle. To handle this we need to warm up the server whenever recycle happens. Here is a good link that explains about server warm up: http://blogs.msdn.com/b/joelo/archive/2006/08/13/697044.aspx 


So the idea is to schedule a job that pings the server whenever reset occurs.

Web Part Page Maintenance – Get rid of that broken web part (SharePoint: Tricks for web part customization)

So, what happens when you are making a web part and despite your awesome coding prowess something goes wrong that prevents the page from rendering? It is kind of hard to change a setting on the web part when you can’t get to its editor window right? Well, the smart guys at Microsoft thought of this and included a “Web Part Page Maintenance” page for just such an occasion. At this page, you get a list of every web part that is added to the page and the ability to close, delete or reset them.

To get to this page, simply type “?contents=1″ at the end of the broken page URL.

Example: http://SharePoint/site.aspx is the page with the broken web part on it. Stick “?contents=1″ at the end of the URL to get http://SharePoint/site.aspx?contents=1

(Note: This will redirect the page to the layouts folder, opening spcontnt.aspx with the URL of the requesting page being sent in the new URL as a parameter. You could open this page directly, but its a lot easier to remember contents=1)

So, you will hopefully get a page like the one shown below. Now just delete the web part that is causing the problem and you are back in business.

Trick 1: Deleting a bad web part

If you have just added a web part to a page and you get the dreaded error page as a result, add ?Contents=1 to the page’s URL.

http://……./default.aspx?Contents=1

You can now delete the offending web part.



Trick 2: Getting to web parts when there is no “Edit Page” in Site Actions

Add &ToolPaneView=2 to then end of the URL. This example will let you see the web parts on a list’s NewForm page.

http://……./NewForm.aspx?……..&ToolPaneView=2