Side-by-side error if compiled under Windows 7 but not XP??

[steveq]

Hey All,

I have written a 32 bit MFC Dialog based program. It is written using Visual Studio 2005 v8.0.50727.867.

If I compile this software using on an 32bit XP based PC, then everything is fine and user can run the software with no worries.
If however I compile it using my Windows 7 64bit PC, using the exact same compiler, then it will run on the PC that compiled it, but I get side by side errors on any other machine that tries to run it (well at least those I have asked to test it)?

Does anyone have any ideas on what may cause this please?

It's doing my head in!

Thanks heaps in advance for your help,

Steve Q.

[VictorN]

Do you use the same compiler/linker options on Windows 7 64bit PC as you used on 32bit XP based PC?

[steveq]

Hey VictorN,

Thanks for your help.

Yep, they are. I copied the project folder from my XP PC to my Win 7 PC, loaded the .sln and did a re-build.
I just went through every option int the project properties in the solution and compare them with both machines. They are identical.

Steve Q.

[John E]

If you can view the executable modules without damaging them, search for the word "Manifest". You'll probably find that when you compile on the XP machine it's specifying some manifest that's later than 867 (probably 4053) which happens to be on the other person's machine. But when you build it on Windows 7, an even later manifest gets specified (which isn't on the other person's machine). By default, your compiler will specify the latest version 8 runtime that it finds on the build machine - but....

If that's the case I can show you how to specify an exact manifest in your build (although I'm not at the right PC just at the moment). It's just a matter of adding some lines to a header file.

[steveq]

Hi John E,

Thanks for your reply. It sounds like this may be the case. I can't check it until Monday, if you wouldn't mind posting your header fix in the mean time, I'd greatly appreciate it.

Many thanks,

Steve Q

[John E]

No problem. You need to create a special header file which will be "force indluded" in your project(s). The header file can be called anything you like and can be located anywhere that's convenient. On my system, the file is:-F:\+GTK-SOURCES\gnu-win32\include\targetsxs.h

The contents look like this:-

#ifndef _TARGETSXS_H_
#define _TARGETSXS_H_

#pragma warning( disable : 4996 )

#ifndef __midl
#define _SXS_ASSEMBLY_VERSION "8.0.50727.4053"
#define _CRT_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
#define _MFC_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
#define _ATL_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION

#ifdef __cplusplus
extern "C" {
#endif
__declspec(selectany) int _forceCRTManifest;
__declspec(selectany) int _forceMFCManifest;
__declspec(selectany) int _forceAtlDllManifest;
__declspec(selectany) int _forceCRTManifestRTM;
__declspec(selectany) int _forceMFCManifestRTM;
__declspec(selectany) int _forceAtlDllManifestRTM;
#ifdef __cplusplus
}
#endif
#endif

#endif /*_TARGETSXS_H_*/

After you create the header file you'll need to ensure that every module in your project includes it. Strictly speaking, you only need to do this for executable modules (DLLs and EXEs). It isn't necessary for any static libs you build.

You can force it to get included by opening the Properties window for each project in your solution, then select Configuration Properties->C/C++->Command Line. Add this line to the box that's labelled Additional options:

/FIF:\+GTK-SOURCES\gnu-win32\include\targetsxs.h

Obviously, adapt that to suit your own path.

Note that the header file only specifies the minimum specification for your app's 'C' runtime. If your end user's system has a more recent version, the most recent version applicable will get used. The general idea is to specify a value that's low enough to be available on everyone's system.

[steveq]

Hey John E,

Thanks heaps for your reply. I'll give this a go first thing Monday.

Thanks again for your help, I really appreciate it.

Kind regards,

Steve Q.

[steveq]

Hey John E,

I've used a hex editor, and loaded the .exes from both a compiles (one on my XP PC and one on my Win 7 PC). I did a search and found the manifests.

Here is the manifest from an .exe compiled on my XP PC:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

and this from my Win 7 compile .exe:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.6195" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.6195" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

In addition to this, any .exe running on a Vista PC or greater has this embedded into the manifest:

<trustInfo>
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel level="requireAdministrator"></requestedExecutionLevel>
    </requestedPrivileges>
  </security>
</trustInfo>

Using your header file, I'm not sure how to change it so that my compiles run on both OSs without getting side-by-side errors?

Would you mind giving me a little more advice please?

Thanks heaps again for your help.

Steve Q.

[John E]

Hi Steve. In the file targetsxs.h change the value and see if it affects either compile. So for example change this line:-

#define _SXS_ASSEMBLY_VERSION "8.0.50727.4053"

and make it say this:-

#define _SXS_ASSEMBLY_VERSION "8.0.50727.867"

Now when you rebuild, does it affect the embedded manifests for either build?

[steveq]

Hey John,

Here are the manifests, extracted from the .exes after your suggested changes:

From code compile on XP:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.867" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.867" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

From code compile on Win 7:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.867" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.867" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.6195" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

It seems to still include the old manifest info, which I'm guessing isn't a good thing

CYA

Steve Q.

[John E]

Hi Steve. My best guess is that you're probably linking to some 3rd party module that needs the other manifest version. I think I once got that problem when I was using libboost. You need to make sure that you're building all non-Microsoft code yourself.

In fact, you should really be doing that anyway. It's not a good idea to mix your modules with modules built by somebody else. It used to work (just about) in the days of VC++6 - but ever since manifests came along, it's been a recipe for disaster...

[steveq]

Hey John,

I do link with 3rd party libraries. The trouble is some of them are commercial libraries I am licensing, so I don't have access to the source code.

If it is these libraries causing the problem, I guess I haven't got too many options, other than to compile it on the XP PC?

Steve

[steveq]

Hey John,

Is this problem occurring because my installer doesn't install the correct VC++ Redistributables?

If I compile on the Win 7 PC, should I use different redistrbutables to the ones for the XP PC?

If so, how do I know which ones to use and where do I find them?

Sorry for the many questions, but I haven't fully got my head around why this is happening.

Kind regards,

Steve Q.

[John E]

My installer is InstallShield (2008 version) and AFAIK it can only redistribute one version of the redistributables. Newer versions might be more flexible.

Probably the best solution for you is to install 8.0.50727.6195 on both systems and specify that as the minimum version (which you'll then distribute).

[steveq]

I'm using Inno Setup for my installer.

Actually, I'm not concerned about my XP PC. In fact I want to code and compile on my Win 7 box, it's faster/newer etc. So it is frustrating that it is this box that is giving me the side-by-side errors.

Is the better solution to take the XP PC out of the equation altogether and use redistributables for 6195, or won't that work because I am coding using version 867?

I'm happy to upgrade to 6195 if I need to, but where do I get it?

Thanks again John,

Steve