You are more or less correct in that a .NET compiler is embedded in the framework as the framework itself is able to internally compile C# and VB.NET code for instance... but Visual Studio 2002-2005 targets more than just the .NET framework.
Remember that .NET applications are CPU independent and portable, provided a compatible .NET framework exists on a given CPU platform a properly written .NET app can be used without concern of if the processor below is an x86, IA64, Sparc, or a hamster in a wheel.
When it comes to native applications though, the code is built specifically for the targeted processor which makes it very difficult to take a binary compiled for Windows and x86 and have it run on a different processor architecture.
The question of which compiler you are using and if it uses the .NET framework is dependant on what kind of project you select and what project attributes you use within. If you built a .NET project from the beginning then it would require the .NET Framework. If on the other hand you built an ATL, MFC or Win32 project, then unless you are using the /CLR flag you are not dependant on it.
One way to think about this is that with all of the old school C/C++ code in the world, Microsoft didn’t want to force everyone to recode their applications for .NET, learn a new language or even be forced to use or learn the Framework... instead they provided two separate paths. On one you are in the managed world with the framework right at your side... on the other path you are in the unmanaged world and able to write and use exactly the same code you did/could before .NET ever existed and along the way there are multiple frontage roads connecting the two paths to make it easy for you to gradually work your way from one into the other as the need arises.
Does this better clear things up