Ode to Trace

I have a project I have been working on wrapping up. We have gotten tons of user feedback, which thrills me to know that my tool will get used. On my list of items needing attention, however, one item loomed largely. I ignored the item for as long as I could. I cleared up everything else, and I had no choice but to stare my arch-nemesis directly in the face: performance. "Yikes", I murmured to myself, trembling. There were so many controls on my page, there were so many domain object getting loaded, the task of finding the offending performance hog seemed to be a huge undertaking. I fretted, I greived, and then I pulled myself out of my self-pity mode and came up with a plan.

From the good old days of .net Beta, when stepping through code without running into environment hang ups was only a distant fantasy, I remember my friend, Trace. So I set Trace=True in my aspx file, and went to town adding Trace.Write lines to my code. I began to get excited as I awaited my first trace output. I could envision the lines I would see, tellling me the expanded time that each snippet of my code began and ended execution. Lo and behold, when I saw the first Trace output, my troubles were over. I saw the offending control was something leftover from pre-version one of my form. This slow control was loading up over 50 times. I slashed the control from my code, and my page now loads about 60 times faster. Hooray! I have defeated the performance tyrant. So, in appreciation of Trace's beautiful output, I have decided to write an Ode...

Ode to Trace

Before I used you, the performance of my page was a disgrace
Rather than troubleshoot, I would have preferred an eye full of mace
As my hour of deployment drew near, I was in a time-race
When, in a flash of brillance (okay, that may be arguable) I turned on Trace.

Seriously, maybe everyone else in the developement community is using Trace all of the time. I had forgotten about it, and I am SO GLAD I remembered to use it today :)

To GAC or not to GAC, that is the question...

In a project with which I am involved, we have a .dll that holds common web controls. This .dll is shared by multiple web applications, however they all reside on the same server. Originally, when this .dll was shared by two web applications, we had both web projects in one solution and used project references. Then, when we deploy, we can just XCOPY the web applications’ files and bin folder. Viola.

Now we have some SharePoint sites that we want to share the common web controls. We can follow our previous architecture, and add the team sites to our solution and use project references. We can also create a new solution for the team sites, but add the existing controls project from SourceSafe to our new solution. In the latter scenario, we would have one master copy of the controls project in source safe.

However, I am not thrilled with the prospect of using XCOPY to create another bunch of instances of the controls .dll on the web server. I see an advantage that when one of our web applications goes live, we won’t have to worry about future changes to the controls .dll affecting our live web application. Having multiple copies of the same .dll on the same web server seems like a worse idea when I consider what we have to do through to address a bug fix or try to upgrade something, especially if we end up with different versions of the controls .dll in each web application’s bin folder.

I was noodling this issue and thought, “Hey, why not use the GAC? The end of .dll hell!”. All of the web applications will be on the same web server, and the GAC was created for just that purpose, right? I can still opt to have multiple versions of the controls .dll in the GAC if I so choose, or I can keep one version and have only one place to maintain it.

I have used the GAC in the past when dealing with a WinForms application, and after the initial set up, things went swell. Our team did create a utility to rebuild our GAC .dlls out of SourceSafe on demand, and we also agreed on a local structure where we published our debug .dlls so we could share each other’s projects without any headaches. We completely abandoned project references all together. There was some overhead, but I never had to restart VisualStudio because "a reference is being used by another process."

In my current situation, I am a little hesitant to use the GAC because I know that if one of the web applications gets moved to another web server, things will break. I have also read some articles where people have had trouble with strong naming and signing their assemblies. I know that changing course now will also require overhead to set it up so my teammates and I are able to work on the same projects without stepping on each other’s toes, and without requiring a manual copy of new versions of .dlls from SourceSafe to our local GACs. Putting our assemblies in the GAC will also make it difficult for another member of my company to quickly get my solution from SourceSafe and be able to compile and run my code (like our graphic designer). They would have to run an install or manually register the required .dlls to the GAC before their code would compile.

I am also still not crazy about the many versions of one .dll on the same web server, just asking to be out of synch with each other. And how will we manage which version is being used on each web application when we will keep one copy in SourceSafe?

I am undecided what to do. Do you have any experience, positive or negative, with using the GAC for web deployments? What would you do in this situation?