title: How can I avoid Authenticode signing third-party libraries in a .NET project in an automated build?
body: <p>We recently purchased a code-signing certificate and I've been incorporating the code signing step into our automated builds.</p>
  
  <p>Our build script has to build both VB6 and .NET projects, so we currently have a batch file that builds everything. For the .NET projects, our build script calls MSBUILD, passing in a solution file to build. The projects in these solutions have some third-party dependencies, and these files all have the <strong>Copy Local</strong> option turned on in <em>References</em>, since they are needed to run the application. In addition, some projects use COM Interop, and so they have automatically-generated Interop assemblies (such as <strong>Interop.MSXML2.dll</strong>) that are also copied to the to the output folder during a build.</p>
  
  <p>I'm trying to figure out an easy to only code sign the files that are compiled during the build (i.e. <em>our</em> assemblies), and ignore third-party libraries and Interop assemblies, without resorting to having to call <strong>signtool.exe</strong> on each assembly separately.</p>
  
  <p>Currently, I worked around this by doing the following in the build script:</p>
  
  <ul>
  <li>Make sure the build cleans all previously-built files</li>
  <li>Compile the .NET solution with MSBUILD, specifying an output folder for the build</li>
  <li>Recursively sign all of the binaries (EXE's, DLL's, OCX's) in the output folder with <strong>signtool.exe</strong>. This signs everything, including the third-party libraries and auto-generated Interop assemblies</li>
  <li>My third-party dependencies are in a separate <code>lib</code> folder, so I copy all of the files from <code>lib</code> back into the build output folder, overwriting the copies that the build copied there. This way these files are no longer signed, but our assemblies still are</li>
  </ul>
  
  <p>My question is, is there a better way to do this? The only other alternative I can think of is to call <strong>signtool.exe</strong> individually on each assembly that needs signing, but this could be a pain because of the number of projects and the amount of change occurring in them (assemblies get renamed, move, get deleted as the projects evolve). Plus, I don't want to have to guess whether a particular assembly got signed or not, so looping through the files and signing them in bulk makes the most sense to me.</p>
  
  <p>At the same time, however, it doesn't seem right (morally, legally, or otherwise) to arbitrarily sign files that we didn't create with our code-signing certificate.</p>
  
  <p>Or maybe I'm going about this the wrong way altogether?</p>