4

This existing question on SO is probably exactly what I need, but it wasn't answered. ;)

I hadn't realized this in my initial testing of my WiX installer, but my application doesn't work properly on Windows 7 after it's been installed. Various assemblies need to read/write files in my installation folder, but access is denied at runtime.

If I then run the application as an administrator, it works perfectly. I can also change the properties of the application manually so that it always runs as an administrator. However, I don't want the user to have to click Yes to the UAC prompt every time.

The part I don't get is that if I run my executable from my source code folder, I don't have to run it as an administrator and it works perfectly.

Can anyone explain why: 1. My executable, when run from my bin/Debug folder, doesn't need to be run as an administrator and works? 2. How I can get WiX to install the executable so it works exactly the same way? (i.e. doesn't require right-click + Run as Administrator)

Thanks!

Community
  • 1
  • 1
Dave
  • 14,618
  • 13
  • 91
  • 145

1 Answers1

6

Programs generally shouldn't be diddling with things in the Program Files folder, but if you do need to do this, you will need to ensure that the permissions on your program's installation folder are set as part of the installation process.

Now that I have berated you for trying to do this, I will give an example from a WiX installer for a program that I maintain that does this same sort of naughty log file writing:

<Directory Id="DirectoryLogs" Name="Logs">
    <Component Id="ComponentCreateFolderLogs" Guid="SOME-GUID">
        <CreateFolder>
            <Permission
                GenericAll="yes"
                User="Authenticated Users" />
        </CreateFolder>
        <RemoveFile
            Id="RemoveFileLogsAll"
            Name="*.*"
            On="uninstall" />
    </Component>
</Directory>

So the installer will create the Logs folder, give all Authenticated Users NTFS permissions to wreak havoc on that directory, and blow away all of the log files that were created after the original installation as part of the uninstall process to leave a clean uninstall.

Is it great design? No--Windows logo requirements freak out about this--but it happens a lot especially in internal environments, so this is how you do it.

Good luck!

Nicholas Piasecki
  • 25,203
  • 5
  • 80
  • 91
  • Thank you for the slap on the wrist. ;) I guess I really need to think about this for the future. For now, I'll give your approach a try. I should have known that I should be writing this stuff to the Users folder instead, now that UAC is everywhere! – Dave Nov 03 '10 at 00:05
  • Actually, I've changed my mind. I'm reading the MS Guidelines for UAC and am going to try to rewrite the portions of code that are not compliant. Would you recommend writing the files to Users\Public\Public Documents, perhaps? – Dave Nov 03 '10 at 00:18
  • 1
    Depending on how it's intended to be used, there's %APPDATA% [aka Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) in .NET] or there is Isolated Storage (which pretty much lives in the same place, but is accessed differently in .NET). If it's something like a log file, I'd make myself a folder in AppData and plop it there. If it's a user-specific database for your app, I'd store it in isolated storage. Anything else--it's a toss up. (See http://stackoverflow.com/questions/483840/when-should-i-opt-for-isolatedstorage-versus-appdata-file-storage). Good luck! – Nicholas Piasecki Nov 03 '10 at 00:26
  • thanks for the tip! I was going to do a CW post here to ask WTH there aren't simple to use wrappers around P/Invoke for accessing shell32.dll methods. I would like to use SHGetKnownFolderPath, but I'll look into Environment now. – Dave Nov 03 '10 at 00:38
  • I'd really like to credit you for this answer, so I'm modifying my installer just to see if it does the trick. If I add the Directory element, along with a ComponentGroup and ComponentGroupRef to a Feature, I get the error "ICE21: Component: 'ComponentCreateFolderLogs' does not belong to any Feature." Can you think of why I'd get this error if I did add ComponentCreateFolderLogs to a Feature? The Feature I added to already has another ComponentGroupRef, but the compiler didn't complain about it. – Dave Mar 19 '12 at 16:28
  • sorry, never mind I realized that I should have used ComponentRef, not ComponentGroupRef. Testing it now! – Dave Mar 19 '12 at 16:36
  • I'm testing this for a different WiX project, but it might not be related to logging. My installer did create the logs folder, but when I run it, it just silently exits. If I right-click and "run as administrator", it all works fine. Is there a way to force WiX to set properties on the app so that it forces "run as administrator" mode? What's still weird is that on my dev system, I can run the app without running as administrator. On both systems (working and not working), I am logged in as a member of Administrators... – Dave Mar 19 '12 at 16:42