GAC and SharePoint

Posted on 8/5/2012 @ 12:23 AM in #SharePoint by | Feedback | 3741 views

GAC and SharePoint have had a funny love & hate relationship.

In 2007, SharePoint and GAC fell in love. GAC was about the only practical alternative to deploying custom code. Here is a dirty secret, based on completely unscientific and unfounded research, I can tell you that 99% of SharePoint code written, ended up in the GAC. Yes, I know GAC rhymes with hack, crack, smack, and even mac, but still it was the better alternative. You could write CAS policies and put your DLLs in the bin folder, but it was mighty inconvenient to both write, and maintain. Most of us never did it. There are still some SharePoint developers out there insisting on the bin approach – well, get over it; you’re not winning the fight. CAS is about as outdated as Samantha Fox anyway. It was hot at one point though. So all that code that ended up in the GAC caused lots and lots of headache. Clearly, Microsoft had to get us off the crack, uhh .. I mean the GAC.

In 2010, SharePoint and GAC’s relationship was being tested. Microsoft introduced something called “Sandbox” solutions. Sandbox solutions were something that allowed your code to think it was running from the GAC, when in reality it never touched anything on the disk. It was quite limiting in what it could do. The solution package itself however was written as if the DLL would end up the GAC. You still had the BIN option that almost no one used, except that sad and lonely old man in the basement with 7 cats around his computer. The issue however was that sandbox solutions were quite limiting in what they could do. Even though we tried to use them quite a bit, every now and then we found ourselves writing farm solutions. Some SharePoint developers in fact got so fed-up of sandbox solutions, they didn’t even bother to try.

In 2013, SharePoint has gotten a restraining order on custom code in GAC. They have introduced the app model. There is something you need to know about apps – they cannot run ANY code on the SharePoint server. They can run code on their own server, and cross-domain into SharePoint and use even SharePoint functionality. You just can’t author code in .NET and expect it to run in the GAC of the SharePoint server. Remember, the SharePoint server has been written with the philosophy to keep the SharePoint server safe and secure. The rest of the world can go to hell. It is now rightfully so, pushing us to author richer functionality using client side code. Unfortunately browsers are not quite as secure as operating systems, for one, they don’t provide the equivalent of process isolation within the browser, like apps will most definitely require. So, it puts a lot of onus on the app developer when writing secure apps that need to co-exist on a page that may have malicious apps on it. I’ll talk more about this later in this chapter and in the book. But, the SharePoint server itself, under all circumstances, when using the app model, will remain safe.

Whether or not this restraining order on custom code in GAC will remain, is yet to be seen! My feeling is, you cannot write-off farm solutions completely. But the reliance on them has greatly reduced in SharePoint 2013. Sandbox solutions on the other hand will see much lesser usage.

Sound off but keep it civil:

Older comments..

On 8/5/2012 11:25:54 AM Sandeep said ..
I guess with SP2013 pushing to use more client object model typo-of coding - we will see more crappy code from guys who still live in .net 2.0 world.

On 8/5/2012 5:26:10 PM Sahil Malik said ..
Oh Sandeep, you can expect a lot of crappy code in the coming years, just because it is JavaScript :)

On 8/7/2012 4:49:50 AM lucy said ..
I didn't expect to find a story of a love tech love affair here on this blog, it is not quite worthy of a mills and boon novel yet though :)