Recently I was updating some code on a system that was fairly old. I won’t/can’t get into too many details, but in my quest to locate malware (by being exploited), it is frequently beneficial to use oldest and worsest (e.g. IE6 – ok, not oldest, but the rest is true) systems with low levels of security patches, etc. So I needed to update one of the services running on such system that was originally compiled in Studio 2005 and has not been updated in quite some time. I’ll be frank, I am not certain that this has anything to do with the issue, but feel that it’s somehow relevant.
Anyway.. These days I do most of my development on Visual Studio 2008, and after making necessary changes to the code in question I loaded it up on this older system and tried to start it. Although this was a Windows service, I have a service console wrapper for debug purposes, so I ran the thing from command prompt. To my great amusement, the result was:
The system cannot execute the specified program.
Nice! If this is a problem you are experiencing, please note that it can happen (as usual) in many situations. Things to check are:
- Do you have the correct Visual Studio Runtime installed on the target system?
- Do you have the correct .Net framework installed on the target system?
For me, both of those were true and I also ran ‘Depends’ for good measure (although that typically results in a different message).
With lack of other info, I turned to the Event Viewer (eventvwr), where in the System log I noticed a couple of errors from SideBySide. Namely, something like this:
Syntax error in manifest or policy file “myawesomeservice.exe” on line 3. The required attribute type is missing from element assemblyIdentity.
Generate Activation Context failed for myawesomeservice.exe. Reference error message: The operation completed successfully.
Really, I was truly glad that it successfully errored out :-).
The odd thing was, that I had no manifest or policy file associated with “myawesomeservice.exe”. If you do, then obviously that’s where you should look for syntax issues.
Digging a little deeper, I found that manifest information can be embedded into the application itself at compile time. Under Project Properties -> Application there are settings for Icon and Manifest:
Changing that setting to “Create application without a manifest” resolved the issue.
However, I wanted to dig a little further yet, and figure out what the embedded manifest looked like. Microsoft provides a tool for things like this – mt.exe – which typically resides in C:\Program Files [(x86)]\Microsoft Visual Studio 8\Common7\Tools\Bin\mt.exe. This tool does numerous things (you can see the command-line options) but the one in question is exporting the embedded manifest file.. So, run:
mt.exe -managedassemblyname:myawesomeservice.exe -out:myawesomeservice.manifest
If all goes well, this will produce “myawesomeservice.manifest” file that will contain the XML markup for manifest information. There, I noticed that AssemblyIdenity attribute was indeed missing the type attribute. But why and why does it work on the Dev box and not on the older system, that I am not sure about.