Adding newsequentialid() to Default Value in SQL Server Management Studio

This is apparently a really well known issue with SQL Server Management Studio. When you try to add “newsequentialid()” to the “Default Value or Binding” field in the designer it keeps throwing the error “Error validating the default for column ”. Do you want to cancel your changes?”. The method I found to work around this is shown below using T-SQL instead of the designer UI.

ALTER TABLE dbo.TableName ADD CONSTRAINT DF_ColumnName DEFAULT newsequentialid() FOR ColumnName

Auto Indenting XML Attributes in VS2010

Here is something I’m definitely going to forget, the following post shows how to setup attribute indentation on a separate line with the auto-formatting (Ctrl+K+F) command.

http://darkeyedev.blogspot.com.au/2010/10/visual-studio-auto-formatting-of-xml.html

In case this link becomes dead in the future, here is what you need to do as quoted from the post.

"Visual Studio 2010 > Tools > Options > Text Editor > XML > Formatting > Attributes > Select 'Align attributes each on a separate line'."

SharePoint Designer 2013 Design View: It’s not a developer vs non-developer argument

Having read a few of the posts around and the comments to said posts as well as on forums, I can’t help but feel this discussion is taking on a “developer vs non-developer” view. From the developers standpoint you have the opinions like that of Bjorn’s who think that past atrocities perpetrated by power users that are sufficient reason to take away the core of their power… design view. Common arguments for the power users, such as those posed by Marc, range from the increased barrier to entry for non-developer types (the task of debugging XSL has been made extremely difficult for developers meaning its virtually impossible for non-developers) to the inflated budgetary requirements (due to the need for more developers).

The problem I take with these arguments is that they concentrate on this whole “developer vs non-developer” argument. To be perfectly honest, on this playing field the developers have it. The rubbish solutions that the deign view has helped contribute to is a pretty solid reason to remove it as developers are the ones that should be doing any kind of development. Although I do agree with this sentiment, my argument exists on a different field. The argument I make is one of negotiation. Of course this argument only works if you are an ethical consultant not looking to take your client’s to the cleaners. I’m actually a massive optimist in the human spirit so for the purposes of this post I’m going to assume you too are not looking to rip off your client.

For my consultancy (Seven Sigma Business Solutions but soon to be Inovus), governance is at the forefront of everything we do. A huge part of this is training of power and end users. In our consultancy the argument of “rubbish solutions” is really a null argument as we will setup a simple development environment (a development site collection typically) in which the power users first create their SharePoint Designer based solutions. This gives them a chance to learn but also provides us with a way to govern their solutions before they have a chance to go into production thus providing some level of quality control.

This learning process is extremely important to delivering good solutions because ultimately the users are the ones that understand their business the best. One of the toughest challenges I have faced as a consultant is the whole “the customer is always right” mentality. Whilst correct, the meaning has been sorely manipulated. The customer is only always right if they have all the right information and often they are very poorly informed or are sorely misguided. Once they see the limitations of SharePoint with their own eyes and understand the difficulties, it means we can then proceed to negotiate for the best solution. This solution often not only requires configuration/development of SharePoint but also cultural/process change within the organisation itself. To put it simply, Microsoft has now removed the greatest learning tool I had for helping non-development users grasp the complexities involved with developing innovative, user-targeted solutions in SharePoint. By removing this learning tool all developers are going to suffer as they now have one less weapon in their belts that they can negotiate with.

Unit Testing Internal Classes

So I recently got my Scrum Master Certification and as a result I have felt an obligation to begin practicing what I now preach. So part of this “transition” in my developer life has been to start forcing myself to just commit to doing test driven development (TDD) for everything I develop. Its been a transition that I knew I would eventually have to make but have been very reluctant because its so different to what I’m used to. Now that I have started doing it, I feel quite stupid I didn’t do it earlier, it just makes so much sense on so many different levels.

Anyway the point of this post is not to gush about how great TDD is, what I wanted to do was just document one of the learnings I had recently where I had a class that I had made internal. Obviously the unit tests all sit in a different project in a different assembly and I needed the unit tests to get access to my class. I found this post where someone had put in a great answer but for whatever reason it wasn’t chosen as the top answer so I thought I may just let everyone know that what you want to do is use the following code:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("UnitTestsAssemblyName")]

Place this in the “AssemblyInfo.cs” file under the “Properties” folder in your project. Replace the “UnitTestsAssemblyName” with the name of the assembly where your unit tests are stored and after a re-compile of your assembly you’ll have access to all the internal classes.

One of the arguments on the post was that in TDD the tests really should be testing user-centric features and those features really should be public. I personally disagree to this statement for the fact that the user-centric feature really has no bearing on the structure of your classes and assemblies so long as the feature is implemented, as requested by the user. Just because a class doesn’t directly implement a user-centric feature doesn’t mean you don’t want to perform thorough testing on it to make sure that any changes to this class don’t impact the stability of the entire project.

In the current example I’m working on, I have a helper class that performs some XML de-serialisation tasks. I don’t feel that there is a need for these classes to be viewed by anything outside of my assembly but if I need to change the checks that are done during XML de-serialization, I want to have some level of assurance that I have the basic checks and balances in-place that will quickly pick-up any obvious mistakes.

South East Asia SharePoint Conference Presentation

For anyone thats interest I’ve got my slides from my South East Asia SharePoint Conference presentation on “The Modern Art of Taming Software Developers” available here. The slides don’t have everything I talk about so if you’re interested in finding out more, follow me on twitter (@christomich82) and I’ll let you know when the next conference I’ll be presenting at is.

The SharePoint ‘Tacklebox’

The other day I was talking to one of my clients and I was trying to explain what SharePoint is exactly and why projects delivering them tend to fail. Like most others, they had been sold on the collaborative power that SharePoint introduces into an organisation and how it was the be all and end all of online delivery of content, collaboration, business intelligence, search etc. After a little search in my head for the best analogy I could think of, I settled on comparing it to a fisherman’s tackle box.

When I was much younger my dad bought this fantastic fishing tackle box. It’s one of those boxes that when you pulled back the lid there would be all these multilevel compartments that could be folded out and had millions of little drawers to hold all kinds of different fishing tackle. My dad had filled it up with all kinds of different hooks, sinkers, floaters, leaders, etc. By having everything at our disposal it meant that we would be prepared for any fishing environment.

Now just because we had purchased a complete kit with all the equipment any fishing pro would have at his disposal did not make everyone in my family a pro. In most cases I had no clue what the thing did or when or how it should even be used. Context is a major part of fishing, just like in a SharePoint project. Knowing what the functional use for the accessory is does not mean you know the environment or situation in which to use it. For example, can you have a guess as to what the following equipment is and when it’s typically used?

If you didn’t manage to guess it, its a fish bite alarm. To some this may seem pointless because you’d be asking the question “wouldn’t you know that you have a fish by the fact its trying to rip the rod out of your line?” and you’d be correct in some circumstances but there are times when you may have multiple lines or the kind of fish you’re fishing for requires a more subtle technique meaning the bite is quite hard to detect without some kind of aid. SharePoint is no different; there is a time and a place for all its components.

When you install SharePoint, you aren’t installing a tool with the knowledge and wisdom of a thousand grey haired developers. What you’re installing is a tool of immeasurable pain toolbox of components commonly used in the development of a variety of web based applications. Just like fishing, we need to know the environment we’re in. We need to know whether it is an intranet site, internet site, collaborative portal, document management portal, or records management portal (just to mention a few) that we’re building. We also need to have an understanding of the IT / businesses processes and procedures in place as these are likely to affect the kinds of solutions and the paths we choose for customisation.

Judging the success/failure of a SharePoint project is also much like fishing, we judge it on the level of user engagement we attract. The less user engagement, the more likely we’ve totally missed the needs of the business. The more we understand the business needs as the business views it (I’m glaring at those developers who think they know the business better than the business knows itself) before we undertake the development of the project then the higher level of user engagement we’ll receive.

The ultimate point in all of this is that SharePoint alone won’t get the level of user engagement sought after by organisations. There is a level of maturity and understanding required by implementers around both the needs of the business and the business goals that are to be achieved. These need to be understood long before you decide upon SharePoint as the platform. It’s for this reason that many SharePoint projects fail. SharePoint can deliver on the promises of collaboration, portal, business intelligence, business processes, content management, and search. What it can’t deliver and doesn’t promise to deliver is that these tools will be used properly by the SharePoint ‘fisherman’ and that any users will be successfully ‘caught’.

Shameless Conference Plug

I’ve been accepted to present on SharePoint governance and finding goal alignment at the SharePoint Conference Asia 2011 in Singapore so here is my shameless plug to come to my session.

I’ll be discussing various techniques we’ve used to find goal alignment within an organisation as this has been a critical success factor in all the SharePoint deployments my consultancy has undertaken. In particular I’ll explore one of the biggest factors we’ve noted as being a hurdle to finding this goal alignment which is the way most organisations have been structured.

If you’re going to be in the area in November on the 8 – 9 and are interested in coming you can find out more here http://www.sharepointconference.asia/sea/2011/solutionpages/default.aspx.

MOSS World (parody of Gary Jule version of Mad World)

My colleague and a few other SharePoint gurus came up with this gold. I think it aptly sums up the feelings of most SharePoint Consultants that inherit projects. Enjoy.

http://www.cleverworkarounds.com/2011/03/18/moss-world/

Enumerating User Profile Properties

I recently had a need for a PowerShell script that would enumerate the fields on a user profile and thought I’d share it as well as point out some minor hurdles I encountered when I tried to run the script. Its important to note this script is for SharePoint 2010. There’s been some pretty major changes to the User Profile Service so I don’t expect this script to work with WSS 3.0 or MOSS 2007.

I recently discovered the magic that is Amazon S3 so you can download the script from https://s3.amazonaws.com/mymemorysucks.com/userprofilepropertiesenum/userprofilepropertiesenum.ps1 . To use it, its just a matter of specifying the “-siteaddress” parameter on the command line like so.

Hopefully the next screen you will see is the following. As you can see in the screenshot the script currently just outputs the ‘DisplayName’ and ‘Name’ of the user profile property.

If you encounter the following error instead then it possibly means that the account you’re running the command line under doesn’t have ENOUGH permissions to access the User Profile Service Application. I use the word ‘enough’ because like me the first time, you’re probably thinking that running under a farm administrator account should be enough but there’s some extra permissions you need to set for your farm administrator account.

First off, go to the ‘Manage Service Applications’ page under ‘Application Management’. You first need to select the ‘User Profile Service Application’ and then you’ll have access to the ’Permissions’ tab along the ribbon as shown in the screenshot below.

 You will need to make sure that the account you’re using is granted ‘Full Control’ under the ’Permissions’ tab as shown in the screenshot below.

Hopefully after granting the account ‘Full Control’ you should be able to execute the script.

Follow-up on ‘Can’t Find .NET Framework Class Methods’

Ok so after figuring out why the PowerShell ISE wasn’t loading the appropriate .NET Framework I added the registry key to enforce that .NET Framework v4.0 always loaded – bad idea. When you do this it means that the .NET Framework v4.0 will be loaded instead of the .NET Framework version you selected for that particular Visual Studio project. This results in a variable array of ‘could not be resolved because it has a higher version’, ‘type or namespace could not be found’, and ‘predefined type is defined in multiple assemblies in the global alias’ warnings and errors.

To get yourself back to a usable state, delete the registry keys out. Below are the commands that will let you do this from the commandline.

reg delete hklm\software\microsoft\.netframework /v OnlyUseLatestCLR
reg delete hklm\software\wow6432node\microsoft\.netframework /v OnlyUseLatestCLR