Knowledge Matters

One of the most common questions I get asked from developers is “What is the best way to set up a SharePoint Dev Environment.  And they normally get a much longer answer than they’d like – there are a lot of things that can affect the answer – how many people are working together, what are their roles, how locked down are your developer boxes, are you using TFS… the list goes on.

Well, things are changing for SharePoint 2010.  And it’s a change for the better – I’ll cover a lot of the new items as we go along, but I would like to point out that the MSDN documentation now calls out the “standard” process for setting up a dev environment.  You can find it at http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx and use it as a basis for putting together your own customized development environment.

If you want a little more discussion on the matter, you can see what’s going on in the SharePoint Dev Wiki at http://www.sharepointdevwiki.com/display/sp2010/Building+a+SharePoint+2010+Development+machine

Tags: SharePoint

As I look back at the history of SharePoint, one of the primary features that made it so popular is the ability to store and work with any type of files.  This is GREAT from a user standpoint, but that capability requires that SharePoint work with those files as a BLOB (Black box of bits) when it stores them.  Second order issue for that then becomes that differencing versions of files becomes impractical and thus you end up with a copy of each version of a file.  If you’ve got a lot of active people working on documents, and you’re tracking versions – you end up having two basic options.  Limit how many versions of those files you will keep (putting a limit on how useful versioning is in the first place – not something your users will like), or throw LOTS of database space at your implementation (something that could have your DBA coming after you with a brick.) 

Well, with the 2007 generation of SharePoint, the product team introduced a feature deep in the technical documentation to allow remote blob stores.  This was something they were working very hard on to get to the right level of performance, ease, and API maturity so they kept it a bit low key.  But with the 2010 generation of SharePoint that we’re testing today, that capability is coming to the forefront for implementations that have very large numbers of files, or even organizations that already have mature file stores, and would like SharePoint to provide even easier integration. 

If you’re in either of these situations, or just interested in catching up with something that’s been around for a bit, but hasn’t been really in the spotlight, I’d highly recommend taking a look at the capabilities. 

http://blogs.msdn.com/opal/archive/2009/12/07/sharepoint-2010-beta-with-filestream-rbs-provider.aspx

Tags: SharePoint

I get asked a LOT for a short list of what has changed between SharePoint 2007 and SharePoint 2010.  Unfortunately that list is never short as there are more factors to dive into than most people want to look at – at least in a short list.  Level, configuration, licensing, User tools, it makes a pretty impressive matrix.  But there is an MSDN article that helps out by providing a general overview of many of the SharePoint new features and capabilities.

http://officebeta.microsoft.com/en-us/sharepointserverhelp/whats-new-in-microsoft-sharepoint-server-2010-HA010370058.aspx

Can help you plan what you want to learn more about and dig deeper into.  It’s a very nice overview of some of the high points from a capabilities model.  For a deeper dive into the development capabilities though, you’ll need to either check out the SharePoint conference material or tune in for the content that Zain is working up for our launch events in the spring.

Tags: SharePoint