​This page covers things we know we can do better with and are currently working on improving.

Docuentation

We've been meaning to publish this project for a long time, but never got around to it until now. Please be mericful as we try to get our act together. We'll have more documetnation and such in the weeks and months to come.

Issue Tracking, Code Sharing

We're only getting started. Right now all the code is in our repo on VisualStudio.com and we need to look into moving it to GitHub or something like that so we can share with other contributors. If you want to help in the meantime and have your own MSDN subscription, we can grant you access to the repository.

Releasing Stable Packages

So, what we're doing right now is pushing some package versions to our private feed in Visual Studio Online, and then only pushing to Nuget when we know a package is stable enough. That way, the bugs we're introducing hopefully won't be something that affects the developer community. This is why you'll see that package versions will skip a few numbers. Early on we weren't realizing this would mean that changes and features aren't necessarily communicated for the updated packages. What we're doing now is keeping the revision history in the comments of the nuspec file, so that when we release a public package we can also share the culumlative updates. If anyone can suggest to me a better methodology, I'd appreciate it if you'd drop us a line.

Frameworks and Versions

Over the years, Microsoft has changed the overall model for SharePoint development quite a few times. In the early days it was enough to try and keep track of Debug vs. Release and different .NET frameworks (2.0 for SharePoint 2007, 3.5 for SharePoint 2010, 4.5 for SharePoint 2013).

Now things are much more complex. For the 2010 version, we had to seperate our code into thing that would run only on farm soluitions, things that would run on the server as a sandbox, and things that were meant to run from the client. Over time it became obvious that client code comes in both compiled (c#) flavors, as well as script (js) and that the latter needs a methodology to deploy it to the server which can take one of several possible forms. Add to this complexity the fact that we can now write "apps" for SharePoint (or Add-ins) if you prefer) and that sometimes these run entirely on Azure Web Apps or other servers that aren't running SharePoint at all.

And that doesn't even count the dozens of web parts and other one-off projects that we've built over the years and intend to put out into the wild at some point.

Thus, over the years there have proliferated a dizzying array of proejcts intended for different purposes, as well as different build configurations intended for different versions of SharePoint. Of course not every combination or configuration can be tested regularly by our small development team.

At present, only the 4.5 version of Kraken.SharePoint.Client is up on CodePlex. For the server-side stuff, it is much more important that we make sure it will compile and run without serious issues at least on SP2010 and 2013, though hopefully 2016 will be an option too. We expect that these will not make their debut on Nuget until we are sure that we can offer you that choice of platforms. Meanwhile, if you have a particular need, reach out to us and we'll see what we can do.

Compiler Warnings

Yeah, there are a ton of them. There's a lot of code to sift through and precious little time. We plan to do a push to reduce the number of warnings as soon as we can. Meanwhile, you're welcome to join the open source effort and help us out.

SPDisposeCheck and potential memory leaks

This is really more of a server-side library thing, so it affects our older code rather than the libraries for clients and apps. We ran this tool a few years ago, but we know that we need to do this again. Most modern SharePoint solutions are done using CSOM and not server side object model, so we admit this hasn't been our focus. There's a Beowulf project coming up in the next few months that should help to fund getting this done. Meanwhile, you're welcome to pitch in and lend a hand.

SPCAF

We have a copy of SPCAF, and we're already in the process of working through the issues identified by that tool. So, if you have your own copy, don't be surprised by what you find there. It's also important to understand that many of the critical warnings generated by SPCAF are specifically for certain code practices used in SharePoint development that can be considered "hacks"; they're in our library because sometimes they're the only way to get the job done, not because they represent best practices. We use them sparingly and we know what we're doing. We'll update our documentation to make it clear what's going on in this situations, so that if you use our library, you can choose to embrace or avoid these tactics as necessary.

Licensing

We decided to use LGPL as our open source license. We haven't had the chance to go through every dependent project that we use, or every blog we ever got ideas from to see if we're complying with their license. Frankly speaking, we probably never will. Here are a couple guidelines we try to follow.

If you've published a function or code block on your blog, and we used it as inspiration for something in our code base, then we've tried to put a thank you message and link-back in the comments of our code. As a rule, we try not to copy entire methods from while cloth. Because we use Kraken in production, we have to put all the functionality through a process of refactoring and other improvements to make it configurable, stable, usable, and maintainable. Chances are that by the time we're done, the code may not look very much like your original work. We're operating under the assumption that, by posting source code in blogs, it is the intention of the author that other programmers will use and improve it, whether you've explicitly posted it with a license (such as CC) or not. Please understand it would be almost improssible for us to track individually the terms of each individual author's web site.

We all stand on the backs of giants, and we want everyone to know that it's not our intention to steal from anybody, which is why we're publishing Kraken where we can return the favor by sharing our work with the community. If you feel like we missed giving you credit for something, please reach out to us directly; posting public comments on the forums isn't likely to be noticed by us as quickly (or received as positively) as a simple email to myself or another member of our team.

If we download and use a library that you wrote, whether its by Nuget or some other means, please understand that we've done only very limited checking to make sure we're complying with the terms of your license. For Nuget packages, the end user is responsible for agreeing and following your license, and if we've accidentally leveraged packages that complicate the licensing process for your project, we apologize. We assume most code is either going to be available in some flavor of the MS-PL, GPL/LGPL, MIT or similar license approved by the OSI and FSF and that if you're using Nuget, you already accept that open source is a reality and it is not a cause for concern at your place of business.

For packages downloaded and incorporated directly into our library either as DLLs or source code - whether downloaded from your web site, CodePlex, or elsewhere - the process of following up on license compliance is much more challenging, but we expect to make a pass at this in the near future to make sure we've included and necessary notices, licenses, credits, and documentation within our own code. This list is not so long, so please be patient with us while we get it sorted out. Chances are that for those few authors in this situation we'll be reaching out to you on an individual basis.

Unit Tests

Yes, we have them. No, I don't particularly think they do anything useful or prove the code is any good, and we need to work on that. Kraken is now so big that we could never test all this stuff manually, so this is something we recognize needs to happen in the near future.