Installing .NET Framework 3.5 on Windows 8.1

God, why is this so difficult? I needed to install the .NET framework 3.5 (for SQL Management Studio, dammit!) on my Windows 8.1 machine. You’re supposed to be able to do this from control panel (Programs and Feature > Turn on Windows Features > .Net 3.5). It didn’t work for me. Continue reading “Installing .NET Framework 3.5 on Windows 8.1”

Advertisements
Installing .NET Framework 3.5 on Windows 8.1

Error: "RootWebOnly='FALSE'" is True…

I wrote a feature to deploy a couple of pages into a Pages library on a site. The idea was that these were search pages, and they’d be going into a Search Center. My feature had an Elements manifest of:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="CustomSearchPages" Url="Pages" RootWebOnly="FALSE" Path="Pages">
<File Url="advanced.aspx" IgnoreIfAlreadyExists="TRUE" Type="GhostableInLibrary">
</File>
<File Url="contentresults.aspx" IgnoreIfAlreadyExists="TRUE" Type="GhostableInLibrary">
</File>
</Module>
</Elements>

Yet when I activated this on my Search Center, the pages weren’t installed. This was weird, ‘cos I’d done nearly exactly the same thing to install my custom Master page. I began swapping bits of the Master Page feature into my Search Pages feature to see if they worked, which at first they didn’t. Then, by accident, I tried installing my Search Pages on my root site, and they did install.

Interesting.

There followed a bit of wild, stab-in-the-dark guessing. I’d seen lots of examples of installing new page layouts, or installing new master pages. These should all go in the root site (or ‘root web’), and so their Module node would specify RootWebOnly="TRUE". I could find very few results, though, where RootWebOnly="FALSE", which is a little unusual on Google. What if the thing that made a module only install on a root site was the presence of a RootWebOnly attribute, rather than the value of it? I tried:

<Module Name="CustomSearchPages" Url="Pages" Path="Pages">

for my module tag. Well, that’s what it turned out to be. I removed the RootWebOnly="FALSE" attribute, and suddenly my pages would install. I guess I was stupid for trying to be explicit in saying that this feature was not only for the root site. I’ve gotta be honest, that sucks, and it wasted me 4 hours. Clearly, it shouldn’t just be the presence of the attribute; by setting it to False I was saying specifically that the feature was not for root sites only. Someone was shoddy in their processing of the XML.

Error: "RootWebOnly='FALSE'" is True…

Create an Image only Search Scope in Sharepoint

Previously I’d looked at having a search that shows thumbnails of images in SharePoint. I modified the results page to do this – but the results themselves would still show non-Picture items (e.g. documents, pages, etc.). In this post, I’ll configure up a new Search Scope for images only. Continue reading “Create an Image only Search Scope in Sharepoint”

Create an Image only Search Scope in Sharepoint

The curious incident of the date column in the night-time

I have been tearing my hair out over a problem with dates and timezones. We have a site column ‘Document Date’ that we are using in our search results page. It only holds a date.

Our client noticed that some dates appeared on the search results page as a day earlier than the value in the lists themselves. For example, the list would show a document date of the 8th of May, but the search results would show the 7th of May. Curious, and the start of a bit of a detective story… Continue reading “The curious incident of the date column in the night-time”

The curious incident of the date column in the night-time

Hit Highlighting in SharePoint Search Document Titles

I came across an interesting behaviour in a search results page I’ve been working on. I’d added some code to do search highlighting on the results of a query. Here’s an example of the results I got for a search for ‘Barnacles’:

Search Results showing Hit Highlighting in the Titles and Description of documents

The observant amongst you will notice that the titles all contain the word ‘Barnacles’, but only some are highlighted – specifically where the word barnacles is not the last word before the dot-extension of the file name. I did some further testing and found that the search does recognise the word ‘Barnacles’ in the file name, but the hit highlighting doesn’t seem to. Continue reading “Hit Highlighting in SharePoint Search Document Titles”

Hit Highlighting in SharePoint Search Document Titles

Self Referencing Lookup columns

Came across something I’d not considered – self referencing lookup columns! I was doing some testing, and this totally caught me out (and caused my Outlook plugin to crash and die).

Basically, this is a Lookup column where the List that it is looking up onto is the same as the list where the lookup column is in use. In our case we had a list called ‘Issues’, and the lookup was a multi-choice look-up called ‘Related Issues’. It would let a user select things from the Issues list. All in all, a perfectly sensible use of a multiple lookup, and one I’d not thought of!

However, this in itself wouldn’t cause my plug-in to suffer an error. The problem was with the data I was getting back from the Web Services I’m using. I use the List Webservice‘s GetListContentType method to get information about the Content Type, and I then read the information about the fields. Lookup fields normally come through with an attribute List ; this is the list that’s being looked up onto, and normally it is a GUID. However, for self-referencing lookup instead of a GUID, you get a string ‘Self’‘. Okay, I can’t argue that it’s wrong, but it’s a smidgen annoying that it is inconsistent. Couldn’t it just give me the GUID and let me figure out if that’s the same list? Or use another attribute to denote that it’s a self-reference?

I don’t get why this was built that way.

Self Referencing Lookup columns

Duplicate rows from the SharePoint Lists webservice.

Edit: I’ve since learned more about this behaviour – but it’s still not very obvious

I found what I can only describe as a but in the Lists.asmx web service in SharePoint. I was using Lists.GetListItems to get a list of the folders in a Document Library, and I found that I was getting one of the folders twice. However, when I looked in SharePoint, there was only one, and my program showed that both these folders were supposed to be at the same URL. WTF?

Naturally, I went back and had a look at the XML I was getting back from the web service. I expected to get two, so I was somewhat surprised to get 3…

GetListItems Response XML Showing 3 records

As you can see, 2 records have the same URL, the same internal ID (both of which have to be unique!), and the only difference is in the AWBMultiLookup column. This set alarm bells ringing. Firstly, I was surprised to see it in the results. In GetListItems you can define the fields you want returned in the responses (the ‘view fields’ ). I had only asked for the URL, the ‘link file name’ (the item’s name), and it’s ID. I’d expect to get some other details (the web services always seem to include more), but not field data.

Secondly, AWBMultiLookup is a multi-select lookup column. In other words, it looks up data from another list, and you can can select zero to many items from it. For my folder, I’d selected 2 options from this column (‘A’ and ‘C’), and now I have 2 records with the only difference being the value of the AWBMultiLookup column – ‘A’ or ‘C’. On a hunch, I went and selected a third option (‘B’), and my XML I was getting back became:

GetListItems Response XML Showing 4 records

Yup, now I got 3 records with different values of AWBMultiLookup, rather than just the one. Clearly, and incredibly, the web service was returning a seperate ‘item’ for each value of the multi-select lookup column that was selected. I can’t think of a situation where that would be the desired behaviour – and everywhere else in the system, multiple values are just encoded into one string. Hence, I’m calling that a bug.

However, this raised a question. Elsewhere in the system I get just the one folder and it was definitely getting the multi-select lookup field correctly. I ran that code and found that the XML I got back was:

Results of GetListItem with a Multiple lookup where all values are returned in one attribute

Yup, you’ll notice that the results from GetListItems this time shows all the values for the multi-select lookup in one attribute. What gives? What’s different about this query to the other one where multiple items would be returned?

Well, the only difference that seemed like it could be relevant is that this second query requests the ‘AWBMultiLookup‘ column in the ‘view fields’. I decided that I’d test this by modifying the view fields for my first query to include the AWBMultiLookup column like so:

View Fields changed to get the multi-select lookup

Having done this, my query now worked as I’d expected it to in the first place:

GetListItemsResponseXML with defined view including multiple lookup

Notice that all values are now encoded in the one attribute, and that I’m getting the two records I’d originally expected.

Or course, this doesn’t help me. When my application is browsing across folders I don’t actually know what the columns against folder really are, so even if I was happy to request the multi-select lookup fields (despite their being superfluous ), I can’t, ‘cos I don’t know what they are yet. I’ve gotta admit, though, that I’ve lost my temper at whoever made the web services work that way. It’s worth noting that the SharePoint API doesn’t behave similarly

One thing I haven’t checked yet is what happens if you hav many multi-select lookups. Combinatorial explosion anyone?

Duplicate rows from the SharePoint Lists webservice.