The native code file can be found, though not easily. I think, however, it will not be quite what you want.
In C:\Windows there is a folder called assembly. If you open it up in the Windows Explorer, however, you will not find a list of files. You will be entering a shell application designed to manage the GAC. Go instead to a console and cd to C:\Windows\assemblies (or wherever your machine keeps the OS). If you do a dir command here, you will see a number of folders each starting with NativeImages. There will be one for each version of the .Net runtime you have installed, and a pair for 32 and 64 if you are running on a 64-bit machine. If your exe is called barney.exe, do a dir "barney*" /S . You should find a file barney.ni.exe.
Now for the bad news. This is a fully compiled file, in that it consists of machine language code, not IL. However, it is still managed code and as such must be loaded by the .Net runtime, which the runtime should do if you try to start the original executable. You cannot start such a file from the command line.
There is often less performance advantage to messing with this than you might expect, since the JIT compiler can do some runtime optimizations that are not available to ngen. Perhaps the greatest benefit to ngen is to compile dll files that are likely to be shared by many processes at runtime. A dll compiled by JIT cannot be shared, and each process keeps its own copy. A dll from ngen's cache can be shared. This is why, of course, when you look in the NativeImage folders you see lots of folders for the .Net framework dlls themselves.
Best you can do for your application is just carefully test and determine whether you are indeed gaining an advantage.
