修改于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！