Getting .dll files out of the GAC

Periodically, you may find it necessary to get a copy of a .dll file out of the the GAC (C:\Windows\Assembly).  Navigating to this folder, you will notice it doesn’t “feel” like a normal windows folder since it isn’t.  You can drag .dll files onto this folder to install, but you can’t drag anything out of it.  This happens due to the shfusion.dll explorer extension dll that format the GAC folder.



So if you want access to these .dlls, you can unregister the shfusion.dll

regsvr32 /u C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\shfusion.dll

and you should see a message like this:



Once you have unregistered the .dll, you can browse to the assembly folder and you will notice that the underlying folder structure is exposed:


If you’re looking to grad several .dlls out of the GAC, you can use xcopy or some other tool to flatten out the folder structure.


Minor Detail, Major Impact in SSMS Script Wizard

After a few hours of pulling out what few stubs of hair I have remaining, I finally tracked down a rather perplexing problem relating to the Script Wizard feature of SQL Server Management Studio (SSMS).

My goal was to script out all of the stored procedures in a database in a fully re-runnable state, one SP per .sql file.  This would allow the procedures to be easily checked into source control, and tracked for changes that could be tied to our bug tracking system.  Having stored procedures and other database code in source control can be a tricky proposition because you need the right processes in place to ensure that any changes made to the source code are reflected in the database and migration path.  Conversely, it is equally important to ensure that any changes made directly in the database are accurately and promptly updated in source control.  Sound like a problem any of you have run into?  I know Ben Scheirman has, he posted a great summary of some database migration tools on his blog.

Although there are many good tools out there, my company is taking the “roll your own” approach because we have some specific requirements that no existing tool seems to encompass.  It has to handle SQL Server and Oracle, SPs, triggers, views, as well as ad-hoc DDL and DML changes.  It has been no picnic putting the processes and systems together, but I do think we have a good system in place.

One of the points of our approach is aided in the use of scripting tools, SSMS in particular for the SQL Server based database objects.  If you haven’t uncovered this handy tool (not very discoverable), try right-clicking on your database and following through Tasks to Generate Scripts:


I was scripting out a bunch of objects and trying to get home, so I thought I would try a little parallel processing to make the scripting go faster.  When choosing the settings in the SSMS “Generate Scripts” Wizard, I encountered the following differences between machine #1 and machine #2:

machine #1: Good


machine #2: Bad


Obviously, this smells like a software version difference, so I dug deep into the bowels of SQL Server’s Program Files folder (C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE) to find out that:

Machine #1: SqlWb.exe 2005.90.3054.0

Machine #2: SqlWb.exe 2005.90.2050.0

Unfortunately, Windows Update doesn’t pick up on this difference on 64bit machines!  So, unless you manually update your SQL tools, you’ll be stuck with inferior script generation options.  This is key because the options in the older of these 2 versions is not sufficient IMO.  Running Windows update on a 32bit machine yielded different results, and I was easily able to tell that I needed SQL Server SP2.  Obviously these are very specific situations, but I thought it was worth sharing

Bottom line is that you should have the following very helpful option in the Script Wizard in SSMS:

  • Script Drop

If you don’t check to make sure you’ve got a recent version of the tools.  The previous version only allows you to “Generate CREATE statements only” or “Generate DROP statements only” which is not nearly as useful as tacking the 2 together.  A useful page for quickly searching through SQL Server release details can be found here:

TeamCity 1 – CCNet 0

OK, so in my preliminary experiences I have to say that TeamCity is friggin awesome. It was amazing how simple it is to setup, and the features that come pre-installed are great. Effortless email notifications, build statistics including average Winner!build time and success rates, ability to monitor multiple projects in VSS — It’s all in there. What was unexpected is the ability to keep tabs on your development effort with intuitive source control history information. There is even a built-in web component that shows you a color-coded code-diff on the spot. Code reviews have never been easier!

I am going to recommend that my company take TeamCity to an official state of adoption as it clearly fills a need and is a very well put together tool. You can configure it to have multiple build servers in the event that you are building a lot of products, so this should scale well.

Thanks JetBrains!

Giving TeamCity another try…

Thanks to a comment from Eugene Petrenko, I decided TeamCity was worth another shot.  Everything I have heard has been positive, so I can’t let a little problem like not getting to my source control repository get in the way of continuous integration 🙂

Once again, I visited the TeamCity download site and read all of the fine print once again to figure out what I was missing.  All I can gather right now is that I am going to want to upgrade, but I am not sure yet what the killer feature is that will push me to fork out the credit card digits.

Install was smooth (as it was the first time), but this time I changed the services to run using a domain build account instead of the local system account.  There are 2 services that are installed with the default installation options, and I changed them both to run under this more privileged account:


I was definitely impressed with the ability to test the email settings. It was intuitive and gave me a better feel that things under the hood were put together in a manner consistent with the feedback I have heard about this tool.

Once I got the right user specified in the service it was able to connect to my VSS instance and I am now running my first test build.  Not bad considering it took me about 15 minutes and I couldn’t even tell you where the documentation is located!  I am warming up to this TeamCity stuff….


TeamCity Install Experience

Well, my hopes for a streamlined CruiseControl.NET were not realized in my first attempt at installing the continuous integration server software.  My CCNet lava lamp server died on my last week so I needed to spin up a replacement.  This seemed like a good opportunity.

Although the installation was slick and simple, I feel as though I was more of a user and less of an administrator when I started using it.  I guess that is the idea, but I want to know what is going on with my builds and know how to tweak stuff.  Having that comfort level with an existing toolset leaves me biased, but I digress.ragepost

The big disappointment was the fact that I wasn’t able to even select a VSS source control instance because it kept telling me the file didn’t exist?  Maybe it was because my machine was 64bit.  Maybe it is because VSS support is weak since they think nobody uses it any more.  Maybe it was because the user interface is pretty but not very bulletproof?  Whatever the reason, I am probably not going to be spending any more time on this tool in the immediate future.  Until I can find somebody to help me through a VSS example I’m not sure it will be time well spent…

TeamCity – A Better CCNet?

I have heard some buzz about a product from JetBrains called TeamCity.  Some very influential technologists such as Roy Osherove seem to like the capabilities, so it is definitely worth a look.  This looks like a good competitor to CruiseControl.NET, so I think I am going to give it a spin.  I’ll update the blog here with my findings as I go along.  The installation sounds to be smoother than CCNet (which can be a bit painful), and some of the features on the TeamCity website look terrific.

More to come, but if you have any experiences with TeamCity, please share them here in the comments.  My only concern at this point is that it looks like it may cater to more of a “Java” based crowd?  Sometimes tools with a Java history just don’t “feel” right to me and seem to take a long time to get the hang of for teams that are primarily involved with .NET.

The Automatic DBA

You know, there is nothing like a painfully long set of SQL scripts that need to be applied to multiple databases to get the creative juices flowing. As I stared at a list of 29 scripts that needed to be applied to at least 2 different databases (it could be much worse), I thought to myself, “There has to be a better way”. SQL Server Management Studio (SSMS) is a great tool, but I do hate how it makes you login to the database with each script you open. What is even worse, when I tried to open all 29 scripts at once it somehow spawned 7 different instances of SSMS in no apparent logical manner. Time to do some research.

I have used SQLCMD in the past, and I knew this would be the source of my enlightenment. SQLCMD is the 2005 command line successor to OSQL for SQL Server 2000. It allows you to execute SQL scripts at the command line. Nice.

Without any further banter, I’ll explain how you too can shave potential hours off of your DBA tasks. Note, this is a SQL Server specific tactic. I’m sure there is a way to do it in Oracle as well, but you’ll have to find some other chum to feed you that.

  1. Pick a folder to consolidate your .sql scripts (ie C:\AutoDBA)
  2. Create a text file called RunDBScripts.bat with the following contents
    DEL %1.%2.log
    FOR %%f in (*.sql) DO sqlcmd -S %1 -d %2 -i %%f >> %1.%2.log
  3. Create a second file called RunDBScripts.SERVER.DATABASE.bat (replacing SERVER and DATABASE with your specifics)
    RunDBScripts.bat SERVER DATABASE
  4. Execute the file created in step 3

That’s it, seriously. Try it out and you’ll be amazed and the time it can save you! You’ll also have a nice log file with the output results of the scripts.

The work is really done in the script created in step 2.  You loop through all files based on the *.sql wildcard.  For each file, it will issue the SQLCMD passing in the server, database, and file name.  The >> pipes the output to a log file.  Windows Authentication will be used by default, but you can also modify this to specify a username and password.

If anyone has any schnazzy additions to run from a UNC path or add a timestamp to the logfile name those would be worthwhile additions.

Thanks to these links for help in getting to this solution: