I was in a SharePoint governance meeting at one of my customer sites yesterday and the group is thinking of enforcing some rules as far as SharePoint solution packages go. I kept saying during the meeting “Inspect the manifest file so that you can view what files are going to be installed on the server and where they are going to get installed”. One of the network engineers asked “How do you read a manifest file given a WSP?” This is probably common knowledge to people who are SharePoint veterans. But if you didn’t know how it’s done, here’s how:

1. Rename the wsp file to a .cab file
2. Open up the .cab file (used to be wsp) in WinZIP or something that can open a CAB file.
3. You can either: a)  extract all files in the cab file and open up the extracted manifest.xml; or b) look for manifest.xml in WinZIP and just extract that one single file.
4. Open up manifest.xml in notepad, Internet Explorer, or your preferred XML file viewer.

That’s it!

Several of my upcoming posts will be on how to create solution packages. Stay tuned!

In the world of managed-code, the garbage-collector typically clears objects in memory automatically for you. Remember malloc() and free() in C++? In managed code, you just typically write “variable = new Object()” and the CLR will allocate the memory for you. In unmanaged world like C++, you had to allocated memory and then deallocate memory after use.

Most objects in ASP.NET Framework are allocated/deallocated in memory automatically. However, there are objects that inherit from the IDisposable. You have to explicitly dispose objects that implement the IDisposable interface or you will run the risk of memory leaks. Some examples of ASP.NET objects that implement IDisposable include Connection, Command, Adapater, and Reader objects (in the System.Data namespace). You can perform any of the following to dispose these objects properly:

SQLConnection connection = new SQLConnection(connectionString);

//use the connection object here

connection.Dispose();

 

Or, you can using the using statement:

using(SQLConnection connection = new SQLConnection(connectionString))

{

                //use connection object here

} // don't have to call Dispose(); the using statement will dispose connection correctly

When working with SharePoint API (SharePoint .NET libraries and not the SharePoint Web services), it is important to know when and when not to dispose SharePoint objects. If you do not dispose objects in SharePoint, your server will run the risk of memory leaks which can lead to performance issues. If you dispose objects that you’re not supposed to call Dispose() on, you might inadvertently kill the SharePoint application! For example, the following code will definitely kill the SharePoint Web application:

SPContext.Current.Web.Dispose(); // expect calls to your help-desk with this line in your code!

 

If you are the custodian of the SharePoint farm, you might want to use the SP Dispose Checker Tool to ensure that the custom .NET assemblies being installed on your farm will not cause memory leaks.

For complete guidance on when and how to dispose SharePoint objects, you can read the SP Dispose Team blog.

The SharePoint conference just concluded in Vegas. So many things being discussed right now with the upcoming SharePoint 2010. My friend Russell emailed me this article about SharePoint: SharePoint is Microsoft’s Real Window of Opportunity.

The article couldn’t have explained it better about the strategic importance of SharePoint. People think SharePoint is all about Web 2.0, collaboration, content management, etc. SharePoint is that but it’s NOT ALL that. You see, it’s all about protecting and promoting the Microsoft Office product line. Years ago, Open Office came along and gave people a free alternative to having software to create documents, spreadsheets, presentation slides, and email client. Microsoft Office cost money while Open Office was free–based purely on price-point, Open Office seemed like a no brainer. Then early versions of SharePoint came along; I thought the first versions were utter crap. Better “content management” systems came along, some of them open-source such that they were attractive to organizations with small budgets. Open source Web 2.0 such as Media Wiki and WordPress also came along. Fine products if I may say so myself. Meanwhile, Microsoft was busy improving Office, SharePoint, and the .NET Frameworks. This coming version of SharePoint integrates all of that together. Keyword is interoperability. The Office products (Word, Excel, Access, Outlook) integrate with SharePoint and .NET and .NET runs inside Office (macros and code-behinds) and in SharePoint (Web parts, features). Then there is the SharePoint Enterprise Search–if the organization was putting most if not all of their artifacts in SharePoint, people within the organization can find information regardless of whether the information resides in a Web site, a  Word document, a database, a blog, a wiki, etc.
 
Now, imagine getting Open Office as your productivity tool, Media Wiki as your wiki tool, and WordPress as your blogging tool, and then get some open-source search engine. Cost is zero dollars for software licenses so far. Add an open-source email client and mail server. The cost is still zero up to this point. Now integrate all that disparate technologies and maintain it over long term. Can you even integrate all that stuff at all? Say, they managed to integrate Open Office and WordPress and the integration breaks later on, who is responsible for the fix? In other words, who will provide support? Open Office developers? Or should that be the WordPress developers’ responsibility? Or is it the shop maintaining the integration (after all, they do have the source code)?
 
It will be very difficult to make all that open-source or “cheaper” alternatives inter-operate with each other. At the end of the day, SharePoint and Office is a one-stop-shop for everything–document creation and editing, sharing, calendars, tasking, blogging, knowledge management, forms, businss data, dash boards, and search.
 
SharePoint is like a Swiss Army knife–it has different things packaged into one. If each of the features of SharePoint is a tool within the Swiss Army knife, then one can say that technologies trying to compete with SharePoint are individual tools and they’re not together. Should an office always buy and implement the Swiss Army knife? No. If  it just needs a screw driver and nothing else, the bottle opener and the rest of the stuff is frivolous, So, that office is better off just “buying a screw driver”. To use SharePoint just for blogging is overkill. To use SharePoint just so there is a place to upload documents to is overkill. To use SharePoint just as a content management system is not getting your money’s worth. You get the point. If you just need blogging, just get WordPress. If you just need wikis, get MediaWiki. And so forth.
 
The article also points out that Google is the only closest thing to provide the “one-stop-shop” alternative to SharePoint. I’m not very familiar with this coming Google Wave just yet. All I know is that it’s going to be “cloud-based”. If it’s going to be an outsourced cloud, such that Google hosts the data and apps, a lot of big companies will shun from it. Amazon S3 is already out there yet you can’t use that cloud technology for everything; Amazon S3 fails to comply with financial standards/requirements (example: Amazon will tell you do not store credit card transactions in their platform). Sensitive corporate or national security stuff going to an outsourced cloud? Forget it; it ain’t gonna happen. Check this picture though–Google might allow companies to implement a private cloud:
 
http://www.waveprotocol.org/Home/federation_diagram.png?attredirects=0
 
We really don’t know what the cost will be to implement the Google way when it’s ready. We’ll find out soon enough. By the time Google or anybody can provide all that is provided by SharePoint, Microsoft would have sold many licenses at that point that they can give this product away for free. Oh, another way to say it is by the time Google or anybody else has figured it out, Office will be so entrenched everywhere that Microsoft can give away freebies.
 
Heck, if one looks at it, it seems Microsoft is already giving people a cheap alternative. Enterprise SharePoint (MOSS) is expensive, right? Well, you can get a zero-dollar-cost solution and still be in SharePoint. Here’s what you do:

• Get SQL Server 2005 Express for free
• Get WSS 3.0 from microsoft.com for free (if OS is Small Business Server 2008, WSS 3.0 is already there, for free)
• Get Search Server 2008 Server from microsoft.com for free
• Go to codeplex.com and get BlogEngine.NET for free to get enhanced blogging. Did I say it’s free?
• Download Community Kit from codeplex.com for free and get an enhanced wiki engine.. Again, free.

The nice thing is that all of these will integrate together. The integration of all of the listed above comes close to MOSS but still missing a few features such as Publishing feature, Excel Services, InfoPath Forms Server, and Business Data Catalog. But all of that for free! Search used to be part of Enterprise MOSS. I couldn’t believe it when Microsoft started giving that stuff way for free! I can see Microsoft giving away more free stuff in the future there really is no point to going to an open-source alternative. Open-source developer Gary Edwards is worried. And rightly so.