none
Problems embedding manifest for UAC execution level for ClickOnce application

    Question

  • Hello,

     

    I have a ClickOnce WinForms application that I'm trying to get running on Vista.  I'm following the solution provided here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1307851&SiteID=1.  But, when I use the mt.exe command in step 3, I'm getting the following error:

     

    .NET Framework Initialization Error: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll could not be loaded

     

    I've uninstall and re-installed the 2.0 Framework AND SDK, rebooted, etc.  No luck.  I've verified the file is there.  I haven't found any references to this problem anywhere, other than saying I need to install the framework.  I've been using .Net 2.0 for a long time without any problems, so it must be something else.

     

    Any ideas are greatly appreciated!

     

    Thanks,

     

    Sean.

     

    Monday, July 9, 2007 8:12 PM

Answers

  • I called Microsoft on this.  Their final response:

     

    ClickOnce / Vista / UAC - ClickOnce is designed to install applications in a secure, per user cache with the benefit being that you do not require administrative permissions to install the VS part of a Click Once deployed applications.  Click once applications do not attempt to elevate to admin privileges at runtime because they can expose the client to security elevation attacks.  It is by design. We do not have any work around for this as of now.

     

    So, while you can add a UAC manifest to a ClickOnce published application, you can only use "asInvoker" as the requested execution level.  The other levels ("requireAdministrator", "highestAvailable") are not supported due to security concerns.

     

    The workaround I'm going with is to create a shell app (simple exe) that will have the UAC manifest with "requireAdministrator" and call the ClickOnce app from there.  The thinking is that the shell app is a one-time install, and the ClickOnce app will be able to upgrade normally.  I'll post back here if this works out OK.

     

    Sean.

     

    ------

     

    Update to this post:

     

    The solution of using a shell exe app and calling the application reference created by ClickOnce is working very well.  The shell app has the UAC manifest embedded, so you get the nice Vista security shield over the icon automatically.  There is the headache of having an additional app to install, but it's just an exe with no supporting files, and it's a one-time thing.  The ClickOnce automatic updates still work.

     

    The other major problem we ran into when not running elevated as administrator was that the performance for both internet calls and SQL Server calls were painfully slow!  A simple web service call and SQL update took 6.8 seconds as a standard user, and 0.1 seconds elevated.  Simply not acceptable.  HTTP downloads of JPG files was so slow the system became unusable.  See Rick Strahl's post on this subject at http://www.west-wind.com/weblog/posts/10685.aspx.  This was on a new Toshiba laptop with 2GB RAM installed.

     

    Thanks for everyone's help on this!

     

    Sean.

     

     

    Wednesday, July 11, 2007 8:04 PM

All replies

  • Does your application compile ok? Make sure you have the MT from the VISTA SDK.
    Monday, July 9, 2007 8:32 PM
  • Sorry for the lack of info.  I'm compiling on an XP box using .Net 2.0.  Everything compiles fine, and I can install on a Vista box OK (without any of the UAC manifest stuff).  It looks like the Vista SDK is for Vista and 3.0 only?

     

    I saw in another post (http://blogs.msdn.com/cheller/archive/2006/08/24/718757.aspx) that there can be problems with the mt in v2.0\bin.  I got the same error with VC\bin\mt.exe, but getting better results with Common7\Tools\bin\mt.exe, so I'm trying the solution referenced above with that.

     

    Sean.

     

     

     

     

     

    Monday, July 9, 2007 8:49 PM
  • Using Common7\Tools\bin\mt.exe worked, I was able to publish and install with the embedded manifest using "asInvoker" as the requestedExecutionLevel.  But when I try using "requireAdministrator", the install fails on the Vista machine with:

     

    +Execution level requested by the application is not supported.

     

    My ultimate goal is to be able to use "requireAdministrator", please tell me it's possible!

     

    Thanks,

     

    Sean.

    Monday, July 9, 2007 9:31 PM
  • have you modified the UAC policies at all?
    Monday, July 9, 2007 10:20 PM
  • The install fails with the default policy settings.  Disabling "Detect application installations and prompt for elevation" has no effect.

     

    If I disable "Run all administrators in Admin Approval Mode" the install works and the program runs.  But re-enabling the policy causes an error:

     

    + The requested operation required elevation (Exception from HRESULT 0x8007024)

     

    Sean.

     

     

     

     

    Monday, July 9, 2007 11:04 PM
  • I am encountering this same issue when trying.

    My goal is to get a SideBar Gadget running. It will be an XBAP that makes use of the old GiveIO.sys and trying to load that driver requires administrative rights.

    I created the manifest:

    Code Snippet

    <?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="msil" name="DMTFBrowser" type="win32"/-->
      <description>Description of your application</description>
      <!-- Identify the application security requirements. -->
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
          </requestedPrivileges>
        </security>
      </trustInfo>
    </assembly>

    Then at the command prompt (in the Release Dir), I ran the following commands:


    "c:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\mt.exe" -manifest ..\..\TestApp.exe.manifest -outputresource:TestApp.exe;#1
    "c:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\mage.exe" -s TestApp.exe.manifest -cf ..\..\TestApp_TemporaryKey.pfx
    "c:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\mage.exe" -s TestApp.xbap -cf ..\..\TestApp_TemporaryKey.pfx
    "c:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\mage.exe" -u TestApp.xbap -appm TestApp.exe.manifest -cf ..\..\TestApp_TemporaryKey.pfx

    I was hoping it would still be able to run even in IE's sandbox being that is running locally in the My Computer zone.
    Hoping for a clear path allowing it to work,
    Nathan

    Tuesday, July 10, 2007 6:38 AM
  • Bruce, anything else I can try?

     

    Sean.

    Tuesday, July 10, 2007 8:31 PM
  • I called Microsoft on this.  Their final response:

     

    ClickOnce / Vista / UAC - ClickOnce is designed to install applications in a secure, per user cache with the benefit being that you do not require administrative permissions to install the VS part of a Click Once deployed applications.  Click once applications do not attempt to elevate to admin privileges at runtime because they can expose the client to security elevation attacks.  It is by design. We do not have any work around for this as of now.

     

    So, while you can add a UAC manifest to a ClickOnce published application, you can only use "asInvoker" as the requested execution level.  The other levels ("requireAdministrator", "highestAvailable") are not supported due to security concerns.

     

    The workaround I'm going with is to create a shell app (simple exe) that will have the UAC manifest with "requireAdministrator" and call the ClickOnce app from there.  The thinking is that the shell app is a one-time install, and the ClickOnce app will be able to upgrade normally.  I'll post back here if this works out OK.

     

    Sean.

     

    ------

     

    Update to this post:

     

    The solution of using a shell exe app and calling the application reference created by ClickOnce is working very well.  The shell app has the UAC manifest embedded, so you get the nice Vista security shield over the icon automatically.  There is the headache of having an additional app to install, but it's just an exe with no supporting files, and it's a one-time thing.  The ClickOnce automatic updates still work.

     

    The other major problem we ran into when not running elevated as administrator was that the performance for both internet calls and SQL Server calls were painfully slow!  A simple web service call and SQL update took 6.8 seconds as a standard user, and 0.1 seconds elevated.  Simply not acceptable.  HTTP downloads of JPG files was so slow the system became unusable.  See Rick Strahl's post on this subject at http://www.west-wind.com/weblog/posts/10685.aspx.  This was on a new Toshiba laptop with 2GB RAM installed.

     

    Thanks for everyone's help on this!

     

    Sean.

     

     

    Wednesday, July 11, 2007 8:04 PM
  • You'll have an issue creating a low privledge process from a higher privledge one.
    Wednesday, July 11, 2007 8:13 PM
  • Hi Sean,

     

    I've run into a similar problem, and I'm interested in a few more details regarding your solution.

     

    How do you deliver the shell exe app? As an MSI? An MSI wrapped in a setup.exe?

    How does the ClickOnce app get installed? By the MSI that delivers the shell exe? By a call to Process.Start() referencing the URL for the ClickOnce deployment manifest?

    How do you find the application reference created by ClickOnce so the shell exe can start it?

     

    I'd really like to learn from your experience.

     

    Regards,

    Oluf N

    Wednesday, August 22, 2007 6:21 AM
  • Hi Oluf,

     

    The shell exe is so small (36K) and simple (no supporting files), we just copy it down to the client and put it on the desktop.  In our situation, we install the main app for our clients, so it wasn't worth the time to do something more sophisticated.

     

    We start the ClickOnce app by calling the application reference that's created with a ClickOnce install (appref.ms file).  That way the normal ClickOnce updates work fine.

     

    I'm using System.Environment.GetFolderPath(Environment.SpecialFolder.StartMenu) and add "Programs/Company Name/Application.appref-ms" because I know that's where it's installed.  If this file isn't found, I just send the user to the ClickOnce install site (publish.htm) and they install normally.

     

    If the file is found, then we just use Process.Start() with the appref-ms file.  I liked this idea better than calling the URL because it still works if the user is offline.

     

    Hope that helps.  If I didn't answer your questions or I wasn't clear, please let me know!

     

    Thanks,


    Sean.

     

    Wednesday, August 22, 2007 2:32 PM
  •  

    Hi Sean,

     

    Thanks for the extra explanations. I'm still not quite clear on how you actually get the app ClickOnce installed in the first place if it requires Vista elevation.

     

    My application is deployed on a web server, wrapped in ClickOnce. The application itself has a manifest that requires Admin privileges, and that's the part that's not supported on Vista with web deployment as far as I understand.

     

    So I think I'm still not going to be able to solve my problem. Even if I were to use the workaround you describe.

     

    On top of that, my webserver seems to mysteriously cache a really old version of the app (it's not in the file system of the webserver any more, yet it still gets successfully downloaded and deployed on XP systems)

     

    -Oluf

    Thursday, August 23, 2007 5:53 AM
  • ClickOnce installations don't require elevation.  That's why including a manifest that says the app needs to be elevated doesn't work, MS doesn't support elevating ClickOnce apps because the installations doesn't require elevation.  So it's a security thing.

     

    We install the app by going to the publish.htm page created when you publish the app with VS2005.  Once the app is installed, it needs to run elevated, which is what the shell exe does.

     

    Are you saying you can't even install your ClickOnce app on Vista?

     

    Sean.

    Thursday, August 23, 2007 2:25 PM
  • Hi Sean,

     

    I guess there are two things that get signed in the ClickOnce scenario: The xyz.application deployment manifest and the actual application manifest. My xyz.application deployment manifest is just a standard, unmodified ClickOnce manifest. It's the actual application manifest that's marked as requiring UAC elevation. And I guess that's the problem. ClickOnce goes part of the way through, and then fails, leaving the ClickOnce app not installed.

     

    Let me try to summarize your scenario, just for my own benefit: You leave both your .application deployment manifest and the real application's manifest unmodified. Then you create a separate exe that has a UAC elevation manifest and that in turn launches the ClickOnce app using Process.Start(). Since the app that launches the ClickOnce app runs elevated, the ClickOnce app will also run elevated. Did I get that right?

     

    So it sounds like I'll have to create an MSI-based installer for the small elevation .exe, have the user download and install that, and then from there launch the ClickOnce app, causing another initial download.

     

    It seems like ClickOnce is not the right deployment model for my app after all. That double download is just a little too weird for a user. In my opinion, anyway.

     

    Thanks for all the help! I really appreciate it!

     

    -Oluf

    Thursday, August 23, 2007 3:36 PM
  • Yes, the point is that adding the elevated manifest to a ClickOnce app won't work.  If anything, you can only include a manifest that says the app runs as a regular user (I forget the actual elevation level).

     

    You summarization of my scenario is correct.  Remember, we always do the initial install of our app, so dropping an exe on the desktop is easy.  It's a one-time install for the exe, so the user get's the normal ClickOnce updates without having to do anything.  The ClickOnce update process is what we like best about it. We publish a new update an all of the users are updated automatically, without any code on our part at all.

     

    Sean.

    Thursday, August 23, 2007 3:58 PM
  • Hi Sean,

    I have been struggling with the UAC for a few days since we started introducing Win 7 PCs.

    We were/are using XP with on which clickonce publishing of VS2005 winform app worked fine. However, with Win 7, the app works fine just after installed from pusblished URL but throws an error when called from the shortcut.

    I have tried several suggestions, but in vain.

    I would like to give yours a go. Can you please send me the details for the Shell.exe, if possible the project source, apparently minimum.

    Thanking you very much in advance.

    rgds

     

     

     

     

    Tuesday, July 12, 2011 10:17 AM
  • Eventaully I resolved my problem by converting the project into a VS2008 solution.

    Unser VS2008, clickonce to XP and Win7 works like a charm !!

    Friday, September 23, 2011 8:50 AM
  • SILENT FOOL

    SOLUTION: SECURTY---->enable ClickOnce security settings (unchecked)

    Friday, March 23, 2012 2:47 PM
  • Ultimately this just reinforces the whole concept that Microsoft doesn't really understand what developers and users need.  Stupid users that will click any OK button is no reason to keep developers form deploying solutions to users who can perform the appropriate clicks at the appropriate time.  An executable is an executable.  No matter where it's run from, a user just needs to run it, to use it.  Deciding that click once applications some how will never to need to elevate privs is something that is so shortsighted and under thought.  It makes no sense.

    They have created a platform penetrable by so many viruses and malware attacks from so many directions...  Rather than address those specific problems by creating a more robust internal code review (it actually should be automated now, 30 years into this disastrous situation), they are disabling things that make the platform usable.  Developers will now have to use WIX or some other installer to create an installer to run their application from.

    That just makes zero sense...



    Wubs

    Monday, July 24, 2017 7:28 PM