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.
Related
Similar to this question Visual Studio 2013 High DPI on 4k Screen to which I had posted an answer but have now removed since uncovering the issue below.
I too have just bought a new 4K laptop and have been having problems with high DPI with the display of the SSIS package designer and dialogs in VS2013 as well as dialogs etc in SSMS.
A workaround I found for SSMS is to enable bitmap scaling and create a manifest file - ssms.exe.manifest - in the same folder as ssms.exe.
This article describes how to fix this for SSMS
http://www.sqlservercentral.com/blogs/spaghettidba/2015/10/14/ssms-in-high-dpi-displays-how-to-stop-the-madness/
For completeness, I've duplicated the process described in the article.
Set this registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
And then paste this xml into a manifest file.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
Now this works great (so far) for SSMS, so I tried to apply this fix to VS2013. While it does fix the SSIS designer display problem, it causes an issue when attempting to launch the debugger. Additionally, this is affecting debugging other project types - C#, VB as well as SSIS projects.
I'm guessing the dependencies in the manifest are incomplete or inaccurate, since 0x80040155 is a COM interface not registered error code.
Unable to start debugging.
An error occurred that usually indicates a corrupt installation (code 0x80040155). If the problem persists, repair your Visual Studio installation via 'Add or Remove Programs' in Control Panel. (Microsoft Visual Studio Debugger)
Unable to start debugging.
The debugger is not properly installed.
Run setup to install or repair the debugger. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.LaunchVsDebugger(IVsDebugger iVsDebugger, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.ValidateAndRunDebugger(Int32 flags, IOutputWindow outputWindow, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, ProjectItem startupProjItem, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchActivePackage(Int32 launchOptions)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.Launch(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
===================================
So my question is can anyone suggest a suitable manifest for VS2013 (or another way to make the SSIS designer behave)?
Ok, so I absolutely have no idea what I'm doing.
However, in the same folder as devenv.exe (C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE), there are a couple of other manifest files, one of which is for DebuggerProxy.dll.manifest. Since this is a debugger problem and there seemed to be a missing reference to the debugger, I merged the content into the devenv.exe.manifest file and came up with this, which works for me:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.VC90.CRT"
version="9.0.21022.8"
processorArchitecture="amd64"
publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
<file name="debuggerproxy.dll">
<comClass clsid="{C5621364-87CC-4731-8947-929CAE75323E}" threadingModel="Both"/>
</file>
<comInterfaceExternalProxyStub name="CausalityInternal_IAD7ALCausalityEventBridge" iid="{F6A124D7-5BB7-47B2-A9AF-AAB0EEAB60E3}" numMethods="5" proxyStubClsid32="{C5621364-87CC-4731-8947-929CAE75323E}"/>
<comInterfaceExternalProxyStub name="CausalityInternal_ISDMCausalityEventCallback" iid="{74D108F1-1FD2-4699-991E-C4BAD52E773D}" numMethods="4" proxyStubClsid32="{C5621364-87CC-4731-8947-929CAE75323E}"/>
... many more entries ...
</assembly>
Unfortunately, there is a 30k limit on characters to a post and it would not fit, so I stuck a copy of the file in my one drive here.
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
My last question "List service and services status under Win-7" made me start working on a solution that gives my app the admin privileges under Windows Vista onward based on a .manifest file.
I was not sure about continue the previous question with this matter since they are not the same so here is another question:
My app now works fine under Win 7 whether or not I run it "as admin" because of the manifest file.
My manifest file is as follow:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.6.0.5" processorArchitecture="X86" name="ServiceMonitorPro" type="win32"/>
<description publisher="Powershield Ltd" product="Powershield Service Monitor">Powershield Service Monitor</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
When the application runs on windows 7 or Vista, the UAC comes with a dialog like this:
alt text http://www.freeimagehosting.net/uploads/39787fd3dd.jpg
How can I replace the "unknow" publisher?
The other and bigest problem is, even thou the app runs with no problem under Win7 or Vista, under WinXP it is now crashing with the message:
"This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
Another thing I would like to add: If
I add reference (uses clause) to XPMan
the app works fine on WinXP but then
it my .manifest file makes no
diference under Vista or Win7.
I have to thank everyone that, with comments or answers point me to keep digging... :)
I went to search for the file WindowsXP.res.
The content of that file is:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
type="win32"
name="DelphiApplication"
version="1.0.0.0"
processorArchitecture="*"/>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"/>
</dependentAssembly>
</dependency>
</assembly>
The solution: I have mixed my .manifest file with the WindowsXP.Res xml one adding the dependency section.
If anyone know why its now working, I would be glad to hear about - but this was the solution here - tested so far in a couple of virtual machines, on my computer and a couple of others... working :)
You need to sign your code with a code signing certificate. There should be lots of examples here. I have re-tagged your question with "code-signing", and you can also look for "certificate".
I use Comodo certs myself, and sign them with the awesome, wonderful, Visual Build Pro v6, which is an advertiser here on SO.
You can indicate compatibility with various versions of Windows in your manifest as well. I know that there are entries for compatibility with Vista and Win7; not sure about XP.
Info about the manifest compatibility section is available at MSDN. This may help, also - from the linked page:
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
</application>
</compatibility>
On newer versions of Delphi (7 and above I think) you also need to also be sure to uncheck the "Use Runtime Themes" option in your project options dialog, otherwise Delphi will automatically link in its own default manifest file (that's how it enables the "theme support") and you will get a runtime error about the application's configuration being incorrect, because there will be conflicting entries.
Here's a complete manifest file for a Delphi2007 app which needs to run in adminstrator mode in Windows 7, and also includes the "dependency" section to enable runtime theme support:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
type="win32"
name="CodeGear RAD Studio"
version="11.0.2902.10471"
processorArchitecture="*"/>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
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>