This page covers things we know we can do better with and are currently working on improving.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.