side-by-side

We have an app compiled using MSVC 2K5, SP1 (version 762 msvcrt80) All is well, right up until somebody installs on the same machine .Net3.0SP1, and along with it msvcrt80 version 1433 is installed and a policy to automatically upgrade. Now we have random crashes all over the place and unhappy customers. I understand we can adjust our manifest files to force the usage of a specific version, but I've only found the really ugly way of copying detail that is auto generated and modifying it by hand. This is especially unpleasant with a large number of apps to fix Can we instead get rid of the

I have a Windows, C++ software project (built with Visual Studio 2005, SP1) that has the following (simplified) file layout: {App. Root Directory} |-- bin | |-- Microsoft.VC80.CRT | +-- Microsoft.VC80.MFC +-- utils There are various executables that live in both the bin and utils directories. Each of these executables rely on the side-by-side assembly (C++ run-time DLLs) that we store in bin , but we have segregated them into these separate folders for various reasons (e.g., the exes in the utils folder are supplemental tools to our primary application, and are run infrequently). As a direct

We include a 3rd Party lib+DLL that recently causes a lot of trouble on installations. Using dependencywalker , we found that the dll itself refers to two different Versions of MSVCR80.DLL: Version 8.0.50727.4053 and Version 8.0.50727.42 alt text http://img101.imageshack.us/img101/1734/dependencywalk2.jpg In MOST cases installation makes no problems, even if we distribute none of both versions. But in a number of cases our installation just does not start. We then find messages in the windows system event log from the SideBySide manger: "Version of DLL does not match". In most cases again this

We are adapting our client side relatively complicated application (ActiveX / .net / Delphi / C++ / COM ) to use SxS to achieve non admin deployment and isolation from older versions of our product. We were able to achieve this goal for almost all our in proc components such as our .net ui, Delphi ui, and the COM servers we use in proc by composing a manifest file which described all the libraries used by our process, with no registration on the client of any of the components (almost). And here comes the almost part: At the moment, our application invokes (from it's c++ portion) an out of

The problem I'm facing is essentially described here , that is: I have a DLL that is using a 3rd party in-process COM component dll. I want to use registration free COM with that in-process component. I want to embed and use a manfest into this DLL (not into the main EXE) so that I can use the 3rd party component in a reg free way. The Interface I use from the component is activated through a call to CoCreateInstance . The 3rd party COM component hasn't got any further (COM) dependencies and doesn't rely on or need isolation. I see that simply embedding a manifest into my DLL doesn't work, as