Manifest View 1.0

Every so often I need to view an application’s manifest, for example to debug application dependencies or to confirm the requested execution level.  This usually involves opening up the binary application file in Visual Studio and exporting the RT_MANIFEST resource to a text file that I then open in Notepad. Needless to say this is very tedious. Well tonight I had enough of this and whipped up this little tool.

Manifest View simply reads the manifest embedded in the selected file and displays it in a browser control. It’s simple but effective. It also automatically reloads the manifest when the Manifest View window receives the input focus. This is useful if you’re viewing a manifest and then switch to Visual Studio to rebuild and then switch back to view the changes.

You can download Manifest View 1.0 here. It works on both x86 and x64 editions of Windows and can read manifests embedded in either 32-bit or 64-bit PE files. It does however require the .NET Framework 2.0 to run.

Update: build 1.0.0.2 adds support for x64 editions of Windows XP and Windows 2003.

Update: build 1.0.0.3 adds support for DLLs.

Enjoy!

© 2007 Kenny Kerr

12 Comments

  • Why do I need the creepy .net stuff and can't run the application from a network drive?

    Showing an html page in plain c/win32 is not that hard.

    Steffen

  • This looks great, but I think I'm still gonna use Resource Hacker for those times I need a quick peek. Like the other poster, I try to stay away from .Net apps.

  • Thanks for the feedback. As I said, it was just a quick tool I whipped up last night. I’ll post a native version when I get a moment. Yes, it isn’t hard but the .NET Framework does accelerate GUI development when you’re in a rush.

  • I've tried a few EXEs and I always get "Error: The parameter is incorrect". This is on XP Pro x64

  • Mike: thanks for the feedback. I mistakenly used LOAD_LIBRARY_AS_IMAGE_RESOURCE when calling LoadLibraryEx instead of LOAD_LIBRARY_AS_DATAFILE. LOAD_LIBRARY_AS_IMAGE_RESOURCE is new to Vista.
    I tested on Vista x64 and XP x86 thinking that would be good enough for this little tool. Strangely LoadLibraryEx on XP x86 just ignores the unsupported flag but Windows XP/2003 x64 doesn’t allow it and results in the error you mentioned.
    Anyway, I've posted build 1.0.0.2 to address this. Sorry about that.

  • WTF are you guys so afraid of .Net for? It won't bite. You install the framework and forget about it and you won't even notice you're running a .Net app. Sure, C# and .Net are not ideal for *everything*, but for something like this there's no reason at all not to use them and lots of reasons to use them (they make life a lot easier for the developer).

    Sometimes tells me anyone avoiding .Net apps has never actually tried them.

  • Leo: thanks for the comment. I don’t get the whole “.net is creepy” thing either.

  • I mentioned creepy because I can't run the app from a network share. It just crashes. So I have to copy the app to a local drive. This annoyes me.

    On Windows XP I have to install .net 2.0 Now I'm getting updates every few days with windows update.

    I don't like .net because every dude tries to write an app. But these people write really bad code which is running only on their machines. Since they dont care/know about error handling, a lot of these apps just crashes because of bad coding style/error handling.

    If you write a win32 app, you have to have at least a little knowledge, so you will write more stable code. Further, as a good developer, you will care about compatibility, so your app will even run on w2k.

    Steffen

  • Thanks for the tool. It would be nice to be able to edit that and stuff it back to exe/dll

  • Steffen: I respect your passion, but I completely don't understand your argument.

    1] The .NET runtime is really not that large. I just don't understand why people cry about installing it.

    2] With all due respect, the updates argument sounds like something off of slashdot. Whats wrong with the runtime? Whats wrong with getting security or robustness updates ?

    3] About your point on developers: .NET is meant to increase developer productivity, thus making it easier for smart people to make smart apps. Dumb people will still make dumb apps regardless of the toolset given to them.

    Just because somebody knows Win32 well, or COM well or whatever just guarantees they can get their code to compile and run, but not necessarily run well. I personally am aware of many people who can write lots of complex native code. Too bad its god-awful, and if they were 'smart' they would use the resources available to them to write the code in a quarter of the time, size, and complexity.

    Kenny as a smart developer recognized that he can get a lot of productivity quickly by using the resources available to him in the .NET framework. What is wrong with that?

    Just to finally conclude, and illustrate my feelings on the subject: In the end its about writing apps that work and use apps make my life easier. If someone wants to write a hello world app in C++ with inline assembler to render a window 5 microseconds faster. Fine, maybe the nerd gods will shine their heavenly light down on that developer. However, they're idiots as far as i'm concerned. Use the appropriate tools for the appropriate tasks.

  • Thanks for the update Kenny, it's working fine now.

  • Awesome tool Kenny (I'm doing isolated COM atm). Much appreciation!

Comments have been disabled for this content.