[CMake] Setting /MANIFESTUAC:NO with Visual Studio 2012 is ignored

Tue May 6 16:37:47 EDT 2014

Yes, I believe this is still a problem in the current development version
of cmake, in that /MANIFESTUAC:NO is not correctly processed.  (And, by the
way, my previous comment about this potentially being fixed by a
restructuring was probably due to my mis-reading of the code.)

Ultimately, however, to do my testing I did go back to using the v2.8.12.2
tag source code.  After looking at cmIDEOptions::CheckFlagTable to
understand the processing of the Visual Studio linker flags processing
better, I believe that the /MANIFESTUAC:NO option needs to simply force the
EnableUAC attribute to "false".   I'm not sure why there are multiple
entries in the table (which might mean I'm missing something here) but
doing the following replacment in cvVS11LikFlagTable.h seemed to fix the
problem:

diff --git a/Source/cmVS11LinkFlagTable.h b/Source/cmVS11LinkFlagTable.h
index b4587a8..0f641e4 100644
--- a/Source/cmVS11LinkFlagTable.h
+++ b/Source/cmVS11LinkFlagTable.h
@@ -217,10 +217,7 @@ static cmVS7FlagTable cmVS11LinkFlagTable[] =
   {"LinkDLL", "DLL", "", "true", 0},

   //Bool Properties With Argument
-  {"EnableUAC", "MANIFESTUAC:NO", "", "false",
-   cmVS7FlagTable::UserValueIgnored | cmVS7FlagTable::Continue},
-  {"EnableUAC", "MANIFESTUAC:NO", "Enable User Account Control (UAC)", "",
-   cmVS7FlagTable::UserValueRequired},
+  {"EnableUAC", "MANIFESTUAC:NO", "", "false", 0},
   {"EnableUAC", "MANIFESTUAC:", "", "true",
    cmVS7FlagTable::UserValueIgnored | cmVS7FlagTable::Continue},
   {"UACUIAccess", "MANIFESTUAC:", "Enable User Account Control (UAC)", "",

I built a project with a version of cmake with this patch applied and I did
get executables without a "requestedExecutionLevel" manifest embedded in
it, and that was the behavior I was looking for (we apply our manifests
manually after the build process since it simplifies our management of the
manifest generation).

If this is correct, similar changes would be necessary in the VS10 and VS12
tables as well.  One of the reasons I thought this was correct was that the
inclusion of the 2nd rule for MANIFESTUAC:NO seems to imply there is a
syntax where there are additional values appended to MANIFESTUAC:NO but I
do not believe this to be the case.  The only other thing that wasn't clear
to me was whether MANIFESTUAC:NO has additional impact on the
UACExecutionLevel and UACUIAccess attributes but I was assuming these
values were unnecessary if EnableUAC was false.  Hopefully that is correct.

I suppose the code was trying to deal with the very general syntax of the
/MANIFESTUAC: option, which can be in the following forms:

/MANIFESTUAC
/MANIFESTUAC:NO
/MANIFESTUAC:fragment
/MANIFESTUAC:level=_level
/MANIFESTUAC:uiAccess=_uiAccess


With the "fragment" form being the most problematic (I don't think the
table-drive approach can easily handle that syntax (which is probably fine
because that syntax is a bit ugly IMHO), and the synopsis of the "fragment"
syntax is:

    /MANIFESTUAC:"level=[ asInvoker | highestAvailable |
requireAdministrator ] uiAccess=[ true | false ]"

However I suppose there might be a possibility of having the setting of
just "level" and "uiAccess" with a rule for "/MANIFESTUAC:level=" and
"MANIFESTUAC:uiAccess=" with a "UserValueRequired" "special" flag.  I'm not
asking for this directly, as it is the "MANIFESTUAC:NO" case that I care
about most, but I thought I'd mention this as a potential enhancement.  It
still doesn't address the "fragment" case, but perhaps that's ok.

So the diff I include above I believe will help the /MANIFESTUAC:NO case
but not provide full support for all the variants of /MANIFESTUAC.  But I
think it would be a step in the right direction although perhaps I'm
missing some of the issues here and am interested in whatever input you
might have regarding the appropriateness of this for inclusion in cmake.

But, should the above analysis be largely correct, I'd like to request that
this be considered for a 2.8.12.X update or at least future versions of
cmake.

I'm definitely willing to submit this fix through more official review
channels, but I thought I'd post this here for an initial check on my
understanding.

Thanks,

Eric Berge



On Fri, May 2, 2014 at 1:42 PM, Eric Berge <ericmberge at gmail.com> wrote:

> Experiments with today's git master branch are inconclusive at this point.
>  There's something causing errors with my tree that don't occur with
> 2.8.12.2, but it did generate the cvproj file and, in spite of the
> restructuring of the vcproj generation, it looks like the GenerateManifest
> value is still true.  I just wish I could have actually gotten the build to
> generate the associated executable so I could have confirmed this more
> strongly by examining the embedded manifest.
>
> So I'm expecting this is still a problem, but I'm not sure.  I'll do some
> more experimentation and update this with anything I find.
>
>
>
> On Fri, May 2, 2014 at 11:47 AM, Eric Berge <ericmberge at gmail.com> wrote:
>
>> Note that this was based on 2.8.12.2 but looking at the more recent code
>> I think there's a possibility that a fix for this "fell out" of a
>> restructuring of the generation of the vcproj files.   I'm going to try to
>> build this and see if the problem appears to be fixed.
>>
>>
>>
>>
>> On Fri, May 2, 2014 at 10:59 AM, Eric Berge <ericmberge at gmail.com> wrote:
>>
>>>
>>> I am updating our cmake files from Visual Studio 2008 to 2012 and the
>>> setting of CMAKE_EXE_LINKER_FLAGS to include /MANIFESTUAC:NO (which worked
>>> with VS2008) appears to be ignored.  The resulting exe files have the
>>> following manifest in them:
>>>
>>> <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
>>> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
>>>   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
>>>     <security>
>>>       <requestedPrivileges>
>>>         <requestedExecutionLevel level='asInvoker' uiAccess='false' />
>>>       </requestedPrivileges>
>>>     </security>
>>>   </trustInfo>
>>> </assembly>
>>>
>>> I'm not sure, but I believe this is due to the following being included
>>> for the RelWithDebInfo build I'm doing:
>>>
>>> <GenerateManifest
>>> Condition="'$(Configuration)|$(Platform)'=='RelWithDebInfo|x64'">true</GenerateManifest>
>>>
>>> and I expect this should be "false" (but I'm not sure whether there are
>>> other parts of the Visual Studio project file that need to be updated as
>>> well.
>>>
>>> I believe this is another manifestation or is at least related to issue
>>> 12963 - http://public.kitware.com/Bug/view.php?id=12963
>>>
>>> So I'm probably requesting that issue be bumped from "backlog" status.
>>>
>>> Eric
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140506/b75da63d/attachment.html>
