SharePoint Kerberos Buddy Update – Release Created On CodePlex

Whoops. Sorry folks! I had just uploaded the .MSI and related setup files to the CodePlex site source control. I forgot to created a release with them which made it a pain to download. I should probably zip up the files so it’s one download but the MSI and setup.exe are now sorta easily available.

Share

What Are The Biggest SharePoint API Mistakes?

The most prevalent SharePoint API mistake that I see is the lack of freaking Exist properties on proxy objects.

What do I mean?

One can’t do this in order to test, for example, whether a SPList object exists:

[csharp]
public static void DoesMyListExistIDunno()
{
SPWeb web = SPContext.Current.Web;
SPList list = web.Lists[“Heres My List”];

bool areYouThere = list.{An Exists Property Would Be Sweet Wouldn’t It?};
}
[/csharp]

As opposed to this, a developer is forced to do this (or a mild variation of this, I am just using the LINQ because it looks fancy) which is lame:
[csharp]

public static bool InspectForList(string listName)
{
var results = SPContext.Current.Web.Lists.Cast().Where(item => Equals(string.Compare(item.Title, listName, true), 0));
return results.Count()> 0;
}

[/csharp]
What do you think is the most rampant and cumbersome? I am interested in what other people see as being a pain in the butt.

Share

Best Practice For Deploying Shared SharePoint Libraries

I am a huge fan of developing and employing shared libraries across the enterprise regardless of objective, be it third party WebPart interface components or exclusively containing common method implementation. I really enjoy the fact that code base refinement and adjustment can happen so effortlessly with minimal friction when a common baseline of libraries used (very important when using third party components since release cycles are not locally owned). I find myself doing this recurrently during SharePoint development because there are so many gaps within the current API it makes for a lucrative environment to develop cyclic components (i.e. building existence testing for proxy objects that don’t have it OOB) and common code base standards (i.e. when doing something remedial like root SPWeb reference executing corporate exception handling practices in a static method).

One principal issue, and one that I recently had to deal with, is intentional meager checking for globally referenced assemblies within the solution build and malformed solution builds. The SharePoint solution framework does not respect referenced assemblies, nor should it because it is developer accountability (much as it pains me to say).

What I mean by not respecting references is if you have two solutions that use an arbitrary shared library, each specifying the library as a deployment target within the solution manifest, during retraction for the first solution effectively the shared library will be removed, thereby breaking the secondary solution reference to that library resulting in a File Not Found exception. More granularly, each SharePoint solution will have within the solution manifest, in the Assemblies node, DeploymentTarget and location attributes that reference said shared assembly. This is a huge problem, but is working as intended (otherwise the solution framework wouldn’t be very effective would it?) and just requires diligence to correct.

Fundamentally, this is what the problem looks like:

So while the SharePoint solution framework allocates deployment ease and aggregate management; it places an exceptional quantity of power within the user that is responsible for package deployment (who may or may not be a developer). Therefore when using shared libraries that have multiple callers, you have two options. One I like, and the other one I find overcomplicated and a poor approach.

Package and deploy the shared library mutually exclusive from any specific component. Developers are allowed to assume that they can reference that assembly locally during build phases and it will exist in later cycles regardless of where code is moved / deployed.

Within any number of events and receivers, use Reflection, more specifically GetReferencedAssemblies() in order to build an array of all assemblies referenced and inspect whether the retraction should execute. While this seems like a fun option, it doesn’t offer the managerial aspects that the above does.

Share