It has been some weeks ago when I needed to find a way to make to be executed with full rights. There are several reason why you got to do so e.g. get write-access to C:

It was my aim to show that nice UAC Dialog from Windows itself when the rights are needed.

And this is how it works:

Create a manifest for you executable which is simple xml:

<?xml version="1.0" encoding="utf-8" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="yourApp"
type="win32" />
<description>Your App Description</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"><security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" />
</requestedPrivileges>
</security>
</trustInfo></assembly>

this is the important line:

<requestedExecutionLevel level="requireAdministrator" />

Now you can rename it to (YourApp).manifest. The .NET Framework when executing the file will see the Manifest and handle its contents.

Or you can, which I regard as better, embed the .manifest file into you executable.

mt -manifest YourApp.exe.manifest -outputresource:YourApp.exe

The mt.exe come with Visual Studio SDK which can be downloaded at Microsoft’s.

To simplify this I created a Post-Build event which looks like this:

“C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\mt.exe” -manifest “$(ProjectDir)$(TargetName).exe.manifest” –outputresource:”$(TargetDir)$(TargetFileName)”;#1

An important note:
If your assembly is strong named, you will be unable to embed the manifest into it as it would invalidate the strong naming.

Some source:

Every assembly, whether static or dynamic, contains a collection of data that describes how the elements in the assembly relate to each other. The assembly manifest contains this assembly metadata. An assembly manifest contains all the metadata needed to specify the assembly’s version requirements and security identity, and all metadata needed to define the scope of the assembly and resolve references to resources and classes. The assembly manifest can be stored in either a PE file (an .exe or .dll) with Microsoft intermediate language (MSIL) code or in a standalone PE file that contains only assembly manifest information. (http://msdn.microsoft.com/en-us/library/bb756929.aspx)

I today discovered something I wanted to share with you:

When normalizing strings, it is highly recommended that you use ToUpperInvariant instead of ToLowerInvariant because Microsoft has optimized the code for performing uppercase comparisons.

ToUpperInvariant is preferred because it makes all characters round-trip. See msdn.microsoft.com/en-us/library/bb386042.aspx. For comparisons, write

"a".Equals("A",StringComparison.OrdinalIgnoreCase)

In 99,9 percent of all cases it doesn’t matter that much.

I tried benchmarking ToUpperInvariant vs ToLowerInvariant. I cannot find any difference in their performance under .NET 2.0 or 3.5. Certainly not anything that warrant “highly recommending” using one over the other.