I too was wondering about native win32 versus .NET code. From what I understand the .NET framework will handle the UAC and most .NET developers shouldn't worry too much about it. I imagine though that anyone who developed using the native APIs will be the
ones who see the majority of these problems.
The short answer is if you turn off UAC, my .NET app works fine on Vista.
When I took the effort to switch from VB6, to .NET (which was no small migration), I too believed that my app would work just great in Vista without any code changes. As far as class libraries and methods, these are all there and work great on Vista, but as
far as UAC, it is not pretty:
1) .NET methods and libraries work without a problem on Vista just like they do in XP. This is great, and this is what I hoped for by migrating my app to .NET. I don't have to worry about creating separate installers like I did for my VB6 app for Win2k and
XP. Another example: I don't have to worry about differences from XP to Vista regarding the operating system paths because by calling the System.Environment.GetFolder(Desktop) for example because .NET will resolve it correctly on both platforms, even though
the physical paths are different.
2) Ok, now the bad news. UAC causes lots of problems for my app during install and auto-updating. Like they said in the video, apps which "auto-update" and try to write to the program files directory have problems.
The good news is that you can turn off UAC. Anyone who runs my app on Vista is going to have to turn off UAC and run as an administrator to be able to install or update my app. The app runs fine for a standard user, but for updating its database, which happens
once a month, they are going to have to turn off UAC, which makes Vista more XP-like as far as priviledges. I'll work to make my app work as well as possible with UAC, but I'm a one man development shop, so it's going to be a few months, if ever.