title: Working with Visual Studios C++ manifest files
body: <p>I have written some code that makes use of an open source library to do some of the heavy lifting. This work was done in linux, with unit tests and cmake to help with porting it to windows. There is a requirement to have it run on both platforms.</p>
  
  <p>I like Linux and I like cmake and I like that I can get visual studios files automatically generated. As it is now, on windows everything will compile and it will link and it will generate the test executables.</p>
  
  <p>However, to get to this point I had to fight with windows for several days, learning all about manifest files and redistributable packages.</p>
  
  <p>As far as my understanding goes:</p>
  
  <p>With VS 2005, Microsoft created Side By Side dlls. The motivation for this is that before, multiple applications would install different versions of the same dll, causing previously installed and working applications to crash (ie "Dll Hell"). Side by Side dlls fix this, as there is now a "manifest file" appended to each executable/dll that specifies which version should be executed.</p>
  
  <p>This is all well and good. Applications should no longer crash mysteriously. However...</p>
  
  <p>Microsoft seems to release a new set of system dlls with every release of Visual Studios. Also, as I mentioned earlier, I am a developer trying to link to a third party library. Often, these things come distributed as a "precompiled dll". Now, what happens when a precompiled dll compiled with one version of visual studios is linked to an application using another version of visual studios?</p>
  
  <p>From what I have read on the internet, bad stuff happens. Luckily, I never got that far - I kept running into the "MSVCR80.dll not found" problem when running the executable and thus began my foray into this whole manifest issue.</p>
  
  <p>I finally came to the conclusion that the only way to get this to work (besides statically linking everything) is that all third party libraries must be compiled using the same version of Visual Studios - ie don't use precompiled dlls - download the source, build a new dll and use that instead.</p>
  
  <p>Is this in fact true? Did I miss something?</p>
  
  <p>Furthermore, if this seems to be the case, then I can't help but think that Microsoft did this on purpose for nefarious reasons.</p>
  
  <p>Not only does it break all precompiled binaries making it unnecessarily difficult to use precompiled binaries, if you happen to work for a software company that makes use of third party proprietary libraries, then whenever they upgrade to the latest version of visual studios - your company must now do the same thing or the code will no longer run.</p>
  
  <p>As an aside, how does linux avoid this? Although I said I preferred developing on it and I understand the mechanics of linking, I haven't maintained any application long enough to run into this sort of low level shared libraries versioning problem.</p>
  
  <p>Finally, to sum up: Is it possible to use precompiled binaries with this new manifest scheme? If it is, what was my mistake? If it isn't, does Microsoft honestly think this makes application development easier?</p>
  
  <p>Update - A more concise question: <strong>How does Linux avoid the use of Manifest files?</strong></p>