The Infragistics SharePoint Demo Is Funny, But Depressing

So, I recently got solicited for feedback and comment from Infragistics because I was for some time heavily into using their control set. Regardless of some of the unwieldy operations to sustain the nifty functions, I think they are neat and a lot of the times clients have a pre-existing license agreements so I just use ’em.

Infragistics appears to be making a tactical move into the SharePoint space; therefore curiosity arose in me to go test out what they had recently released. Regrettably, in conventional let’s hurry up and provide a SharePoint solution format which can be vendor criterion, Infragistics wins for the most cumbersome deployment process feasible. Well, maybe not that bad, but it’s pretty damn close.  The WORST part about this situation is the code behind for the solution is fantastic (not being sarcastic, it really is pretty good!), and it’s a bummer that they dropped the ball on everything BUT managed code development. Kudos to the developer on the code though.

So, here is the page of concern:

And here is a link to the configuration guide:

Alrighty, let’s get started. Once the PDF is open, scroll down to page 10.

1) Get to step one. WTF?!?! Cmon Infragistics, you want *manual* web.config modifications? LAME. That can take forever to complete on a staging farm, and is subject to substantial human error. I mean come on; the SPWebConfigModification class exists for a reason and there are all sorts of receivers.
– Moving right along, reference point 1 for the custom configuration sections instances. Are people really supposed to copy and paste that shit?
– Manual safe control entries. HA! I like that one. No note needed on that sweetness.
– Manual CAS adjustments make me want to cry. Seriously, as someone that takes code security critically, I want to shove a pen in my eye to damn the tears up like a Bic beaver.
– Again, the session state stuff? See above.
– Could go on with the rest of em, but you get the point…
2) Creating folders at the root of the site can be automated, that’s why we have SPWebApplication, etc. objects. You can even do your permission requirements as well.
3) You want people to copy things into the 12 hive. Is there a point to that? I mean, it is breaking the fundamental principle of SharePoint Solution architecture. That’s one of the reasons WE HAVE SOLUTIONS.
4) Uploading a master page can be automated since the Master Page Gallery upload is the same as any document library. Sigh.
5) As opposed to packing .webpart or .dwp files, you are asking people to new them up out of the gallery. The extent of that laziness is immeasurable in words.
6) Well, I guess back to the 12 hive thing, again, manual Theme deployment. Word.
7) After I saw SPD, I threw up a little bit in my mouth and stopped reading.

I am not bagging on the controls, but FFS, if you are going to build a sample solution, MAKE IT EASY AND QUICK TO DEPLOY. I don’t want to spend a fucking afternoon trying to get some pie charts and random data grids into a demo site.