Use the Network Services Shell to unblock WLANs in Windows Vista

Yesterday I wasn’t able to connect to my own WLAN. The day before yesterday I was able, but yesterday I got the message that my network administrator has blocked me from connecting to this network. "Your network administrator has blocked you from connecting to this network".


The ironic thing is that I am the network administrator of this network. :-) As I hadn’t installed anything new on my machine, I wondered why my computer wasn’t able to connect anymore. Then I remembered that I got a bluescreen due to my swisscom unlimited card. My computer awaked from sleep and didn’t recognize the swisscom unlimited card anymore. I plugged-in the card again, and then I got a bluescreen. Unfortunately at this moment I was not in my home-wlan, so I didn’t recognize that it didn’t work anymore.

So the question was how to unblock this WLAN. I didn’t find any contextmenu or a Dialog to unblock it. So first I have deinstalled the software of the unlimited card. But that wasn’t a helpful idea. My WLAN was still blocked. (Normally the software of the unlimited card (called unlimited data manager) can manage your WLANs, then you’ll see them as blocked. But I didn’t tell the software to manage my WLANs, so I thought deinstalling would help, but it didn’t).

After deinstalling the unlimited card software didn’t help, I thought there’s only a way like a real admin would do – by a commandline-tool that gives you a little bit of linux-feeling.

Windows Vista contains a commandline-tool called "netsh" – the Network Services Shell. That tool was also shipped with XP and other Windows Operating Systems. Run that tool from the commandline with "netsh wlan" and you’ll see the available commands for WLANs. I looked at, where you’ll find all informations about administration of WLANs by netsh. There you’ll also find the "delete filter" command, that was the solution to my problem.

I’ve deleted the filters of denied infrastructure and adhoc networks by calling the following two commands in a cmd-Window with path to system32

>netsh wlan delete filter permission=denyall networktype=infrastructure
>netsh wlan delete filter permission=denyall networktype=adhoc

Both times I got the message "This filter is removed from the system successfully". Here’s the Console that shows what I’ve done.


After that step in the Console, my WLAN wasn’t blocked anymore and I was able to connect again… puhh, however, I’m still still wondering that there isn’t a GUI to unblock WLANs, even on a system called "Windows". ;-)

Vista’s SaveFileDialog and OpenFileDialog in WPF

Windows Vista contains new Win32-Dialogs to save and open a file. There are also the old dialogs from XP available.

Windows Presentation Foundation has two wrapper-classes for Win32-Dialogs. The Microsoft.Win32-Namespace contains a SaveFileDialog- and an OpenFileDialog-class. The classes are located in the PresentationFramework-Assembly, one of the central assemblies of WPF.

When you use the classes from Microsoft.Win32-Namespace, you get the old dialogs from XP. In the snippet below the OpenFileDialog is opened.

With the two lines above the dialog below is shown, and that’s the old-style Windows XP OpenFileDialog:


Windows Forms also wraps the two Dialogs SaveFileDialog and OpenFileDialog with classes in the namespace System.Windows.Forms. Add a reference to the assembly System.Windows.Forms.dll to your WPF-Project, and you can use these wrapper-classes. The interesting part is that they show per default the new Vista Dialog.

With the lines above the new Vista Dialog is displayed:


Both WinForms-Dialog-Classes contain a property called AutoUpgradeEnabled (inherited from FileDialog, property is supported in .NET Versions 3.5, 3.0 SP1 and 2.0 SP1). This property is per default true, so the FileDialog-Instance will automatically upgrade appearance and behavior when running on Windows Vista. Set it to false, to get the old dialog-style:

On XP, the AutoUpgradeEnabled-property doesn’t have any effect, of course, there’s only the old dialog available.

Fazit: The cool thing about Microsoft.Win32 is that you can add a using-directive to your WPF-Project and use the classes inside that namespace without a full qualified name. Adding a using-directive for System.Windows.Forms isn’t a good thing in a WPF-Project. There are many double-matches in System.Windows.Forms and e.g. WPF’s System.Windows.Controls-Namespace, like e.g. the Button-class. So the compiler needs full qualified names. But if you wan’t to use the new Dialogs, you have to use the Wrappers from Windows Forms, but don’t add a using-directive for System.Windows.Forms, use full qualified names instead.

There are also other possibilities to get the new vista dialogs. E.g. you could make a Win32-call into comdlg32.dll, but the already available wrappers from Windows Forms are the easiest and fastest way to do it. And you won’t program something, if it’s already there, right? But you have to know that it is there. 8-)

I think Microsoft will update the classes in Microsoft.Win32 in the near future, maybe in the upcoming servicing release for .NET 3.5 planned for Summer 2008? It’s really a little bit strange, WPF is the technology to create first class Vista apps, and its wrappers show still old dialogs, while Windows Forms wrappers don’t…