アプリケーションの種類で「単純アプリケーション」を選択すれば最初から
stdafx.hがインクルードされた状態でプロジェクトが作成されますので、
それを利用してください。

単純にstdafx.hが無いのではないかと。
プロジェクトを作成するときの最初のステップで以下のどれを選びましたか？

空のプロジェクト
単純アプリケーション
Hello, World!アプリケーション
MFCをサポートするアプリケーション

空のプロジェクトを選んだ場合はstdafx.hは無いのではないかと
思います。

質問者に逆に質問。
コンソールアプリなのに、なんで stdafx.h が必要なんですか？
ＭＦＣが使いたいの？？

stdafx.h　は主にウインドウズアプリ用途ですよね？

> stdafx.h　は主にウインドウズアプリ用途ですよね？

違います。
プリコンパイルヘッダをまとまるのが目的で、
Windows/Consoleには無関係です。

stdafx.hって、MFC関連の全ヘッダファイルじゃなかったでしたっけ？
膨大な数のインライン関数を含むため、まともにコンパイルすると、インライン関数の
コンパイルだけでかなりの時間がかかる。
だから、インライン関数のプリコンパイルヘッダをあらかじめ作成し、ビルド時に再利
用することでビルド時間の短縮をはかる。
そんな感じだと思っています。自信のほどは、まるで無しです(笑)。

> stdafx.hって、MFC関連の全ヘッダファイルじゃなかったでしたっけ？
επιστημηさんが書いている通りです。MFC関連と決めつけてはいけません。
# afxwin.hと間違ってない？。それだとしてもMFC関連の全ヘッダファイルじゃないし。

> 膨大な数のインライン関数を含むため、まともにコンパイルすると、インライン関数
の
どこからインライン関数という単語が出てくるのか不思議。その様な説明は見たことが
ありません。
プリコンパイルされるものはヘッダファイルに記述されたもの全てであり、インライン
関数に限るものではないはず。
# もしかしてヘッダファイルの役割はインライン関数の展開と考えているの？

> 自信のほどは、まるで無しです(笑)。
「まるで」自信の無いことを掲示板に書くのは如何かと。

Microsoft C および C++ コンパイラにはインライン コードなど、C または C++
コードをプリコンパイルするためのオプションが提供されています。このパフォーマン
ス機能を使用すると、安定したコード本体をコンパイルし、コンパイル済みのコー
ドをファイルに格納し、以降のコンパイルでプリコンパイル済みコードと開発中の
コードを組み合わせることができます。安定したコードは再度コンパイルする必要
がないので、以降のコンパイルが高速化されます。

以上MSDNライブラリ(VC++6.0付属)より。
プリコンパイル済みヘッダファイルの使用は、MFCやWindowsアプリケーションの場
合はこれを省略すると恐ろしく時間がかかるので大抵は有効になっていますが、
実際は只のコンパイル高速化オプションです。
何を作るかには関係有りません。

また、stdafx.hというファイル名にしたところでウィザードで生成する場合のプリコン
パイル済みヘッダファイルの名前であり、慣例的に使用されるだけで、特に意味
のあるものではないはずです。少なくともMSDNライブラリにおいてPCH回りの説
明にはそのような名称は出てきません。

大分横道にそれていますが、元の質問に対する回答としては

方法1、プリコンパイル済みヘッダファイルを使用しない様に変更する。
具体的には、「#include stdafx.h」との記述を消すだけでいいはずです。
stdafx.hに記述する指定のものは各ファイルの「#include stdafx.h」が有るべ
き場所に書く必要はあります。
もしプロジェクト設定でプリコンパイル済みヘッダファイルが有効になっていたらそれ
を無効にする必要がるので、その場合はプロジェクトを作り直すほうが簡単です。

方法2、プリコンパイル済みヘッダファイルを使用する様に変更する。
具体的には、Kerryさん書いた方法や直接プロジェクトオプションを変える方法が
あります。
プロジェクトオプションを変える方法は面倒なので止めたほうが無難です。

>#include stdafx.h

この書き方は、ソース(CPP)があるフォルダと同一の場所にあるものをインクルード
する場合の記述ですよね
コンパイル対象とする、それぞれのソースファイルの場所を確認しましょう

#include ＜stdafx.h＞
このように記述する場合はどこからインクルードするか勉強しましょう

stdafx.h　は他の皆様が思うような意味もありますが
なぜ必要か？

と聞く前に、コンパイルエラーで困っているようなので
それの原因追究方法を教えてあげるべきではないでしょうか？

maruさんへ

ごめんなさい、私には決めつけているのは、maruさんの方のように思います。
実際、私が一言も言っていないことを一杯言っていますからね。

それに、確かに私はまるで自信のないことを書きましたが、同じ疑問を持つものを代表
して書いたつもりです。
>「まるで」自信の無いことを掲示板に書くのは如何かと。
とはどういうことでしょう。
掲示板の目的って、自信のないことをみんなで相談して、お互いの知識を高めあう、そ
ういうことじゃないんですか？そういう意味でも決めつけていませんか？

これ以上の反論があるなら、この掲示板の「使用上の注意」にある
「人への批判、失礼になるような発言、不快にさせるような発言は行わないで下さ
い。」
に抵触するおそれがあるので、以下のメールアドレスに直接メールしてください。
bunapuri@yahoo.co.jp
万が一、この発言に直接、返事された場合は黙殺させていただきます。

よろしくお願いいたします。

気にすんな！

本人さんからのレスも無いまま話が進んでますけれど、
御本人さんからの情報が少なかったのでもうちょっと欲しかったんですけどねぇ。

御本人が書いていないので全くの想像の話になるんですが、
Win32 Console applicationを選んだ後、空のプロジェクトを選んでしまっていて
本来ならstdafx.hは要らない筈なのに参考にしているプログラムがプリコンパイルが
有効になっているプロジェクトのソースを参考にしていて機械的にコピーした結果
このようになったのではないかなと。

結論としては、空のプロジェクトを選んだのであれば、プリコンパイルは無効のはず
なので、stdafx.hではなくてそのコンソールプログラムに必要なヘッダーファイルを
適時追加してコンパイルすれば良いと言う話な訳です。

プリコンパイル云々と言う話は付録的な話ですけれど、
話的には参考になるのでこれはこれで役に立つカナと思います。

>wood
本題から逸れていてすいません。
VC++6.0などだとプリコンパイル済みヘッダファイルとして指定したヘッダファイルの
インクルードは、パスを無視して動作するので、一般常識が通じません。
この辺ちょっと注意が必要かと思います。
例：PCH有効プロジェクトで一部のCPPファイルを別階層に移動したがPCHに指
定したstdafx.hを移動しなかった場合でも、移動したCPPファイルからは存在しな
いstdafx.hを参照させておく必要がある。
…恐ろしい事にPCH有効時だとPCHにしたファイルはオープンすらしないで、ファイ
ル名のみ評価するようです。

#includeとは、以下のような行為も可能なので

ＰＡＴＩＯ　さん　がおっしゃるように
＞プリコンパイル云々
はとくに意識することなく

やったら　エラーになった、どうしたら良いかと
スレは質問していますが

stdafx.hとは何ぞや？　とは質問していないと思いますよ

参考）こんな事もできま～す（=＾エ＾=）/
------------ main.cpp -------
#include <stdio.h>
void main (void)
{
#include print.txt　　　←読み込むファイル拡張子は何でもｏｋよ
　　　　　　　　　　　　　　コンパイル通るかどうかは中身次第ですけど
}
-----------------------------

------------ print.txt ------

printf(aaaaaaaaa);
------------------------------

確かにwoodさんが書かれているように#include文はいろんな事が
出来ちゃうんですが、できるからして良いかと言うと話は別かなと。
実際の話、何でもかんでもインクルードしてしまうと元のソースが
とてつもなく読みにくくなってしまいます。
あるシステム開発でソースの何処を探してもそういう関数が存在しない
のでヘッダーファイルを覗いてみたらかなりの規模の関数が丸ごと
ヘッダーファイル内に記述されていると言う事が有りました。
インライン関数レベルの小規模なものならわかるんですが、
あまりにも大きな処理をヘッダーに書くのはどうかなと感じました。

まあ、ヘッダーファイルに書かなくてはならない必然があれば、
絶対にするなとまで言う気は無いんですけれどね。