我有一个解决方案，它有一个编译成DLL的C ++项目，以及一个 C＃项目，它是该程序的主要部分。 DLL是在常规C ++之上管理C ++的。在其中一个原生的 函数中，我打了一个看起来有点像这样的电话： file = _fsopen（path，mode，SH_DENYNO）; 该调用生成一个System.NullReferenceException，这使得 绝对没有意义，因为它发生在非托管代码中。在 之上，路径和模式都正确设置。 我做错了什么？ Lee
解决方案" Lee Crabtree" < LC ******* @ goisi>在消息中写道 新闻：％2 **************** @ TK2MSFTNGP14.phx.gbl ... 我'有一个解决方案，它有一个编译成DLL的C ++项目，以及一个作为程序主要部分的C＃项目。 这个DLL是在常规的基础上管理的C ++ C ++。在其中一个原生函数中，我打了一个看起来有点像这样的电话： file = _fsopen（path，mode，SH_DENYNO）; 那个call生成一个System.NullReferenceException，这使得绝对没有意义，因为它发生在非托管代码中。最重要的是，路径和模式都正确设置。 我做错了什么？
一个猜测...但很有可能，你错误地判断了例外是什么来源于b $ b，因为你是绝对正确的 - 得到一个管理的例外 out本地库函数没有任何意义。 你绝对100％确定'异常来自何处？ -cd
Lee Crabtree写道：我有一个解决方案，它有一个编译成DLL的C ++项目，以及一个<作为程序的主要部分的C＃项目。 DLL是在常规C ++之上管理C ++的。在其中一个原生函数中，我打了一个看起来有点像这样的电话： file = _fsopen（path，mode，SH_DENYNO）; 那个call生成一个System.NullReferenceException，这使得绝对没有意义，因为它发生在非托管代码中。最重要的是，路径和模式都正确设置。 我做错了什么？ 李
一些实验表明它与文件所在的位置有关。 。如果它与可执行文件 位于同一目录中（因此路径为。\\\\ file.ext），则可以正常工作。同样，如果根目录中的文件是 （所以路径是c：\\ file.ext），那就没问题了。 但是，在任何其他文件夹中（其路径类似于 " c：\\dir \\ file.ext"）），有一个System.NullReferenceException。 我已经检查了权限，所以不是这样。我完全在这里损失了。 Lee
Carl Daniel [VC ++ MVP]写道：" Lee Crabtree" < LC ******* @ goisi>在消息中写道新闻：％2 **************** @ TK2MSFTNGP14.phx.gbl ... 我有一个具有编译为DLL的C ++项目的解决方案，以及作为程序主要部分的C＃项目。 DLL是在常规C ++之上管理C ++的。在其中一个原生函数中，我打了一个看起来有点像这样的电话： file = _fsopen（path，mode，SH_DENYNO）; 那个call生成一个System.NullReferenceException，这使得绝对没有意义，因为它发生在非托管代码中。最重要的是，路径和模式都正确设置。 我做错了什么？
只是一个猜测..但很可能，你误诊了异常来自哪里，因为你是绝对正确的 - 从本机库函数中获得一个管理异常是没有意义的。 你绝对100％确定'异常来自哪里？
我一次踩过一个，那条线总是 触发它。 Lee
I''ve got a solution that has a C++ project that compiles to a DLL, and a C# project that is the main piece of the program. The DLL is managed C++ on top of regular C++. In one of the native functions, I make a call that looks a little like this: file = _fsopen(path, mode, SH_DENYNO); That call generates a System.NullReferenceException, which makes ABSOLUTELY no sense, since it''s happening in unmanaged code. On top of all that, both the path and mode are correctly set. What am I doing wrong? Lee
解决方案 "Lee Crabtree" <lc*******@goisi> wrote in message news:%2****************@TK2MSFTNGP14.phx.gbl... I''ve got a solution that has a C++ project that compiles to a DLL, and a C# project that is the main piece of the program. The DLL is managed C++ on top of regular C++. In one of the native functions, I make a call that looks a little like this: file = _fsopen(path, mode, SH_DENYNO); That call generates a System.NullReferenceException, which makes ABSOLUTELY no sense, since it''s happening in unmanaged code. On top of all that, both the path and mode are correctly set. What am I doing wrong?Just a guess... but most likely, you''ve misdiagnosed where the exception is coming from, because you''re absolutely right - getting a managed exception out of a native library function makes no sense. Are you absolutely 100% sure that''s where the exception is coming from? -cd
Lee Crabtree wrote: I''ve got a solution that has a C++ project that compiles to a DLL, and a C# project that is the main piece of the program. The DLL is managed C++ on top of regular C++. In one of the native functions, I make a call that looks a little like this: file = _fsopen(path, mode, SH_DENYNO); That call generates a System.NullReferenceException, which makes ABSOLUTELY no sense, since it''s happening in unmanaged code. On top of all that, both the path and mode are correctly set. What am I doing wrong? LeeSome experimentation has shown that it''s got something to do with where the file is located. If it''s in the same directory as the executable (so that the path is ".\\file.ext"), it works. Likewise, if the file is in the root (so that the path is "c:\\file.ext"), there''s no problem. However, in any other folder (where the path is something like "c:\\dir\\file.ext"), there''s a System.NullReferenceException. I''ve checked permissions already, so that''s not it. I''m completely at a loss here. Lee
Carl Daniel [VC++ MVP] wrote: "Lee Crabtree" <lc*******@goisi> wrote in message news:%2****************@TK2MSFTNGP14.phx.gbl... I''ve got a solution that has a C++ project that compiles to a DLL, and a C# project that is the main piece of the program. The DLL is managed C++ on top of regular C++. In one of the native functions, I make a call that looks a little like this: file = _fsopen(path, mode, SH_DENYNO); That call generates a System.NullReferenceException, which makes ABSOLUTELY no sense, since it''s happening in unmanaged code. On top of all that, both the path and mode are correctly set. What am I doing wrong?Just a guess... but most likely, you''ve misdiagnosed where the exception is coming from, because you''re absolutely right - getting a managed exception out of a native library function makes no sense. Are you absolutely 100% sure that''s where the exception is coming from? -cd
I''m stepping through one at a time, and that line is what always triggers it. Lee
更多推荐
在混合模式解决方案中打开文件
发布评论