I was raving about SSIS yesterday and ran in to something that I consider a HUGE oversight.  I think the "script task" is a really neat feature that has been in there since the DTS days and that they have come a long way in updating it to use today's technologies.  The problem, however, is that they got so far and decided to stop right there.  For example, the only language you can use in the script task is VB.NET, even though they have a drop-down to select your desired language (vb is the only option).  It looks like they were considering adding more but for one reason or another, stopped right there.  Oh boy.

As if that wasn't enough, they tout how you can reference your own assemblies for execution which made me all excited... until I learned the limitation.  You *must* copy the assembly to the GAC and/or the Microsoft.NET folder for whatever version of .NET (2.0 only) you are using as the machine default.  In other words, "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727".  They say this requirement is only on the dev machine and that you can get by copying only to the GAC on the production machine... however, that has a caveat.  If you select to have your script precompiled, you must now copy the referenced assembly to the framework folder in addition to (or instead of, not 100% sure on this) the GAC.

So... trying to be creative, I am thinking of sneaky ways around that.  Having not tried it yet, but assuming it is possible, I wonder about the use of reflection to do my tasks.  Obviously that would be a painful way to do it if I have a lot of things I need to do in the referenced assembly, but if I only have a couple of tasks and don't want to copy to the GAC and/or the framework folder, this would seem the best way to get around that silly little oversight.  Seeing as I don't currently have anything I want to test that on, I don't even want to try yet... but just a thought.