Why does SharePoint creates a new version of a document in a document library when you edit properties?

I’m working on an article for IntranetJournal about the way that SharePoint actually uses meta data (fields) in a document library and as I was crawling through the details it occurred to me one of the reasons why SharePoint has to create a new version when you update the properties of the file.  Many people have wondered why this causes a new version to be created — including myself.  However, I believe that I’ve stumbled across the answer — Because it *IS* a new version in some cases.

In the case of Office documents, the document itself gets updated to reflect the new properties.  You can see for yourself by checking File-Properties-File Properties on the file.

It’s also storing the previous properties off if you needed to restore them, even if there is no way to see them.  (It’s not just recreating them from the properties in the document because it has the behavior of restoring the properties even for non-Office documents.)

Display a Random Item from a SharePoint List: Beta Testing

One of the annoying things for me has been trying to get a web part that would show a random item from a list.  I’ve wanted to feature projects, employees, questions/answer sets, etc. on the home page to keep it new without having to finely control what data was exposed on the home page.

I’ve completed the coding for a Random Item web part which takes a random item from a list and displays it using the formatting that the user/developer provides.  It has the ability to support previous and next buttons as well as the ability to cache the results for a period of time so that the entire page isn’t in a constant state of flux.

I’ve still got to finish the documentation and create a few example DWPs, but I’m looking for folks who are interested in beta testing the web part and letting me know what additional features it needs.

Find a Person

I was speaking with Todd Bleeker who is still very excited about the possibilities of the Content Editor web part. Then I went to a client who was having a typical problem — making it easy to find people in their organization.

The net result was that I created a web part that leverages the Content Editor web part to use the REST format of the search page to find people. I’ve made the dwp available here for those who might be able to use it.  I’m starting to see why Todd likes this approach.  It’s good for some simple things that you want to get done without a lot of coding.

Anatomy of a Software Development Role: Project Manager

Open source software on the desktop — Is it right for you?

There are few topics more heated than the discussion surrounding Open Source vs. Microsoft. This discussion typically focuses on the difference between Linux and Windows as an operating system. This is, however, only one dimension of the problem. You have to consider both the operating system and the office software that most users use. You must add to that everything else you have to support that isn’t included in the basic office applications.

http://www.techrepublic.com/article/open-source-software-on-the-desktop-is-it-right-for-you/

Link Tracking Beta

I finished a new web part kit over the weekend.  It is called Link Tracking, and allows you to see how frequently that users are actually using the links that are in the portal.  Most customers I’ve talked to are completely unaware of when the users are using the links on the portal, as a result it’s hard to fine-tune the number and type of links on the site.

Link tracking fixes this by recording each link as it’s clicked so you can go back and review the number of people who have used the link.

I’m looking for three beta participants with the commercial release being later this month.  If selected for the beta, I’ll give you a license to the final code when it comes out.

Rob

How to use SharePoint as a Mail Merge Source

I was looking for how to perform a mail merge using a SharePoint list as a source and found Wayne’s post asking the same question.  There wasn’t help there, however, amongst the comment was on from Yatin Purohit indicating that you could link to the SharePoint list as a table in Access and then use the Access table as a source for Word to use in a mail merge.  It’s a pretty useful technique — too bad there’s not an OLEDB driver for SharePoint lists. I suppose this will work for now.

A few other dumb things that you can do with .NET — but shouldn’t.

In my previous post I highlighted a single bad idea that I had seen in some code.  I want to offer up a few other things that I saw and why you shouldn’t do them…

  • Tightly nested Try/Catch blocks — basically, put a try block, do one statement, add a try block in that block and repeat…  See the code…

            static public void LogRequestResult(string url, string status)

            {

                  try

                  {

                        FileStream objFileStream = null;

                        StreamWriter objStreamWriter = null;

 

                        try

                        {

                              objFileStream = File.Open(cnstMyFilePath, FileMode.Append, FileAccess.Write, FileShare.Read);

                              try

                              {

                                    objStreamWriter = new StreamWriter(objFileStream);

                                    lock(objStreamWriter)

                                    {

                                          objStreamWriter.Write(Status + url);

                                    }

                              }

                              finally

                              {

                                    if (objStreamWriter != null) objStreamWriter.Close();

                              }

                        }

                        finally

                        {

                              if (objFileStream != null) objFileStream.Close();

                        }

                  }

                  catch

                  {

                  }

            }


Ignoring the fact that we’re not actually doing any error checking… Isn’t the following much more straightforward easier to read, and less prone to errors?  The moral to the story, try/catch blocks are cool but don’t abuse them.

 


            static public void LogRequestResult(string url, string status)

            {

                  FileStream objFileStream = null;

                  StreamWriter objStreamWriter = null;

                  try

                  {

                        objFileStream = File.Open(cnstMyFilePath, FileMode.Append, FileAccess.Write, FileShare.Read);

                        objStreamWriter = new StreamWriter(objFileStream);

                        lock(objStreamWriter)

                        {

                              objStreamWriter.Write(Status + url);

                        }

                  }

                  finally

                  {

                        if (objStreamWriter != null) objFileStream.Close();

                        if (objFileStream != null) objFileStream.Close();

                  }

            }


  • Magic Numbers (or in this case letters), just stop — I can’t tell you how many times I’m looking through code and I come across an if statement that looks like “if myvariable == “A““  Why in the world would your variable is “A“.  What does “A“ mean?  In .NET we have enumerations and constants.  Why can’t we just them?  I have no idea what “A“ means — and neither will the author 2 months from now.  If you put quotes around the same text twice it should be a constant.  If you use a number for an if statement or as part of an assignment that isn’t a 0 or a 1, you should have a constant.  (Zero is a number to compare against, 1 is a number to fix a number of offset issues.)
  • Comments — Hey, there’s a concept.  And I don’t mean one that says, // the following line adds one to the number.  Thanks.  I can read code.  How about writing comments that tell me why you’re adding one to the number?  Oh, yea, those XML comment things that .NET supports.  Those are useful.  You can use them too, they’re not expensive.

Do you have any pet peves about code that should go on this list?

 

How Not to test for a null string in .NET

Today I was forced to read some code for a developer that I loathe.  Just when I believe I’ve seen every stupid thing you can do with code I am surprised by a new structure that he repeats everywhere through his code.  Here’s what I saw today…

string myString = (GetStringFromConfiguration(”keyvalue”) + “”).ToLower();

At first I did a double take, it doesn’t make sense to add an empty string to a string … that is unless you’re trying to prevent the null reference exception from ToLower().  Adding null to any string results in that string.  Thus, you *CAN* work around null references by using this technique.  However, here is why you shouldn’t.

When you do this you actually force the CLR to create an extra, unnecessary new string object.  It creates a temporary string object which it concatenates the result of the function and the empty string into.  Another string is created when the string is taken ToLower().  That one can’t be helped, but the intervening one — the one caused by the concatenation, can be eliminated.

OK, sure, it’s a detail and it probably won’t matter much to most people but it will perform slower, require more memory, etc. The biggest thing for me is that it’s really odd from a readability/understandability perspective.  (Did I mention that there are no comments in this code?)

Ideally, I’d create a GetStringFromConfiguration function overload that took a second parameter of what I wanted back if the entry wasn’t in the configuration file.  That way the code doesn’t concern itself with the details, it knows that it will always get back a valid string.  This is in fact what I do when I have to be concerned about getting back a null when I need it to be functionally equivelent of a default or an empty string.

As a sidebar, it would have been nice to see a String.Empty instead of ““ … oh well, you can’t win them all.

 

 

Develop a strategy for requirements gathering

In most mid-sized IT organizations the process of gathering requirements is a little more advanced than scribbling a few wire frame representations of what the screen for the new system should look like. (A wire frame is simply a line drawing with boxes, rectangles, and text which roughly describes what the final product may look like.) This mechanism for collecting requirements is quick. After a few minutes and a handful of sketches, enough information can be gathered to start developing a solution.

http://www.techrepublic.com/article/develop-a-strategy-for-requirements-gathering/