From: Dave m <csh...@ya...> - 2006-02-27 19:00:44
|
Hi I am trying to build a project which wraps certain C/C++ dlls to execute as wrapped C# dlls. Everything had been working with the VS 2003 compiler. When I tried building the wrappers using the VS 2005 compiler, I got an error saying that a particular member function I was trying to use had an ambiguous reference which could not be resolved. Specifically, this member could either be System.AccessViolationException or MyNamespaceWrapped.AccessViolationException. Here, MyNamespace is the project namespace which contains the same member (AccessViolationException). I found this odd. However, to resolve this error, I tries using thr %rename directive to change all AccessViolationException in the wrapper generated C# files to AccessViolatedException. However each time the wrappers were generated, the C# code would be set to AccessViolationException and again gave the same reference exception. As a simple test, I tried to force the name in the C# generated file and on compilation the project worked (affirming the fact that there was no other problem with the code). The other thing that I tried was to append the Namespace during generation, so that the compiler does not get confused. But each time I gave it's full reference, namely MyNamespaceWrapped.AccessViolationException, it a) recognised that this does not belong to the System namespace, and b) started looking for this in MyNamespaceWrapped, i.e. for MyNamespaceWrapped.MyNamespaceWrapped.AccessViolationException. Clearly this path does not exist, and this method was unsuccessful in resolving the error. I still think that the rename directive should work. I'm therefore enclosing specific parts of my interface files (2), and if anyone has any suggestiong, I would appreciate if you could share them with me. One thing to do I suppose would be to change the name of the member function permanently, but since this specific project has been redistributed in a considerable number of other projects, this would entail a significant effort to synchronise across all projects, not to mention the possible dilemma over deciding a new name. Relevant file parts: ================================================ File1 - Module1Exceptions.i ================================================ . . . static void ThrowAccessViolationException(string msg) { // hack for .NET 2; modified in Module1Exceptions.i as well // original class name (AccessViolationException) conflicts with // System exception in .NET2 // This is where the conflict could not be resolved, so the name was // changed throw new AccessViolatedException(msg); } . . ================================================ ================================================ File2 - MyNamespace.i ================================================ /* ----------------------------------------------------------------------------- * File MyNamespace.i * SWIG interface file to generate C# wrapper for MyNamespace namespace. */ // Module name MUST be the name of the dll that will contain the wrapper. %module MyNamespaceWrapped // In the block below, put files to include in the generated wrapper *_wrap.cpp %{ // Starting the wrapper #include "MyNamespace.h" %} // SWIG library for string handling %include "std_string.i" %include "exception.i" // This is needed for string as class' public members (in our case, static constants) %apply const std::string& {std::string *}; // Our custom library, to allow addressing classes from different assemblies // (where SWIG generates protected, we need public access) %include "pubtypemaps.i" /* * Below are our headers (i.e., interface that is being wrapped), preceeded * and/or followed by the customisation necessary for SWIG to correctly generate * what we need. */ %include "file1.h" %include "file2.h" //------------------------------------ // Exceptions //------------------------------------ // hack for .NET 2; modified in exceptions.i as well %rename(Module1ViolatedException) MyNamespace::Module1ViolationException; %include "Module1Exceptions.i" %include "Module1Exceptions.h" ================================================ --------------------------------- Find your next car at Yahoo! Canada Autos |
From: Marcelo M. <mm...@ac...> - 2006-02-27 19:43:15
|
While William can offer more help in this front later, here are some questions: - what swig version are you using? - could you provide a small but working example?, ie, from the code snips you have below, please create a test.i file which can reproduce the error under your compiler. Marcelo Dave m wrote: > Hi > > I am trying to build a project which wraps certain C/C++ dlls to > execute as wrapped C# dlls. Everything had been working with the VS > 2003 compiler. When I tried building the wrappers using the VS 2005 > compiler, I got an error saying that a particular member function I > was trying to use had an ambiguous reference which could not be > resolved. Specifically, this member could either be > System.AccessViolationException or > > MyNamespaceWrapped.AccessViolationException. Here, MyNamespace is the > project namespace which contains the same member > (AccessViolationException). I found this odd. However, to resolve this > error, I tries using thr %rename directive to change all > AccessViolationException in the wrapper generated C# files to > AccessViolatedException. However each time the wrappers were > generated, the C# code would be set to AccessViolationException and > again gave the same reference exception. > < /div> > As a simple test, I tried to force the name in the C# generated file > and on compilation the project worked (affirming the fact that there > was no other problem with the code). > > The other thing that I tried was to append the Namespace during > generation, so that the compiler does not get confused. But each time > I gave it's full reference, namely > MyNamespaceWrapped.AccessViolationException, it a) recognised that > this does not belong to the System namespace, and b) started looking > for this in MyNamespaceWrapped, i.e. for > MyNamespaceWrapped.MyNamespaceWrapped.AccessViolationException. > Clearly this path does not exist, and this method was unsuccessful in > resolving the error. > > I still think that the rename directive should work. I'm therefore > enclosing specific parts of my interface files (2), and if anyone has > any suggestiong, I would appreciate if you could share them with me. > One thing to do I suppose would be to ch ange the name of the member > function permanently, but since this specific project has been > redistributed in a considerable number of other projects, this would > entail a significant effort to synchronise across all projects, not to > mention the possible dilemma over deciding a new name. > > Relevant file parts: > > ================================================ > File1 - Module1Exceptions.i > ================================================ > . > . > . > static void ThrowAccessViolationException(string msg) { > // hack for .NET 2; modified in Module1Exceptions.i as well > // original class name (AccessViolationException) conflicts with > // System exception in .NET2 > // This is where the conflict could not be resolved, so the name was > // changed > throw new AccessViolatedException(msg); > } > . > . > ================================================ > > > > ================================================ > File2 - MyNamespace.i > ================================================ > > /* > ----------------------------------------------------------------------------- > * File MyNamespace.i > * SWIG interface file to generate C# wrapper for MyNamespace namespace. > */ > > // Module name MUST be the name of the dll that will contain the wrapper. > %module MyNamespaceWrapped > // In the block below, put files to include in the generated wrapper > *_wrap.cpp > %{ > // Starting the wrapper > #include "MyNamespace.h" > %} > // SWIG library for string handling > %include "std_string.i" > %include "exception.i" > // This is needed for string as class' public members (in our case, > static constants) > %apply const std::string& {std::string *}; > // Our custom library, to allow addressing classes from different > assemblies > // (where SWIG generates protected, we need public access) > %include "pubtypemaps.i" > > /* > * Below are our headers (i.e., interface that is being wrapped), preceeded > * and/or followed by the customisation necessary for SWIG to correctly > generate > * what we need. > */ > %include "file1.h" > %include "file2.h" > //------------------------------------ > // Exceptions > //------------------------------------ > // hack for .NET 2; modified in exceptions.i as well > %rename(Module1ViolatedException) MyNamespace::Module1ViolationException; > %include "Module1Exceptions.i" > %include "Module1Exceptions.h" > ================================================ > > ------------------------------------------------------------------------ > Find your next car at *Yahoo! Canada Autos* <http://autos.yahoo.ca> |