title: Should I be changing the ProductCode in my .vdproj file on each build?
body: <p>At the moment our build automatically updates the version number in the deployment project file (VS2008) and changes the ProductCode and the PackageCode.  </p>
  
  <p>We don't use much MSI functionality at all, it's more of a packaging method and a way to run custom actions which do some activity depending upon a definition file which is shipped as content within the MSI.</p>
  
  <p>So, in terms of MSI features all of our builds look the same, they will just be pulling in newer versions of the other projects outputs rather than any changes within the deployment project, and thus we don't change the structure of the MSI at all.</p>
  
  <p>So, am I safe to leave the ProductCode stable?</p>
  
  <p>The reason I would like to do this is that I was uninstalling via product code, until I've just found that this is a silly way given that our build changes them all the time!</p>
  
  <p>Or, is there any way we can uninstall using the UpgradeCode which is a never changed value?</p>
  
  <p>FEEDBACK:</p>
  
  <p>I dug a little more on this one and changed the way that we do an uninstall in our deployment system that deploys into our sizable test estate.  Rather than extract the ProductCode out of the MSI and use that in an MSI /X command I now extract the UpgradeCode from the MSI.  As part of the uninstall I deliver and remotely execute (via PSEXEC) a small vbs script that finds the related products by</p>
  
  <pre><code>set oWI = CreateObject("WindowsInstaller.Installer")
  set related - oWI.RelatedProducts(wscript.arguments(0))  
  if related.Count == 1 then
      uninstallString = "msiexec /X " &amp; related.Item(0) &amp; " /qn"
      set oShell = CreateObject("WScript.Shell")
      oShell.Run uninstallString, 1, True
  end if
  </code></pre>
  
  <p>ok, probably not the worlds best vbs - but it works by passing the UpgradeCode as the first parameter into the script.  There are some more lines for logging etc so we can tell what happened in the audit trail.</p>
  
  <p>Bit more long winded that just calling msiexec directly through psexec but I was delivering the msi and a settings file already so sending down a little script isn't really an issue.</p>
  
  <p>This may help somebody else - who knows. </p>