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.

SharePoint 2010 Feature Changes Document Titles in Search Results

SharePoint 2010 has a interesting feature which you may not know about. It's called Optimistic Title. It's part of the Office Search engine within SharePoint. What it does is determine a new, hopefully more relevant title for your documents to be displayed in your search results based on document properties or the actual contents of the document (i.e. Text within the file). As you might expect this is closely tied to the Office document formats such as Word, PowerPoint, Excel, OneNote, and Visio. Your end users may report that the titles that they see for search results differ greatly from the file name or the actual title of the document. This is particularly evident with PowerPoint files where the name of the first slide is often used. The behavior is not entirely predictable. Different results can be expected from Office 2007 and Office 2010 created files and even those created in earlier versions of Microsoft Office.

If you want to change this functionality you need to actually go and edit the registry on your Search role server(s) within your SharePoint farm, restart the osearch14 service and then do a full crawl. The key you want to modify is the EnableOptimisticTitleOverride. The default setting is 1. Change it to 0 to disable the feature.

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"/>

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.

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.

SharePoint 2010: Changes to HTML with Service Pack 1

SharePoint 2010: Changes to HTML with Service Pack 1

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