Adam wrote a great post on Best Practices. With a myriad of "Best Practices" and even conferences about them floating around, it's good to refrain from that kool-aid and think for yourself sometimes. Because using the old noggin' is truly a Best Practice.

Read the article here: http://www.sharepointsecurity.com/blog/sharepoint/when-best-practices-aren’t-best-practices/

We released NewsGator Social Sites 2.5 yesterday, along with our flagship server NewsGator Enterprise, the social computing platform for the enterprise. There's some very cool things to talk about in that release, but there's a few controversial (if you're super-geeky, that is) things that we did in this release.

One thing we did is move all our assemblies to the GAC. If you read my SharePoint book (Inside Windows SharePoint Services, with Ted Pattison) you'll know this is heresy. Heresy, I tell you! NEVER, EVER, EVER deploy to the Gac for Web Part code is what I told you, time and time again. Full trust is bad!! Evil, I say! Especially for ISVs-- there's no excuse for an ISV to just GAC deploy "because it's easier, and I don't have to worry about CAS".

But alas, there are a few reasons to GAC. For one, you need to GAC your feature receivers... so we've always had some code in the GAC. But to work with Web Parts programmatically (adding them to the page, manipulating them) the executing code needs access to the Web Part assembly. So for receivers to work with Web Parts, the Web Parts need to be GAC'd. Otherwise, you might need to set up a Web Service that your receiver can call that can then work with the Web Parts-- we did this in the last release, and it wasn't an approach that was bulletproof across all of our customer installations. This approach would be fine for internal development where you control the environment and can test against it, but as an ISV there are too many unknown factors (including authentication) that are involved. So we GAC'd the Web Parts, which does make me feel a bit dirty, but our code is more reliable than an alternate approach, and because of that our business stakeholders and customers are appreciative. Did I bypass CAS altogether though? Not entirely-- a customer COULD choose to run in a pure bin-deployed scenario, although they wouldn't get all of the functionality.

So, do I still recommend using CAS and bin deployments? Absolutely! It is the most reliable deployment mechanism. We develop using bin-deployments, it's the only reasonable way to code and test in real-time with SharePoint. You should also only cross the threshold to GAC-deployment when you absolutely need to, and have a good reason to. For us, that threshold came during this release. I would not have recommended GAC deployment of Web Parts other than for the sole reason of feature receivers manipulating and adding the Web Parts.

There's some other cool things to talk about that we learned in this release, including taking a dependency on the 3.5 framework with service pack 1 and using the newer AJAX library, along with some WCF technology. We're also using the SharePoint AJAX Toolkit, which we invested heavily in and you can get for free at www.codeplex.com/sharepointajax. I've also written a book largely based on our architecture, which I'm sure you've heard me mention many times already-- but be sure to pick up Developing Service Oriented AJAX Applications on the Microsoft Platform to get a glimpse at the technologies and architecture we use.

About NewsGator Social Sites

NewsGator Social Sites is one of the things I build at NewsGator Technologies, along with a team of some incredibly talented folks. It's the social computing platform for the enterprise, built on NewsGator Enterprise Server and Microsoft Office SharePoint Server 2007, with lots of cool things like communities, discussions, feeds and subscriptions, tagging, social bookmarking, and a slick user interface built from the ground up using the Microsoft AJAX Library. It's the coolest application you've ever seen on the SharePoint platform... check it out at http://www.newsgator.com/business/socialsites.