SOLUTION:
In Unmanaged C++, the DLL's don't get cleaned out of the "Release" folder the way they do in Managed C++. You must physically move your new DLL into the "Release" folder of your application program each time you make changes to your DLL.
I learned how to deal with updating DLL's in Managed C++ where all you have to do (in your application program folder) is clear out your old DLL library subfolder and copy in the new Release of the changed DLL's into that empty library subfolder. When you "Clean and Rebuild" the application that calls those DLL's, the Managed VS2010 C++ will delete the old DLL's out of the "Release" folder and copy the new DLL's from the library subfolder into the applications "Release" folder. It nicely keeps your DLL's up to date.
In Unmanaged C++, the "Clean and Rebuild" does not delete your old DLL's out of the application's "Release" folder. And it doesn't copy the new DLL's over from your library subfolder either. So even though I thought I was placing my new DLL's in a folder that my program could find them, they were not being copied like they are under Managed C++.
When Michael Burr gave me the link /dump /exports myPipe.dll
tools, I was able to see the Time Stamp of the DLL and the procedures that were available. (In my case it was the first DLL build which only had one procedure.) It was obvious it was an old DLL and not the current one.
This explains why the app always ran with the old procedure name. However, when compiled with the new procedure name, it gave a procedure Entry Point error because the app was only able to find the old DLL (in which the new procedure name didn't exist).
Thanks again! :)