Tip of the Day: Intellisense for MasterPages

How ignorant can you sometimes feel? All the time while working with SharePoint 2010 MasterPages and PageLayouts in VisualStudio, for two years now, I have been cussing the lack of intellisense on those pages on a regural basis. I have even complained about this out loud and asked advice from others - never finding or getting any solution to this.

Then, only last Friday, I was helping out a guy who is relatively new to SharePoint branding and development etc. and had been trying out this and that in VisualStudio to help him get along - and avot! He had found the solution to the problem. Maybe it is old stuff to you already, but it was a life-saver for me!

In the Solution Explorer, right-click on the MasterPage/PageLayout file missing intellisense, select View Markup. That does it, pals!

VisualStudio11 and SharePoint Online

Since there already is a good article about the VisualStudio 11 for SharePoint Online solutions and since I myself haven't got around to actually even install the developer preview yet, let me point you to the said article on the Office365 site:

How to: Use Visual Studio 11 to publish solutions to SharePoint Online
http://community.office365.com/en-us/b/office_365_technical_blog/archive/2012/01/11/how-to-use-visual-studio-11-to-publish-solutions-to-sharepoint-online-grid-user-post.aspx

I found it enlightening and thus wanted to share it!

Quirks of the CKSDev Tools when Working with MasterPages

The CKSDev tools are a splendid toolset for SharePoint 2010 development. As I mostly create branding solutions, I use the Quick Deploy (Copy to SharePoint root) command for a quick and easy deploy without the tiresome iisresets and resulting reload delays etc. that come with the real deploy.

Most of the time this works perfectly, but in some cases I have noticed that it for some reason cannot update the MasterPage and PageLaouts files, but still works for the stylesheets and images. 

The other tool that comes in handy for me, mostly, is the Starter Master Page module. Mostly, I say, for this has a couple of issues. First, though, the reasons I still often prefer to use it for MasterPages rather than an empty module are

• the included starter.master (by Randy Drisgill)
• the better form of the Elements.xml, that is, it contains all the necessary properties for MasterPages ready made
• most of the time the cranky VisualStudio html intellisense for MasterPages works with a bigger probability than when adding MasterPages in an empty module

The quircks are related to this feature not being a proper SharePoint module, but was designed for one MasterPage only and thus

• you either need to create a new StarterMasterPage "module" with its own Elements.xml file for each new MasterPage
• or you need to do a bit of manual work

The manual work required:

1. the name you give the MasterPage when creating it as a new item, names both the "module" and the MasterPage file. E.g. if you name it MasterPages, then rename the MasterPage file and then you need to change the name of the file in the Elements.xml
2. if you add new MasterPage files to the "module", you need to add it to the Elements.xml file yourself (this is easily done by copy-pasting) and set the Deployment Type property for it as ElementFile

Design and Development in SharePoint Online vs. On-premises

And a little bit about planning the mobile sites as well. That was what I had a session about at the TechNet Helsinki 2011. You can find the presentation slides (.pdf) on the TechNet site (in Finnish) and the presentation video in Channel9 (also Finnish of course).

The important things to remember about SharePoint Online in sense of customizations, design, development, are that 1) there is no Farm Administrator role for the SP Online customer, only the SharePoint Online Administator, and 2) the things you can do with your SP Online site depend partly on the lisence you pay. So what it means, is that you are not able to install anything on the SharePoint server, nor change any server settings in SharePoint or IIS, and also that the license really does matter. Whereas of course, if you host your own SharePoint server, there are no such limitations. (See more about SharePoint Online licensing)

Customizations compared, in the browser your possibilities are equal with these two - and in a sense here lies the true power for SharePoint Online development: utilizing the power of the client! You can use e.g. JavaScript, including jQuery etc. in the browser, in Content Editor Web Part for example, but the real power comes with VisualStudio and the client object model.

With SharePoint Designer you can do a lot in both (including harm), but there already are some limitations to this in SP Online. The SP Online adminitrator has the most permissions to SPD, as well as the permission to grant or restrict the use of SPD (fortunately, by default, the admin is the only one who is allowed to use SPD). 

With VisualStudio (i.e. development tools and possibilities), you run into the most limitations. But don't let them fool you. There's a lot that can be done developmentwise with SharePoint Online too.

1. The Sandbox model. It is a subset of the complete SharePoint develpment toolset. I doesn't allow you to deploy anything in the GAC, and it doesn't allow you to access any services. It can use a basic set of objects within the Site Collection. You can make your own web parts, access lists, handle events etc.
   Update (Dec. 8, 2011): As of this autumn, Business Connectivity Services (BCS) are available for developers in SharePoint Online (see more about SPO update and BCS & SPO)
2. The client object model. This, since it is run on the client side, in many cases can pretty much cover the shortcomings of the Sandbox model when it comes to e.g. accessing external data and using web services. It includes .NET Framework Managed, JavaScript and Silverlight. 

So as a conclusion, combining both development models, you can have your SharePoint Online site customized pretty effectively. As for the SharePoint Designer, I generally don't recommend it as a tool for the things that can better be done in a controlled and managed way with development tools in SP Online anymore than on-premises. But it can be used by advanced power users for customizing list views, creating workflows, creating list templates in a more lightweight manner, possibly on top or in addition to what has been done by development tools, globally. And the latest addition to this is that from autumn 2011 on, Business Connectivity Services are available in SharePoint Online, and you can set them up in SPD unlike before.

For more information on both and the whole picture, see the TechNet Library article on SharePoint Online development.

So how to fit the mobile view into all this? What should you know and take into consideration when planning the mobile usage of your SharePoint site, whether it be Online or on-premises? There is a very good blog post on this subject by Mike Hacker, I won't go into as much detail here. But a couple thought on that subject here too.

First of all, you might want to evaluate the most probable mobile usage for your site. If it is all about team sites and document management, it is probably enough to enable mobile views in your SharePoint environment (enabled by default in SP Online) and make sure that all of the newly created list get mobile view activated as well (the default ones have this feature enabled by default but new ones don't).

If we are talking about a publishing site, or sites, the question of the mobile view, or mobile site, gets whole new angles. Should we force the complete web site to mobile users too (needs some adjustments on the server, so this is not supported in SP Online)? Or should we then create another css stylesheet for mobile users (which is probably the easiest way to make changes for the mobile users in terms of detecting the device, but then again doesn't give the mobile user a choice)? Or make a completely different set of masterpages? And what about our web parts? Are they mobile compatible?

Make it this way or that, my personal opinion is: give the users a choice. Don't force a mobile view on mobile users, thinking that you're doing them a favor by making browsing easier. Not all mobile users like mobile views. And even more so, there's a whole lot of mobile devices with approx 10" displays which is quite enough for a full scale web experience.  

With SharePoint Online - on on-premises with the default mobile view settings enabled - it depends a bit on the device which way it will show the site by deafult. As the user with the device, you can switch them either way by changing the ?Mobile= -parameter in the URL string. The zero is the full view, one is the mobile view. So e.g. http://url/?Mobile=1 would be the forces mobile version for the site, whereas http://url/?Mobile=0 would be the forced full version of the site.

Hmph. SharePoint Designer failed me (again) and the photographer was there to document the moment. 

Automatize MasterPages in SiteDefinitions

When building a branded SharePoint2010 solution, the customization of Master Pages is the issue. And as I've stated in a former blog post, one Master Page is seldom enough. In the least, the Search Center needs one of it's own. And maybe we need a customized Team Site? Or two? And one for BI reports? Etc.

Basically, when creating a branding solution - or any solution - you will want to use a feature. And preferably package it all into a wsp package, neat to deploy. It used to be complicated with a lot of handi-work when creating these in VisualStudio, but not anymore. VisualStudio2010 contains SharePoint 2010 project templates natively, adds many of the needed xml files, fills in features by demand, creates the wsp package... and makes SharePoint development extremely flexible by deploying the solution to your development environment with one click, activating your features on the go!

Thus, though, it is easy for a developer to forget a couple essential things for when the time comes to deploy the solution to the test environment of the customer.

1) It's rather convenient to set your features to activate whenever a site of the type is created. This is done by adding a sigle (or two, with the commentation of the code) line in the onet.xml file of the site definition:

inside the web or site (depending on the scope of your feature) features collection of your site definition configuration(s).

2) Create a feature receiver. The automatic activation of a feature is next to nothing it nothing happens. A feature receiver defines what happens when the feature is activated, eg. the MasterPages to use and where. In the simplest scenario, it defines one master page for the whole web. But it's not a big deal to make it acknowledge the different site definitions you've created. This way you can package them all in one feature instead of a minion.

In my example here, there is custom team site and a custom search center site defined with their own master pages plus the overall portal master page used everywhere else (for accuracy, I used the custom WebTemplateId's of my SiteDefinitions instead of WebTemplate names - possible also, but didn't work for me)

The code exerpt above is only the first half, you need to define likewise what to do when the feature gets deactivated.

[Edit. Jan 18th, 2012
For MasterPage automatization withour custom SiteTemplates, see Setting MasterPages to Sites Automatically.]

Uninstalling VisualStudio2010 beta1

Uninstalling VisualStudio 2010 beta1 is, of course, a necessary operation prior to installing Visual Studio 2010 beta2. If you have been running VS2010b1 on Win7 or WinSrv08(R2), uninstalling isn't a simple 3-click-operation. Well, it is, essentially, but while unistalling the TFS Object model, the uninstaller asks for this file TFSObjectModel-amdXX_ENU.exe which is nowhere to be found, really. The workaround is to either unsinstall this component manually, but this file can also be found and downloaded from the go.microsoft-site:

x86: http://go.microsoft.com/fwlink/?LinkId=148199&clcid=0x409
x64: http://go.microsoft.com/fwlink/?LinkId=148200&clcid=0x409