   MSVC++ 2005 And Program Manifests
  I'm trying to figure out where Microsoft is heading with their new compiler.  I have been using MSVC++ 2003 since the beginning.  I finally picked up the Pro version of MSVC++ 2005 and began converting my projects over.  I understand that compilers have to evolve, but I'm having a problem understanding the use of manifests.  What I really want to do is keep manifests out of the compilation process, so I instucted the compiler not to generate or embed it into the .EXE.  When I go to run the .EXE, the application cannot find the dynamic-link library for the runtime.  I thought this was kind of strange, but it was true.  The System32 directory did not contain the runtime.  Instead, after finding the runtime, I pulled the runtime into the working directory of the .EXE.  Now the application cannot find Coredll.dll.  Being that I have not read into this problem, I would like to keep manifest files out of the .EXE.  What I want to do is keep anything CLR related and this new manifest information out of the .EXE.  Any suggestions, comments, or understandings about this problem would be great.  Thanks.   
  Sounds like an issue due to the conversion process, not due to manifest files.Many of the projects I've 'upgraded' to the new IDE has had similar problems.  The only real consistant success I've had has been some of the software pulled down from SourceForge.  Most of these seem to be made for *nix, and have a hand-edited VS6 project and workspace file.Just create a new empty project, add the files, check for the libraries that are missing (the linker will complain) and you should be good to go.frob.   ;  The conversion process seemed most strange to me.  When I tried to convert the 2003 version over to the 2005, it produced errors.  Now I wasn't too worried because all I had to do was do as you suggested and create an empty solution, add all the projects, modify the settings for each, and recompile.  Not a big deal.  This is exactly what I did, but when I asked the compiler not to produce a manifest file or embed a manifest file into the .EXE, this is where it was complaining at runtime that it couldn't find the required DLLs.Try this.  Just create a standard Win32 application using the wizard.  Tell the compiler not to produce a manifest or to embed a manifest file.  At runtime, the application will try to load the runtime but won't find it.  That is fine, just pull the runtime into the local directory.  Try running it again, and it complains about Coredll.dll.  Why should I have to have a manifest file embedded into the .EXE to run?  Where is this Coredll.dll at?  I could not find it anywhere on the harddrive.Thanks.   ;  Manifest files are required for all unmanaged code. They specify additional information about the runtime dependencies required by your code. You can't build without them. They have nothing to do with the CLR.   ;  Well, you can build without them but only if you dont plan on using the DLL runtime, linking to the static runtime shouldnt require it.   ;Quote:Original post by phantomWell, you can build without them but only if you dont plan on using the DLL runtime, linking to the static runtime shouldnt require it.This kind of negates the purpose of having a dll version of the runtime.2003 .NET and below did not use manifest files for unmannaged code.  Why have they decided to change this?   ;  The main thing seems to be secruity, something todo with ensuring your app only loads it runtime infomation from one place.Tbh, its not a huge problem, the only extra task you have todo is ensure that your end user has the runtime libs installed in the right place, something I've explained not twice [smile]   