CODEWITHSUNDEEP
c#manifestassemblyinfo
Vincent
Vincent

Reputation: 1557

app.manifest and assemblyInfo.cs version numbers and is app.manifest needed?

I've been doing a lot of reading up on the app.manifest but i don't get it. Well i do get you need it for some things such as: <requestedExecutionLevel level="asInvoker" uiAccess="false" /> which we really do need and use. But there's also this:

<assemblyIdentity
  name="ModuleSimulator"
  processorArchitecture="*"
  version="1.0.2.1"
  type="win32"/>

And here comes the part I don't get, I can just leave this out without any consequences right? We already have a AssemblyInfo.cs which contains all the assembly details which includes the version:

[assembly: AssemblyVersion("1.0.2.2")]
[assembly: AssemblyFileVersion("1.0.2.2")]
[assembly: AssemblyInformationalVersion("R165Fv001r02")]
[assembly: NeutralResourcesLanguageAttribute("en")]

We are manly targeting windows 7 (at the moment) but we might start supporting windows 10 as well in the future. So what use is the assemblyIdentity in the manifest file if the AssemblyInfo.cs makes sure the assembly is compiled in the right way.

I do realise this has been asked before but I just don't seem to understand it.

What I think I understand is: The app.manifest is used by the windows app-store too.. verify?? the application. (And of course check if the application can be run because of the supported os versions and execution level) but i'm talking about the assemblyIdentity, that I don't quite get.

Upvotes: 2

Views: 1697

Answers (1)

Hans Passant
Hans Passant

Reputation: 942177

The application manifest is a purely unmanaged implementation detail. The C# compiler ensures that it gets embedded as an unmanaged resource in the final executable. Something you can see when you use File > Open > File and pick the EXE file.

It must be unmanaged because the operating system reads it. Just additional configuration beyond what can be stored in the executable file format. A format that is hard to change, too many existing programs that monkey with executable files would be paralyzed by it.

You are not supposed to leave out the AssemblyIdentity element, the SDK documentation demands that a valid manifest always has one. It doesn't otherwise get used in a .NET program since it only plays a role in finding unmanaged DLLs. So the content doesn't actually matter, you're fine with the boilerplate that the item template generates.

The operating system doesn't know beans about .NET attributes, only the CLR can read them. The ones you listed do actually get used by the C# compiler, again to create an unmanaged resource. It is the VERSION resource, you see it as well when you look at the EXE file. It fills in the details of the Details property sheet, the ones you see when you use Explorer to look at the file properties. That resource is also what is used by the .NET FileVersionInfo class. The super-important [AssemblyVersion] attribute is not visible, quite an inconvenience.

The appx manifest in a Store app is a completely different kettle of fish. Again an unmanaged detail, the operating system uses it to figure out how to deploy a store app package onto the user's machine. And what the tile looks like. And what capabilities it needs, matters to the sandbox.

Upvotes: 5

Related Questions