I am upgrading an unmanaged C++ application to use the XP/Vista style common controls by adding a manifest. According to MSDN's page on application manifests, you are required to specify the name and version in the manifest, and optionally the description:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.2.3.4"
processorArchitecture="*"
name="CompanyName.ApplicationName"
type="win32"
/>
<description>Application's description here</description>
</assembly>
How are these details used? There is a mention about backward compatibility being implied by having the same major and minor versions for assemblies, but this does not seem to apply to applications. I also haven't been able to see the name, version, or description specified by the manifest in the application's properties on Windows XP.
What effect does changing these have? Is it worthwhile to keep the version up-to-date?
I'd say its worth keeping them up to date. If for no other reason than you don't know what future tools might come along that make use of them. I'm not aware of any current uses for the assembly name, version, and so on specified in a native application's manifest. To populate the properties page on XP, you need to create a VERSIONINFO section in your resources.
For common controls to use the XP/Vista themes in a C++ application which does not link the manifest in (such as Visual C++ 6 apps), the following is a template you can use:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Program Name"
type="win32"
/>
<description>Description of Program</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
Related
I'm just trying to build 64 bit version of an existing program (EXE with some dependent DLLs). Since it was very easy under Linux (just recompile it), I was optimistic it could be somehow similar under Windows. Unfortunately it is not...
After starting my newly compiled EXE, I get an error message
The application has failed to start because its side-by-side configuration is incorrect...
Tracking down the reason for it I made a SxS trace which shows following error message:
ERROR: Two assemblies have the same assembly name with different version.
Assembly 1: C:\Windows\WinSxS\manifests\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac.manifest.
Assembly 2: INFO: Manifest found at C:\Windows\WinSxS\manifests\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac.manifest..
So..what does this mean? And how can I resolve the problem? Installing the VS2010-redistributable package for x64 was not the trick, here installer complains about a newer version that is already installed...
The Manifest file mentions some X86...is this the reason? If yes: how can I find out on which X(& DLLs it still depends?
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="0.64.1.0" processorArchitecture="x86" name="Controls" type="win32"> </assemblyIdentity>
<description>wxWindows application</description>
<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.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="amd64" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Your application manifest specifies x86 architecture and has two entries for comctl32.
You should specify x86 for your 32 bit build, and amd64 for your 64 bit build. And you should list comctl32 exactly once. For the dependent assembly architecture you can specify * if you wish, but personally I prefer to be explicit.
I need to use the TaskDialog provided by the Windows API Code Pack in my Outlook Add-In.
I recived this error:
TaskDialog feature needs to load version 6 of comctl32.dll
but a different version is current loaded in memory.
I followed the steps provided in the MSDN. I added a resource file and inserted the provided code:
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="MyAssemblyName.vsto"/>
<!--Enable themes for Windows common controls and dialogs (Windows XP and later)-->
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</asmv1:assembly>
I know I have to select the manifest file in the project properties, but sadly, the controls to select the manifest are disabled:
I need a solution, so I can use the TaskDialog.
I'm trying to get the simplest Registration Free COM project to work in 64bit Windows7!
The COM component is also the simplest vb.NET DLL that works fine from the VB6 EXE when its registered.
Can anyone suggest why the manifests are not working please?
I have already tried to update any VB6 internal Manifest with mt.exe but the general error indicates that there is no internal manifest in Project2.exe
The VB6 program (Project2.exe) manifest is....
<assemblyIdentity name="Project2.exe" version="1.0.0.0" type="win32" processorArchitecture="x86"/>
<dependency>
<dependentAssembly>
<assemblyIdentity name="ClassLibrary1" version="1.0.0.0" type="win32"/>
</dependentAssembly>
</dependency>
</assembly>
And the DLL (ClassLibrary1.dll) manifest is.....
<assemblyIdentity name="ClassLibrary1" version="1.0.0.0" type="win32"/>
<clrClass
name="ClassLibrary1.Class1"
clsid="{D9531C2A-3822-4222-8D45-BC507FCDF5F3}"
progid="ClassLibrary1.Class1"
threadingModel="Both"/>
<file name="ClassLibrary1.tlb">
<typelib
tlbid="{DA8A00C1-1E14-4295-AEDE-F8F23DD8E43D}"
version="1.0"
helpdir=""
flags="hasdiskimage"/>
</file>
</assembly>
The manifests are correct, assuming that the Ids are correct. So your problem is something else. What error message do you get?
I employ RegFree Com succesfully and it has saved me countless headaches once you have the manifests right. I do not embed them. I use Side-by-Side Manifest Maker from Maze software for this, they are very helpful, very much worth the investment. I pasted the application manifest and the manifest of one of the dll's to give you a working example.
Filename=MyVB6App.exe.Manifest (Note the .exe. tag)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity name="MyVB6App.exe" version="2.8.0.127" type="win32" processorArchitecture="x86"/>
<description>Built with: Side-by-Side Manifest Maker (3.7.1.4434) (x86)</description>
<dependency>
<dependentAssembly>
<assemblyIdentity name="MyNetComWrapper" version="1.0.24.0" type="win32" publicKeyToken="6ABF096D69195FE6"/>
</dependentAssembly>
</dependency>
</assembly>
Filename=MyNetComWrapper.Manifest (Note the abscense of a .dll. tag)
<assemblyIdentity name="MyNetComWrapper" version="1.0.24.0" type="win32" publicKeyToken="6ABF096D69195FE6"/>
<description>Built with: Side-by-Side Manifest Maker (3.7.1.4434) (x86)</description>
<clrClass
name="MyComNetWrapper.SomeClass"
clsid="{A68F56A1-8425-3E06-BA83-856EC8422F5B}"
progid="MyComNetWrapper.SomeClass"
runtimeVersion="v4.0.30319"
threadingModel="Both"/>
<clrClass
name="MyComNetWrapper.SomeOtherClass"
clsid="{D5156DAF-0421-36AE-84B6-5D915068B2DC}"
progid="MyComNetWrapperc.SomeOtherClass"
runtimeVersion="v4.0.30319"
threadingModel="Both"/>
<file name="MyComNetWrapper.tlb">
<typelib
tlbid="{D189D056-66F1-4C01-8EB9-1F95BA11254A}"
version="1.0"
helpdir=""
flags="hasdiskimage"/>
</file>
</assembly>
I have a TabList control on a form that derives from COMCTL32.OCX.
On development machines it displays fine, but on clean VMs of XP and Win7 one of the tabs comes up in strange colours.
What could be the problem?
EDIT: I have discovered that the problem is related to Themes. In XP when I change from default theme to "Windows Classic" the problem disappears. How can I make this control properly colour itself taking into account changes in Themes? The only thing I can find is this discussion: Common Controls Tab Control Defects when themed
Although I have never observed such behaviour I would hazard a guess that you may be able to resolve the problem by using one of the following approaches:
Create a manifest file with the content below. Name the file to match your project EXE name with a .manfest extension. Eg. Project1.exe.manifest. Place the manifest file in the same location as your executable and run it.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" processorArchitecture="*" version="6.0.0.0" name="mash"/>
<description>Enter your Description Here</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls" version="6.0.0.0"
language="*"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
/>
</dependentAssembly>
</dependency>
</assembly>
Or, you can try adding the following code to the form that contains the MS tabbed control:
Private Declare Sub InitCommonControls Lib "comctl32.dll" ()
Private Sub Form_Initialize()
InitCommonControls
End Sub
I have created a manifest file for a VB6 application that is running on Windows 7 (not for any visual style changes, just to make sure it accesses the common registry and not a virtualised one)
The exe name is Capadm40.exe, the manifest is named Capadm40.exe.manifest and contains the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="CompanyName.Capadm40"
type="win32"/>
<description>Administers the System</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
However, this doesn't seem to make any difference. ie the application is still using the virtualised registry hive. What is also strange is the after I unticked the 'Run this program as an administrator' option in the properties of the application exe, windows still shows a shield on the application icon, leading my to think this is some issue with my windows installation rather than a fault with the manifest. Any ideas?
You're probably running afoul of the fusion cache (and the Explorer Shell's icon cache). External manifests are strongly discouraged anyway, but trying to add one after the program has previously been run often leads to such symptoms.
See Manifest and the fusion cache for a brief description.
You could also touch the EXE to reload the cache.
I would take advantage of LaVolpe's manifest creator, works great for XP, Vista and 7: http://www.vbforums.com/showthread.php?t=606736
I have only found one manifest that works across all platforms 9x+. or even works at all. I have tried all the examples, articles, etc.
the version number or anything else added to it will kill it. possible exception is the extra parameter on requestedExecutionLevel, that seems to be OK. you can change level, and you can add uiAccess. those are allowable. after a LOT of binary-count testing, I found out that those cute extra features of manifests that microsoft offers simply make windows give various errors.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<ms_asmv2:security>
<ms_asmv2:requestedPrivileges>
<ms_asmv2:requestedExecutionLevel level="asInvoker">
</ms_asmv2:requestedExecutionLevel>
</ms_asmv2:requestedPrivileges>
</ms_asmv2:security>
</ms_asmv2:trustInfo>
</assembly>
Applying the styles in the VB6 IDE:
Save this text in a file named vb6.exe.manifest in the same folder as the vb6.exe:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Microsoft.VisualBasic.IDE"
type="win32"
/>
<description>Visual Basic 6 IDE</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
Add spaces in the file end until it reaches 672 bytes (multiple of 4).
Then:
download the Resource Hacker and open it as administrator
File > open the VB6.exe
File > New blank script
type:
1 24 "vb6.exe.manifest"
Compile script
Save