修改於2015年9月6日：
去年寫這篇解決方案的時候其實對着色器編程還一知半解，摸索了一個治標不治本的方法解決問題，結果被一個CSDN的博主原封不動抄了去，還打上個原創的標簽= =，簡直無語。。。
最近重新開始深入學習DX，對這個問題摸索到了更合理的解決辦法，在此重新記錄一下。
本文為大便一籮筐的原創內容，轉載請注明出處，謝謝：http://www.cnblogs.com/dbylk/p/3696949.html
2014年4月的解決方案：
這個問題出現的原因是將.fx文件（着色器文件）導入自己新建的工程以后，VS2013會默認使用HLSL編譯器對其進行編譯，而.fx文件中並未定義main函數，所以會導致編譯出錯。
解決方法是：
右鍵.fx文件，“屬性->配置屬性->常規->項類型”，將“HLSL編譯器”改為“不參與生成”
2015年9月的解決方案：
按照正常的DirectX程序執行流程來說，着色器文件是在程序啟動的時候才被編譯與執行，但如此一來，當着色器程序出現語法錯誤時Debug便變成了一個噩夢。
因此，VS2013為大家提供了一個人性化的功能，那便是在程序編譯時加入了對着色器代碼的語法檢查。去年寫這篇博文時提供的解決方法便是讓編譯器跳過了對着色器的語法檢查，從而讓程序能夠正常運行。
本人博客地址，防止無腦抄襲，影響閱讀見諒：http://www.cnblogs.com/dbylk
那么問題來了：
為什么在着色器代碼在能夠正常執行的情況下編譯器還會對着色器文件報“entrypoint not found”的錯誤呢？
這個問題的答案如下：
不同於C/C++程序，着色器程序的入口函數名是可以由用戶自己定義的，而VS2013將着色器程序的默認入口函數名與C/C++一樣設為了“main”，而DirectX Tutorial中的着色器代碼並不不是以“main”作為程序入口點，所以才會報出上述的錯誤。
新的解決方法如下：
1. 右鍵.fx文件，“屬性->配置屬性->常規->項類型”，將它的值改為“HLSL編譯器”
2. 點擊右下角的“應用”按鈕，會發現左邊的“配置屬性”菜單中多了一個“HLSL編譯器”的菜單，點開后選擇“常規”
3. “入口點名稱”改為着色器文件中對應的函數名
4. “着色器類型”改為對應的着色器類型（一般為頂點 or 像素着色器）
5. “着色器模型”改為對應的着色器版本
使用這個方法就可以在解決問題的同時使用VS2013對着色器代碼進行語法檢查了，OVER！