WPF and old style Open File Dialog on x64 systems?

S

Stefanie Mehl

Hi,

It is a well known fact that if you use the Microsoft.Win32.OpenFileDialog
from an WPF application you will have old fashioned buttons and icons. The
proposed solution to this problem (at least for ClickOnce applications) is to
put a certain paragraph into the .exe.manifest file
(http://bombayboy.wordpress.com/2006/09/09/wpf-avalon-clickonce-application-and-fileopendialog-2/):

<dependency>
<dependentAssembly>
<assemblyIdentity
type=â€win32″
name=â€Microsoft.Windows.Common-Controlsâ€
version=â€6.0.0.0″
processorArchitecture=â€X86″
publicKeyToken=â€6595b64144ccf1dfâ€
language=â€*â€
/>
</dependentAssembly>
</dependency>

Other options proposed are: Try to use EnableVisualStyles where people
assume that this is not stable (SEHExceptions problems?). Or implement the
dialog yourself by using a "Vista Bridge" sample from the Windows SDK, which
probably works only on Vista systems.
(http://reader.feedshow.com/show_items-feed=d7f39942385afee366f96021e8eb6263?page=1).

Howerver, the majority votes for the manifest solution, but there seems to
be a serious drawback: On Windows XP 64 bit versions, there is no version of
Common Controls that matches this entry in the manifest file. There are wow64
and amd64 versions of CommonControls 6.0.x available but for applications
compiled for 32 bit none of them can be used. For 32 bit applications, only
version 5.8.x is available which makes it very risky to use the above
mentioned entry in the manifest file because the ClickOnce application will
crash at install time.

Is there really no better solution to display decent OpenFileDialogs in WPF?

Best regards,

Stefanie
 
W

Willy Denoyette [MVP]

You should have both versions 5.xxx.yyy.zzzz and 6.xxx.yyy.zzz installed in
winSxS, and this for both X86 and amd64.


Willy.
 
S

Stefanie Mehl

Hi Willy,
You should have both versions 5.xxx.yyy.zzzz and 6.xxx.yyy.zzz installed in
winSxS, and this for both X86 and amd64.
Click to expand...

It would be nice if this was the case, but on a freshly installed Windows
XP64, you find only the following versions of Common-Controls:


amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_4D792D2A
amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.3959_x-ww_AB06DEB0
amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_ACED72AF
amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_0A7B2435
wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_0213CDC8
wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_5FA17F4E
x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_1B6F474A
x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.3959_x-ww_78FCF8D0

As Microsoft themselves state that Common-Controls version 6 is not
redistributable (http://msdn2.microsoft.com/en-us/library/bb776779.aspx),
there is also not way to correct that situation - so this is obviously not an
option.

Best regards,

Stefanie
 
W

Willy Denoyette [MVP]

wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.... are the
32-bit (X86) versions of the V6. common controls on XP64. So on your system
you have both.

Willy.
 
S

Stefanie Mehl

Hi Willy,

yes, that is true, but somehow ClickOnce does not accept that as a correct
version for the manifest entry (missing policy?). Otherwise, I would not even
have realized that there could be a problem with missing versions.

Best regards,

Stefanie
 
W

Willy Denoyette [MVP]

What value do you have in the manifest for processorArchitecture?
Sure, your application's manifest specifies "X86", my guess is that the SxS
manifest (and policy) specifies "wow64", so you'll need to specify "wow64"
(or tweak the policy and add a manifest in WinSxS :-( ) to make it work on
XP64. Sure this inconsistency becomes a real problem in ClickOnce scenario's
involving XP64 systems. I would suggest you to file a bug on the Microsoft
Connect site.

Willy.
 
S

Stefanie Mehl

Ok, I already had the suspicion there was no real solution to the problem
with the manifest approach. The only remaining question is: What are
alternatives - is EnableVisualStyles in combination with WindowsForms really
so unstable if it is used correctly? Because otherwise, the only realistic
solution is to live with old fashioned buttons and dialogs...

But thank you very much for your answers, Willy!

Best regards,

Stefanie
 
W

Willy Denoyette [MVP]

I remember there have been issues with EnableVisualStyles in older releases
of the framework, but EnableVisualStyles won't give you the v6 Common Dialog
Styles in a WPF application, at least it does not for me on Vista, don't
know if it does on XP64 though. Anyway I don't like to load the
System.Windows.Forms assembly in a WPF application only to call this single
method.


Willy.
 
W

Willy Denoyette [MVP]

Stefanie,

Could you try using this in your manifest

<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"/>
</dependentAssembly>
</dependency>

Note the processorArchitecture value *, this instructs fusion to find a
correct match in WinSxS.
If this doesn't work (it does for me), could you try with WinSxS tracing
(SxSTrace.exe) enabled and inspect the output of the parsed trace file.
Willy.
 
S

Stefanie Mehl

Hi Willy,

that could have been a good idea, but unfortunately it is not an allowed
value:

The WindowsForms solution seems to work fine, since it even makes it
possible to have the Vista OpenFileDialog on Vista systems.

Best regards,

Stefanie
 
S

Stefanie Mehl

Mhh, I just realized that I maybe didn't mention that I don't only use
EnableVisualStyles but also the WindowsForms OpenFileDialog...
 
W

Willy Denoyette [MVP]

Stefanie Mehl said:
Mhh, I just realized that I maybe didn't mention that I don't only use
EnableVisualStyles but also the WindowsForms OpenFileDialog...
Click to expand...
Do you have any specific requirement to introduce the Forms assembly in a
WPF application?
I'm using Microsoft.Win32.OpenFileDialog from the PresentationFramework
assembly, which is the WPF wrapper around the native Common Control (version
specified through the manifest).

And here is the relevant part of the manifest I'm using..


<?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="MyApplication.app"/>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"/>
</dependentAssembly>
</dependency>
....

Willy.

Note: I'm running this on Vista 64-bit and W2K3 64-bit SP2.
 
S

Stefanie Mehl

Hi Willy,

do you really use processorArchitecture="*" in your manifest? Because I got
an error message for that entry which I mentioned in my post.

Best regards,

Stefanie
 
W

Willy Denoyette [MVP]

Stefanie Mehl said:
Hi Willy,

do you really use processorArchitecture="*" in your manifest? Because I
got
an error message for that entry which I mentioned in my post.

Best regards,

Stefanie
Click to expand...


Stefanie,

Yes I do, but as I said before I tried this on Vista-64 W2K3 SP2 and W2K8-64
only, XP64 is quite a bit older, so I wouldn't be surprised that the
manifest schema has changed a bit.
The documented behavior can be found here:
<http://msdn2.microsoft.com/en-us/library/ms649781.aspx>
Pay special attention to the following note:
Important If you write an application for the 64 bit Windows platform, you
must change the processorArchitecture entry to
processorArchitecture="amd64". You can also specify "*", which ensures that
all platforms are targeted.

Note that * is actually the only value that works for managed applications
built with Target platform "Any CPU".
Any CPU (that is, MSIL ) means that the application can run on X86 or X64 or
IA64, however, the manifest needs a compatible processorArchitecture for the
common controls library (native code!!). processorArchitecture="X86" will
fail when running on X64, X64 will fail when you run on X86, so, the only
valid value in this case is "*".

Following are the valid combinations:
Target Platform processorArchitecture
X86 X86 or *
X64 X64 or *
Itanium IA64 or *
Any CPU *

Again, I would suggest you to file a bug to Connect.

Willy.
 
S

Stefanie Mehl

Hi Willy,

that is interesting, it could really be a difference in the schema which I
currently cannot try out so easily. I think I will file a bug in Connect
later regarding the whole thing.
But anyway, I think we covered a lot of possibilities here, so thank you
very much for all your information!

Best regards,

Stefanie
 
Top