How To Recycle IIS Application Pool Manually via DOS Command ?

As a .NET programmer and an avid user of the Global Assembly Cache when dealing with SharePoint one of the things that I have to use most to test my solutions is to recycle the application pool, so that I can put my newly created DLLs and test them.

I use a lot WSPBuilder for this task, but I always wondered : How can I recycle the application pool via command prompt ?

In case you ever wonder the same and still don’t know how to do it, here’s how:

the cscript command is pretty neat. And mostly the Microsoft Platform applications have a .vbs file assigned to them, so give it a try and try some other cool stuff in other apps.

See you later,

By Edge Pereira

Sharepoint Tips and How Tos

• How to Display Friendly SharePoint error messages ?
• How to Perform SharePoint Deployment by Features?
• How to Recycle IIS Application Pools manually vis DOS Command?

How to do Site Branding in SharePoint?

One of the main selling points for implementing SharePoint are its content management capabilities.

This week I went to a client demonstration of our new site and I noticed that a MOSS enabled website is really appealing to them (end users) but not so much because the underline features or that cool RSS integration you demonstrated but mainly because the ability to manage and roll out content on the web itself.

 

 

As a topic of later discussion amongst us something was obvious: people do not really understand what’s the concept of Site Branding, and for that I believe it is paramount for us consultants to deliver this message for them very clear so they can have a better grasp of their brand new SharePoint site they will be maintaining themselves when we finish the project.

So what is site branding from SharePoint's point of view?

It is called Web Content Management, WCM, and it’s function is to make a clear cut between what’s site branding and site content.

Site Branding is created by a marketing team, normally a group of designers and sometimes for developers. It responds to questions such as site navigation, look and feel, style etc. In other words, it is about HTML, CSS classes, icons, master pages, page layouts etc.

Site Content is created by site managers, contributors, editors etc. They have the task to choose the layout, choose the icons and images to be displayed in the site sections, they add videos to the pages, they populate the text with links to other relevant sites and contents etc.

So, now that we have this picture well defined we can infer that developing a SharePoint website is also to determine the underline appearance of the site itself.

Normally the task to develop the branding is handled over to a 3rd party company. Someone specialised in websites, and better matching colours and with experience to create a visual identity. As a matter of fact, Microsoft has made available to the general public all the CSS classes used by a typical Windows SharePoint Services application (WSS), they can be seen here

Honestly that’s a concept one has to capture and, like most things in life, it takes practice.

If you are a power user, a site editor, a tester, business analyst, project manager or any other role involved in a SharePoint site that doesn’t need to know how the things works under the hood (workflows, code, architectural designs, service contracts etc) and you are interested in learn more about site customization using SharePoint I suggest to read this 3 part series from MSDN, specifically targeting the Web Content Management features of SharePoint.

Part 1: Understanding Web Content Management and Features

Part 2: Extending WCM

Part 3: Creating and Configuring WCM-Enabled Sites

You see, handling the client’s expectations with the project its not only meeting the deadlines and delivering the project but also empowering them on the tools they can within SharePoint itself so next time they come talk to you asking for a new variation they will be more aware of the things he can or can’t do.

If you need any more information about how to do branding in SharePoint feel free to email of leave a comment.

See you later

By Edge Pereira

How to Design a SharePoint Application to the Cloud

There is a very common misconception about the uses for SharePoint and I would like to talk about one of them: Using SharePoint as a file repository. Of course SharePoint has great features to enable file sharing and versioning control across the enterprise, but is it so much more than this. So I decided to elaborate a challenge: How would you go about to setup a SharePoint/MOSS solution as an application architecture?

And let’s make the challenge a bit more interesting, shall we. WPF Composite Application Guidance (PRISM), Windows Azure, Sculpture, MVC, ASP.NET. What all these new technologies have in common? They all have deployment options for the Cloud.  So, our challenge will be not only design an application using SharePoint but also design a SharePoint application using the Cloud as subsystem.

 

How can we design an application for the Cloud?

There are many approaches, but I would say the most likely models are:

• Line of Business running as services  that can keep their data in the Cloud and have web pages as UI.
• Web applications hosted entirely in the Cloud.
• Various systems designed as message-based applications using the Cloud as media and components like HTTP, REST and SOAP as protocols.

One of my passions is photography so let’s design an application where people can contribute with pictures to the cloud via SharePoint. In our case study, we have to consider the following scenario:

• many pictures can be uploaded by a single user.
• many users can submit their pictures at the same time from several locations across the world.
• Every picture will have a little story about it. Whoever upload the picture must tell the story associated with it.
• the pictures and the stories can have multiple formats
• many devices can be used to upload the pictures (desktop, notebook, mobiles)

In the other side, we will have customers (agencies) consuming these contents via exposed services:

• one agency can query as many times they want for shared and approved content.
• many agencies can submit their queries at the same time
• many devices can be used to query the results (desktop, notebook, mobiles)

 

So let’s take a look at our suggested model:

 

Our main enterprise application will be hosted in a SharePoint/MOSS application where the business owners can control it from there, use the BI tolls and apply KPI tools if they wish to. Also via developed custom web parts hosted in our SharePoint site they will have access and create reports targeting our File System impersonated by Windows Azure in the Cloud.

Web services will be developed and exposed using our own APIs to allow communication with our file system in the Cloud. At this point, we want to be agnostic and pragmatic. Just because we are using SharePoint and Microsoft Cloud, it does not mean we have to be attached to Microsoft tools. Since Web services and the Cloud itself work under well-known protocols any client can then interact with them. We can have desktops running Macs searching for pictures and text, we can have mobiles using embedded Java to upload pictures to our application and we can have other agencies using our own exposed API and integrating our system into theirs and querying the results via SQL Reporting Services via XML.

What should be our focus when designing such application ?

It does not matter the chosen technology provider. IMHO, the most important factors to cover here are: Scalability and Application Services

Why Scalability?
Let’s take a step back and think about how is this application going to be in 2 years time.  Scalability means provide a good tolerance for expansion without compromising the quality of service in our case. Overtime we expect a growing user base and file storage usage by pictures, descriptions, user profiles, texts or whatever it is; but not only this, we should expect a growing number of requests per day by users all over the place. If we wanted, we could even expose services as plug-in for third-party consumers to provide our services in their own applications. Scalability must provide enough room for this to grow in the future

That’s when comes a brand new concept: Infrastructure as a service. High scalability and high availability are the main features of such environment. Who today can offer such a worldwide service? the Cloud. and with another good thing to take: The Cloud is agnostic.

So, here we have our chosen infrastructure media.

We are going now to develop .NET custom code implementing the Windows Azure APIs and make them as components in our SharePoint application, which can be distributed in our SharePoint pages as web parts hosted on Web part Zones.

 

Why Application Services?

Here the biggest concern is relating to the many devices allowed by the system per user. It is impossible nowadays to have an application dictating what the user/client must use or not, and if you ever do this it will be in no time your competitor's biggest strength.

At the same time, many RIA – Rich Internet Applications are available and will want to be using such a service base, like iPod Touch and other mobile devices. To implement these we need to think about Composition Interfaces.

Composition Interfaces are many pieces of various design patterns combined to allow writing flexible UIs according to the user. We can even use ASP.NET adaptable rendering controls to minimize our design time. So by using a ASP.NET text box within a custom web part in our SharePoint site page to upload pictures, it will be rendered with no problems when this page is accessed via Firefox browser or a Nokia cell phone as well.

Flexible UIs allows us to develop both simultaneously and with personalization according to the user’s needs.

This given scenario is also a great model for sub locating tasks to other groups via design by contract.

To design an application by contract is to specify, document and make available all the expected inputs and returned outputs from our system, in our case our SharePoint site, so others can develop targeting our platform in a very interesting way because now you can give them a task, tell them the APIs to use (for uploading photos or querying texts) and they then develop the module based on the contract. It also introduces a very important aspect of it which is the atomicity. If their part somehow breaks down or has a bug, it won’t affect the main system because the calls specified by contract are already sanitizing the inputs and outputs.

Another added benefit is that such architecture is modular enough from the solution interface. You can clearly give a demonstration to the project’s stakeholders explaining the contract’s model and the interfaces without touching the internal processes and they will most likely to understand. It is like having a helicopter view of the solution.

So, there you go. Now when someone tells you that they use SharePoint to save files and share resources in their Intranet you can tell: “SharePoint can do so much more than this!”

By Edge Pereira

How to Perform Sharepoint Deployment by Features

Today I would like to talk about Features in Sharepoint. Features is a model provided by Sharepoint what reduces the complexity of deploying site customizations and at the same time provides to the team a strong and consistent way to perform many deployments as necessary following a well-known and documented process.

By wrapping up content deployment in Features, you are also likely to implement versioning control since each package can be labeled by version.

How to Implement a Sharepoint Feature?

Let’s assume you are using Microsoft Visual Studio.NET. To implement a Feature, you should mimic the current Sharepoint file Path in your solution. Go ahead and create a path called <yoursolution>\12\TEMPLATE\FEATURES

There you will place all the necessary content for the Feature. We will use WSPBuilder as a preferred tool to ease our task as well. If you don’t have WSPBuilder you can get it from our tools page.

You will see a file called Feature.XML, this file will tell you the location of the assemblies, files, references, resources etc included in your Feature deployment. The xml file also will allow you specify a friendly name for your feature. like: MySiteBrandingContenttell , for example.

Now let’s say you want to add a whole bunch of images to your site. Just go to the Style Library/Images folder and add them there. Remember, our folder structure is mirroring the actual Sharepoint folder structure.

Now let’s take a look at the elements.xml file.

Note the section called ImageModule pointing to the url style library/Images.

This section will ultimately tell Sharepoint (via WSPBuilder) all the files that must be present inside your Feature package. So you should go and edit this file, adding all the images you want to distribute with your Feature.

That’s an OK process, but often we have dozens if not hundreds of images to deploy. So here’s a nice trick to quickly populate the section.

First you open via windows explorer the location where all the images are located.

Get the folder path, which depending of your solution can be quite big.

Make a list of all the files you want to add to the xml section into a text file. And here comes again another trick, from the good-old-days of DOS. The command below will list all the files, just the names and save it into a file in your computer.

Open this file, select all the files and copy to an Excel spreadsheet (or any other similar toll like the OpenOffice Calc)

Now, another trick. Use this formula within your spreadsheet. This when applied to the content will format the whole document perfectly for use inside your XML feature file.

Now you just have to copy the content generated and copy/paste into your section.

Right-click your solution and rebuild the project.


Voila! You’re ready to deploy your feature.

Now comes the part when WSPBuilder is really handy. If you have it installed in your computer you will notice the context-sensitive menu integrated within your Visual Studio environment.  Right-click again your solution and choose Build WSP

If everything went as expected, right-click again and then choose Deploy. This will effectively deploy the solution to your environment.

How Does WSPBuilder knows where my Sharepoint Site is? It will pick it up from the project properties/URL path.

In any case, the package will be created under your solution/bin/deploy folder. A batch file called deploy with stsadmn is also going to be created if you decide to deploy it manually without having to remember all the stsadmin –o directives for it, or if you want to take the Feature package to another server.

Now go you your website and see all the changes applied. Your feature should have been deployed successfully!

 

Why I can not see my deployed features?

That’s because you need to disable the feature and then re-enabled it again to see it in action. By doing this you are forcing the files to be copied over to the actual Sharepoint site.

You do this. Go to modify all your site settings:



Go to the site features, where you can see all the listed features in your site.


Then manually deactivate and activate the feature.


There you go! Your feature is got to be there now.

By Edge Pereira