APPENDIX B

Questions from the Audience
Real Questions from Real People

During the time it has taken to write this book, I have received countless emails asking questions and asking whether the sender's particular issue will be addressed. And, as a good author, I always answer:

Yes, of course! Just buy the book, and it will be on page 93. Contents subject to change.

Now, to make sure at least some of those people do not sue me for all my earthly possessions, I have included this chapter to answer a few of those questions. What you are about to read are real questions from real people....

Good evening, ladies and gentlemen. My name is Bj⊘rn Furuknap, and I will be here to answer all your questions regarding SharePoint. To make sure we proceed in an orderly fashion, I will take one question at a time. Please raise your hand and wait for me to address you before you speak.

Before we begin, I would like to direct your attention toward the screen behind me. Alas, the moving bits of my presentation came down with the flu, so all we have are static illustrations, but you are free to imagine a properly running demonstration of all the topics discussed here.

Question 1

SharePoint branding is difficult because of the excessive HTML that is generated by SharePoint. What solutions do you recommend to solve this problem?

–Kanwal Khipple, SharePoint consultant and founder of SharePointBuzz.com

Throughout this book, close to every single element is examined and explained, and with the noted exception of grouping in views, I show how everything is generated and how you can exchange the horrible default HTML. Grouping in views is a sad chapter of SharePoint that forces you to rely on HTML tables for output. What's even worse is that there is no way to change this.

My recommendation depends a bit on how much time you want to put into branding, the complexity of your solution, and which features you actually need to brand. If you have limitless time, I recommend re-creating the entire interface. If you have a complex site and utilize nearly every available feature and in addition run on a limited budget, I recommend swapping out the master page and just doing the best you can with CSS.

Question 2

Working with SharePoint, I have found myself increasingly annoyed at the little bugs or errors that seem to want to prevent me from doing my job. Am I missing something, or is SharePoint development so annoying?

–Debbie, Illinois

I think I know what you mean. To me, every project is a learning experience. Even after seven years developing for SharePoint, I still find new areas to discover. The complexity is massive, and this is a source of problems.

I have gotten used to most of the little issues, such as the documentation errors, the bugs in wss.xsd and IntelliSense, the problems with custom field types, and the strange unknown errors that seem to pop up whenever I want to do something trivial. However, the “getting used to” has taken quite some time, and I have been extremely frustrated at times, especially when I learned to make custom views and field types for the first time.

My advice is to look at your learning experience as a journey, and that is also why I have structured this book as a journey. Getting your project done may very well be your short-term goal, but for each project you complete, you learn something new that makes the next project more interesting. If you focus on learning SharePoint as your goal rather than just keeping your boss happy to have a job, I think you will find the entire SharePoint experience a lot more satisfying.

Question 3

How do I get started with SharePoint development? Do I need to buy a server, or can I work on my home computer? I have worked with ASP, PHP, HTML, and CSS, but I have never developed anything for SharePoint.

–Anonymous

Learning to develop for SharePoint is no different from learning any other platform development. You mention experience from different languages, and having wide experience from different languages is always a good idea. Remember that language is just a tool; learning a programming language does not make you a developer any more than learning English or German makes you an author.

How you should learn to develop for SharePoint depends a lot on your learning style. Do you prefer to read? If so, get a good book. For starting out learning SharePoint, I am afraid this book is not your best choice, but you have a wide range of other good choices. I have compiled a list of books I recommend on http://www.understandingsharepoint.com/url?/20010.

If you prefer other methods of learning, you will find a wide variety of online and offline resources using Google. Microsoft has an excellent SharePoint developer training site at http://www.mssharepointdeveloper.com/. You can also check out the training resources on the Understanding SharePoint web site at http://www.understandingsharepoint.com/training.

Regardless of how you want to learn, I do have one advice: be patient. Learning a new technology takes time, and you will get frustrated at times. Stick with it; the rewards of the journey are well worth the effort.

Question 4

Having seen the table of contents before the book was released, I was surprised that there doesn't seem to be a web part chapter. Why is that?

–Claire, United Kingdom

Good question! Web part development is a very popular method for developing functionality for both SharePoint and other web applications. The web part framework in ASP.NET is rich and provides a lot of opportunities for creating very nice interfaces and experiences for users.

However, web parts are essentially part of ASP.NET, just like master pages. I have tried to focus on SharePoint-specific topics. Getting up to speed with web parts in SharePoint is not too different from regular ASP.NET. With the knowledge you have learned in this book, you will be far along the path of creating SharePoint web parts just by applying regular ASP.NET web part skills, without any special training.

A related question is “When should I develop a web part, and when should I rely on standard SharePoint user experience development?” I'm not sure that there is a straight answer that will apply to all scenarios. Think of web parts as little web applications that may or may not interact with SharePoint. Web parts are separate entities that encompass some kind of functionality whether it is interacting with the user or simply displaying data in a certain way. If you require that separation, use a web part.

Question 5

While developing, I keep getting error messages, but I cannot find where WSS logs the errors. The logs in 12-hive/Logs are confusing. Can you help?

–Anonymous

SharePoint allows for great flexibility in logging. The default setup might not give you exactly what you need, but you can easily adjust the logging level. To do so, go to Central Administration, and check out the Diagnostic Logging link where you can adjust logging and error reporting with fine granularity. From then on, your new settings will apply to the log files stored in [12]LOGS.

Reading these logs, however, can be a pain since the file is just a plain-text file with very long lines. The SharePoint 2007 Features package on CodePlex will help you, though, because it contains the Log Viewer feature. That feature will add a log-viewing page to Central Administration that greatly enhances your log-viewing experience. You can download the feature from the CodePlex site at http://www.codeplex.com/features on the Releases tab.

I have also written a blog post on debugging SharePoint, available at http://www.understandingsharepoint.com/url/10008. That article details how to set up and work with logging as well as how to set up SharePoint to display improved error messages.

Question 6

I have developed a custom field type but cannot store any custom properties. After googling the problem, I came across a workaround that I couldn't understand. Using GetCustomProperty doesn't work.

–Anonymous

I'm not sure exactly what your question is from this. However, as it relates to custom properties in custom field types, I can understand if you're bewildered. This is a “good news, bad news” situation–or, rather, it's a “good news, bad news, worse news, horrible news, and news of impending doom” situation.

The bad news is that custom properties in field types work in mysterious ways. Some people call it a bug, but it is not really a bug but rather an inherent problem with the way that adding columns work. Your custom field type code actually serves two distinct purposes when creating new columns. One is to provide the interface where you add your custom field type properties, and the other is to actually store the column after it is created.

The worse news starts when you realize that there are actually two object instances that serve these two purposes, one that holds the custom properties and another that creates the column. Of course, these two objects do not know about each other and cannot communicate directly, so there is no simple way to get the new custom properties from the object that holds the user input into the object that creates the column.

The horrible news is that the problem isn't really a bug but rather just a design issue that follows as a result of how adding new columns is implemented. And since this isn't a bug, the problem will likely remain throughout the life span of the current SharePoint. Brace yourself, and be prepared to live with it and work around it; or, don't implement custom properties in your field types.

Oh, but your day has just started in the bad news category. The impending doom news is that there isn't any good news after all. Nope, no last-minute stay of execution, no white knight or knightess riding in to save the day, no brave sacrifice in the last scene.

If you want to know more about custom properties in field types, the third issue of Understanding SharePoint Journal explains how this problem works and also suggests one workaround that may at least bring some sunlight to an otherwise horrible day. You can read more about that issue and download the code to see how that workaround works at http://www.understandingsharepoint.com/journal.

WSPBuilder implements another widely used workaround in the WSPBuilder Field Type project item. I advise you to add such a custom field type and then study the code that WSPBuilder generates for you.

Question 7

How can I circumvent developing on a server? SharePoint will not install on XP, and I don't want to run Windows Server 2003 on my laptop.

–Multiple askers

This question is asked very frequently and is likely one of the first questions that a SharePoint developer will ask.

I talked about this in Chapter 1 and explained why I don't recommend developing anywhere else but on a server. Not just that, but developing on a server gives you many benefits that you would not get if developing on a workstation. For example, Visual Studio integration will very easily attach to the process running SharePoint, so you can get step-by-step debugging while developing .NET code. You could set this up to work on a remote machine, but it is a hassle.

Second, the object model exposed through the SharePoint DLLs, one of the most powerful development tools you have, is available only locally on the server. You could circumvent this by referencing the SharePoint DLLs, but you would not be able to test your features without deploying your code to the server in any case, and you would still have to tackle the debugging issues.

My recommendation is to develop on a server–a virtual server to be precise. You can download Virtual PC or VMware Server for free, and with an MSDN subscription you get developer licenses of Windows Server. Worst case, you can use the evaluation version of Windows Server. Install a new virtual machine with Windows Server and then install Visual Studio or any other development tools you need.

There's no need to install anything except the virtual machine software on your laptop, and you gain all the benefits of working directly on the server.

Question 8

Some people advise against writing .NET code and just work with the default functionality, since upgrading code later will be a problem. When should I develop my own code, and when should I work with the default features?

–Jagadeep

I'm a developer by heart, so if you ask me, I'd write everything in code. However, I'll buy several arguments for not doing so for everyone.

First, consider the nondevelopers who may need to maintain your features. Visual Studio may not be available, and in any case, recompiling and deploying an assembly every time you want to change a feature is more of a hassle than working with CAML definitions.

Second, some tasks are more difficult to accomplish in code than in CAML, such as creating list views. Even though technically possible through code and even though code would actually allow you to create dynamic views, if all you need to do is create a simple All Items–style view, doing so through CAML is a lot easier, especially when you use the technique I explain in Appendix A.

With that said, again, I love programming, and I use .NET code whenever I think the default features are too limiting or nonexistent. For example, the trivial task of finding out the number of current users on a site is virtually impossible through default features. Add some code, a few delegate controls, a custom action, and a custom administration page, and suddenly you have a very nice solution such as as SPCurrentUsers on CodePlex: http://www.codeplex.com/SPCurrentUsers.

I am probably the wrong person to ask because I like to test the boundaries of technology and focus less on production code.