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.


8 thoughts on “The Infragistics SharePoint Demo Is Funny, But Depressing”

  1. While I agree with many of your observations, be careful what you wish for using SPWebConfigModification. I have encountered issues using that class to update web.configs in farms where some web applications run .NET 3.5. Evidently, the class has issues parsing those configs and will fail since the methods often iterate through all configs in the farm. Not ideal, but can cause headaches and ultimately….you guessed it….manual web.config updates.

  2. LOL i feel your pain.
    Same shit when you want to install FAST ESP SharePoint 2007 connector.
    I mean you pay close to a million in licenses, but the lazy bastards dont even pack it up in a solution for you :-O
    (manual web.config entries, manual copy of web service to ISAPI etc.)

    SPWebConfigModification has issues, but they are pretty well documented in blogs.

  3. @Adam – Appreciate the candid feedback. Just to be clear, what you looked at was a reference implementation on building custom webparts using NetAdvantage. We’re not selling a solution to import controls into SharePoint, we’re showing developers who were already going the route of building a custom WebPart guidance on using the NetAdvantage tools inside of that webpart.

    The thinking was that the consumer would fall into 1 of 2 categories. Either they’re just getting the hang of SharePoint and would find it useful to have a step by step guide to installing a custom built webpart into SharePoint, or they’re of your caliber, where they proably don’t need the guide in the first place and just want to see what the code looked like inside of the WebPart.

    It sounds like there are some best practices around deploying WebParts that you know intimately, and we could probably incorporate into this (already long as you mentioned) document.

    We are also working on an out of the box SharePoint WebPart that you can simply include in your Parts library, and start using immediately (no wrapping required). We’re certianly going to look to improve the ‘install’ experience for that. Feel free to email me with any additional feedback you have!

    Anthony Lombardo

  4. @Tony:

    My feedback doesn’t really come any other way, and thank you for responding to my post! I would like to hash this out… (this is gonna be long).

    I don’t believe I obliquely implied that the Pomegranate bundle is an abundantly functional solution. However, I do think that IT IS an Infragistics reference application (i.e. from my perspective, I consider it endorsed by your organization, and I don’t know if you can say that’s wrong which I will get to in a sec), and if you are going to distribute it, you must promote full-fidelity coding (currently covered) and deployment (currently shitty) best practices. Otherwise, we stumble upon two core problems.

    Firstly, it looks hacky at best from the Infragistics end becomes everything comes off as a work-around, not an elegant, considered, and most importantly, astutely packaged solution. And while I can appreciate your argument faintly, the ad-hoc deployment scenario of WebParts is contradictory to deployment best practices, and honestly doing new ups doesn’t really give any insight into black-boxed, or rather, mystifying SharePoint processes. It’s, well…… it’s just cheap honestly and makes things more bewildering. I wasn’t like befuddled reading that document, but I am pretty good at this SharePoint thing and that was waaaayyyyy to much going on.

    Now I do have an argument prepared to substantiate this first point, which will additionally trickle down in terms of relevancy to my future points so please keep it in mind. On your site, the page referenced in the post, it states Infragistics provides developers using its products with *architectural guidance* for SharePoint portal development, as shown by our reference application (code-named Pomegranate).

    Now, architectural guidance implies deployment man! And it’s not called SharePoint Portal Server anymore too (ok, that was a low blow, my bad. I take that back).

    Secondly, even if it WAS a freshy developer, and they are getting their feet wet with WebPart development, leveraging Pomegranate as an…I don’t know like instructional document for development priming is going to educate malformed deployment practices! We don’t want that! I don’t want it, and I *know* Infragistics doesn’t want it, because then its support city for you guys (perhaps that is good? I dunno.).

    Let’s assume a rudimentary example scenario. A developer takes your guide to heart, and starts doing things that way since Infragistics, IMHO again, is a reputable company (like I said, I drink the kool-aid intermittently). Now, let’s presuppose a project stakeholder wants to do a retraction of a solution across a 50 server farm. That is undoubtedly a week long task to get that code outta there, not incorporating baseline, associated QA practices. That’s no good IMHO. I would be frickin pisssssssssedddddd!!!!!!

    Furthermore, doing something like third-party integration pieces as a primer for WebPart development comes off at the very least as appallingly aggressive. I would argue that most people would instead benefit from more unsophisticated composite control development before moving into something like complex charting solution integration.

    I gotta jet into work otherwise I would go on, but my advice is to actually get community people to develop such applications, it’s what I have seen most third parties doing (admittedly, such an undertaking is more $ then internal so becomes an economical decision). Then you can build case studies, etc. Get their field experience. Make easily deployable solutions so we can take into the suits that have the $ and impressive the shit outta em. If you want to keep doing it this way, PROVIDE ME TWO OPTIONS so I can actually use the thing.

    Again, I hope you don’t take this as bashing Infragistics as a COMPANY. I’m not. I am just pointing out that Pomegranate is one of the most exciting applications to go through from a code perspective, but EASILY the most crude and unsophisticated from a deployment standpoint. I just want someone to fix the aforementioned points because it looks neat and I still can’t get the fucking thing to work. Seriously, I can’t.

  5. @Dan:

    True, but you could also just stream in the web.config and use the Xml* classes to change the values.


    Haven’t tried the FAST stuff. Sound like that’s a good thing.

  6. I would have to agree with Adam on this. If you are going to distribute a sample application, it should be of the same quality as the rest of your products.

    Otherwise, it just comes off as lazy.

  7. I had tried to deploy this same solution, to no avail for the Marine corp MOSS external site. Our staging farm was down for a while since the architect didn’t copy and paste the Pomegranate config sections right.

    Very frustrating since we were just looking for a quick BI demo for our commander.

Leave a Reply

Your email address will not be published. Required fields are marked *