解决方案 »

  1.   

    你另一台机子装的office 是2003的吧,而你开发机的office 是2007或2010的
      

  2.   

    “Microsoft.Office.Interop.Word, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c 这是2010或2007版本的OFFICE。你要重新引用低版本的。
      

  3.   

    那是不是引用Microsoft.Office.Interop.Word 11.0.0.0版本的dll文件,就可以了吗?
      

  4.   

    那是不是引用Microsoft.Office.Interop.Word 11.0.0.0版本的dll文件,就可以了吗?
    是的。要跟你机子上的office版本对应的上才行
      

  5.   

    那是不是引用Microsoft.Office.Interop.Word 11.0.0.0版本的dll文件,就可以了吗?
    是的。要跟你机子上的office版本对应的上才行
    为什么引入进去,如果我重新生成解决方案的话,还是会变成14.0.0.0版本的,求教一下,谢谢
      

  6.   

    那是不是引用Microsoft.Office.Interop.Word 11.0.0.0版本的dll文件,就可以了吗?
    是的。要跟你机子上的office版本对应的上才行
    为什么引入进去,如果我重新生成解决方案的话,还是会变成14.0.0.0版本的,求教一下,谢谢你把原来Bin目录下的文件删了没,?删掉了,重新引用注意版本 然后把引用的设成复制到本地。
      

  7.   

    那是不是引用Microsoft.Office.Interop.Word 11.0.0.0版本的dll文件,就可以了吗?
    是的。要跟你机子上的office版本对应的上才行
    为什么引入进去,如果我重新生成解决方案的话,还是会变成14.0.0.0版本的,求教一下,谢谢你把原来Bin目录下的文件删了没,?删掉了,重新引用注意版本 然后把引用的设成复制到本地。就是这样设置的,如果我重新生成解决方案的话,还是会变成14.0.0.0版本的
      

  8.   

    我觉得你还是换个aspose.word之类的第三方控件操作word吧
    这样就跟目标机的office版本无关了
    万一对方是WPS你不死翘翘了
      

  9.   

    使用com组件的方式是十几年前不得不使用的方式。更可笑的是引入到b/s系统里面,连续点击几次不是瘫痪就是慢得令人发指。使用com组件,随之而来的还是大量实施部署调试工作。楼上推荐的方式才是 正解。
      

  10.   

    强烈建议使用第三方控件,网上有很多,com这种方式最好别用
      

  11.   

    com组件问题太多
    部署的时候需要注册DCOM,需要版本一致,需要位数一致,需要给权限,这也就忍了,大不了麻烦点最大的问题是,调用office组件,原理是开个office进程去处理文件,很容易造成死进程,无法退出
    这在winform下还有办法解决,大不了每次导入导出之后杀死无界面的进程
    在服务器上部署,多用户多线程,同时可能有N多word进程在运行,你杀死哪个?
      

  12.   

    使用word.interop限制太多了,还是apsose.words, spire.doc 不错,不需安装office. 使用spire.doc在C#对word进行操作汇总:http://blog.csdn.net/eiceblue/article/details/43668671