Note: This is an old article which may contain out-of-data content.

I was recently tasked with preventing Redgate’s SQL Complete plug-in from starting with the Visual Studio 2013 IDE. Initially I created a Group Policy Object (GPO) that removed the C:\Program Files(x86)\Devart\dbForge SQL Complete registry value from HKLM\Software\Microsoft\VisualStudio\12.0_Config\AutomationOptions\LookinFolders. This solution proved to be inadequate because although it ran when the user logged in, if that user had not used Visual Studio 2013 before, the registry key would not yet exist.

This turned into a bit of a puzzle. I needed to find out how the registry entries that made Visual Studio invoke the SQL Complete plugin were created and then find a way of inhibiting that mechanism. So I took a machine, deleted the users existing profile, fired up Sysinternals' Process Monitor (procmon.exe) and then started Visual Studio. As soon as Visual Studio had finished opening up I stopped Process Monitor capturing any more disk/registry IO and then exlcuded any process from it’s list of activities that wasn’t Visual Studio (devenv.exe). Finally, I searched the remaining entries logged in Process Monitor for the string dbForge SQL Complete. Now I had my target lined up. Right before creating the offending registry entry, I could see that Visual Studio 2013 read a file called devenv.pkgdef. I opened up this file in my favourite text editor and sure enough, I recognised the offending registry value.

Quickly, I considered my options. I had a string value in a file that I wanted to remove. I made a conscious decision that when upgrading our developer workstations, we would always start with a stock Windows image and then automate the deployment of software in a declarative fashion. In times gone by, with the legacy desktop deployment mechanism I’d inherited, I could have use Microsoft’s DISM to mount the WDS installation image used with the developer workstations, change the file and then import the new image into WDS. The change would roll out gradually as, over time, the developer workstations had their operating system cleanly installed.

Now I needed to actually change the file in-situ. So I wrote a very simple PowerShell script run by Group Policy at start-up.

$filePath="${env:ProgramFiles(x86)}\Microsoft Visual Studio 12.0\Common7\IDE\devenv.pkgdef"
if(Test-Path -Path $filePath){
    (Get-Content -Path $filePath) | %{$_ -replace ";+C:\\Program Files \(x86\)\\Devart\\dbForge SQL Complete;*","" } | Set-Content -Path $filePath
}

This script very simply tests whether or not the file exists and if it does, loads it into the pipleline with Get-Content. The next command in the pipeline simply runs a replace, using a regular expression to identify the string we want to remove. We simply replace the unwanted string with an empty string ("").