In one of the projects I am working the code dynamically loads in a .net DLL into a fully trusted Assembly using the Assembly.LoadFrom function. Up to now this has been working 100% without issue.
I now have a Visual C++ DLL compiled with /clr:pure that needs to get loaded using the above Assembly.LoadFrom. I get BadImageFormatException when I do which is really weird.
In the Visual C++ Project there are 3 types of CLR compile options:
/clr
/clr:pure
/clr:safe
As per the instructions given to me it needs to be compiled under /clr:pure. My problem is using /clr:pure throws the exception. If I change it to /clr it also throws an exception. If I change it to /clr:safe it loads in without throwing an exception (thisis where my testing ended).
So I guess this is really a two part question:
1) Why would /clr:safe work but not the other two?
2) How do I get it to work with /clr?
Thanks in advance!
After research this method can not load mixed assemblys. They can only be pure MSIL.
Related
I am working on a legacy Windows Forms application using VS 2008 under C++ and face a weird problem. The form uses an ImageList object, to which two bitmap images have been added. At run-time, I get the following error in Debug mode (in the Release mode, the application just doens't launch):
An unhandled exception of type 'System.Resources.MissingManifestResourceException' occurred in mscorlib.dll
Additional information: Could not find any resources appropriate for the specified culture or the neutral culture.
Make sure "MyApp.Form1.resources" was correctly embedded or linked into assembly "MyApp" at compile time,
or that all the satellite assemblies required are loadable and fully signed.
The crash occurs at the first line of this block:
this->imageList1->ImageStream = (__try_cast<System::Windows::Forms::ImageListStreamer* >(resources->GetObject(S"imageList1.ImageStream")));
this->imageList1->TransparentColor = System::Drawing::Color::Transparent;
this->imageList1->Images->SetKeyName(0, S"Nok32.png");
this->imageList1->Images->SetKeyName(1, S"Ok32.png");
This is pretty puzzling, because I copied the application from an existing one which works fine. I just changed the namespaces. And if I remove the two images from the list, the application works.
I found several posts on forums about this or similar problems, but none could really help me. I don't think that Visual Studio can be blamed. I tried with frameworks 2.0 and 3.0, to no avail. Fully comparing the sources of both applications, I can't see a significant difference.
Any hint ?
Solved: there was an old namespace left in the project file (.vcproj) !
I'm trying to use ros in cpp with Visual Studio 2012. I wrote the publisher and subscriber tutorial (http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber%28c%2B%2B%29) and first, I configure the project as says in the guide (http://wiki.ros.org/win_ros/hydro/Msvc%20SDK%20Projects).
Then i compiled an linked the publisher, but when I tried to run it, ros::init(argc,argv,"talker") throws an exception... The console says that I ROS_MASTER_URI is not defined but I've got it defined
There are 2 images here:
https://www.dropbox.com/s/o12m0l38gaxiugi/error1.png -
https://www.dropbox.com/s/ocdmf0wj6rj0962/error.png
Can anyone helps me?
Thanks in advance
So, I had the same issue, although I didn't set the ROS_MASTER_URI globally.
I managed to get around this specific issue by adding
ROS_MASTER_URI=http://localhost:11311
to the debugging environment variables (Project->Properties->Configuration Properties->Debugging->Environment).
However, after implementing the above I got an uncaught exception (Unhandled exception at 0x768bc41f in ros_demo.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0028f0e4..).
That went away when I built, compiled and ran the project in release mode (which matched my ROS SDK build).
I got the idea for the release/debug build from here:
xstring isn't an OSG specific object, so the error is elsewhere in the
3rd party dependency chain. As I know nothing about your OS and
software setup I can't speculate what this might be.
In general though this type of error could well be a linking issue -
for instance Visual Studio is hopeless at handling different libs
being built debug and release and will crash randomly.
That was fun to discover..
I would like to add a small feature to QuantLib and compile it together with SWIG bindings to use in a C# project in Visual Studio 2010. I am however having problems at almost every turn. What are the steps involved in building QuantLib in Visual Studio 2010, creating the SWIG bindings, and building the C# project?
I downloaded QuantLib from http://sourceforge.net/projects/quantlib/files/
I downloaded Boost from http://sourceforge.net/projects/boost/files/boost/1.49.0/
I downloaded the QuantLib+SWIG bindings from http://sourceforge.net/projects/quantlib/files/QuantLib/1.0/bindings/QuantLib-SWIG-1.0.zip/download
I set an environment variable QL_DIR to "C:\pathToFolder\QuantLib-1.2\lib" (computer > properties > advanced system settings > advanced > environment variables)
I ran the swig.cmd file located in C:\pathToFolder\QuantLib-SWIG-1.0\CSharp
I opened QuantLib_vc9.sln in Visual Studio 2010
For the NQuantLibc project:
I included my Boost and QuantLib directories in the header directories.
I included my QuantLib/lib directory in the library directories.
I successfully built the NQuantLibc project
For the NQuantLib_vc9 project:
I made it dependent on the NQuantLibc project.
I successfully built the NQuantLib_vc9 project.
For the EquityOption_vc9 project:
I made it dependent on the NQuantLib_vc9 project.
I successfully built the EquityOption_vc9 project.
When I try to run the EquityOption_vc9 project, I get a TypeInitializationException, "An attempt was made to load a program with an incorrect format."
Here's the full exception:
System.TypeInitializationException was unhandled
Message=The type initializer for 'QuantLib.NQuantLibcPINVOKE' threw an exception.
Source=NQuantLib
TypeName=QuantLib.NQuantLibcPINVOKE
StackTrace:
at QuantLib.NQuantLibcPINVOKE.new_Date__SWIG_1(Int32 jarg1, Int32 jarg2, Int32 jarg3)
at QuantLib.Date..ctor(Int32 d, Month m, Int32 y) in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\Date.cs:line 48
at EquityOptionTest.EquityOption.Main(String[] args) in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\examples\EquityOption.cs:line 43
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException: System.TypeInitializationException
Message=The type initializer for 'SWIGExceptionHelper' threw an exception.
Source=NQuantLib
TypeName=SWIGExceptionHelper
StackTrace:
at QuantLib.NQuantLibcPINVOKE.SWIGExceptionHelper..ctor()
at QuantLib.NQuantLibcPINVOKE..cctor() in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\NQuantLibcPINVOKE.cs:line 126
InnerException: System.BadImageFormatException
Message=An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Source=NQuantLib
StackTrace:
at [long string removed]
at QuantLib.NQuantLibcPINVOKE.SWIGExceptionHelper..cctor() in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\NQuantLibcPINVOKE.cs:line 106
InnerException:
Note that I built everything with the Debug configuation. I also tried this using the Release configuration. It didn't work.
I wish I could find a complete set of instructions detailing how to build this type of project. I found some instructions here, Compiling Quantlib via SWIG for C# but i couldn't get it to work.
The QuantLib page contains instructions for building QuantLib in Visual Studio 2010, http://quantlib.org/install/vc10.shtml but I need help creating the SWIG bindings.
Resolver Systems has pre-built C# bindings that work for me. http://www.resolversystems.com/products/quantlib-binary/ I was able to run QuantLib code in C# just fine with this package. My problem is that I need to add a small feature to the QuantLib code for use in my C# project. This is the reason I need to re-build QuantLib and re-create the SWIG bindings.
I know about QLNet, the C# port of QuantLib, http://sourceforge.net/projects/qlnet/, but this project is missing some pieces and I think that it is no longer being actively developed. Specifically, I need to be able to price options that pay discrete dividends. QLNet is missing some of the code for this. I tried porting the necessary code from QuantLib to QLNet, but my C++ must be rusty because I was getting incorrect output.
Note that the small feature I need to add to QuantLib is the ability to handle fractional days. I was able to add this feature to QLNet, and it is a small feature indeed. This tiny edit is delaying my project. I would greatly appreciate help on this issue.
There indeed seems to be a problem with the SWIG wrappers as distributed and .Net 4.0.
I'm not working on that platform, so I can't speak based on personal experience. However, the issue was discussed recently on the QuantLib mailing list, and the solution contributed there by Mark Gillis was reported to work. You can read the relevant thread at http://thread.gmane.org/gmane.comp.finance.quantlib.user/8238. Hope this helps...
I struggled with this exact error message a little while back, and visited this page, as Google search might say, "many times".
In the end, my error was fairly benign, but it took me a while to sort it out.
I was using C# wrappers by SWIG to access QuantLib C++ library. I used Excel DNA Integration to make my Quantlib.xll, and I also built a few .exes that access Quantlib.
Various situations would cause this error to appear for me, most especially
Running the .exes off of my desktop ("sometimes")
Distributing my XLL to other users (always).
In the end, I discovered that the distribution that I was getting from the bin folder of my VS2010 (and 12, 13, 15) projects included NQuantLib (the C# wrapper code) but did not include NQuantLibc (the C++ unmanaged code being called).
The XLL and the exes worked on my machine sometimes because I probably helped them (via changing my path?) to find the missing C++ code, but I did not recall that step in the process.
Once I figured it out (using a StackOverflow hint to check the "inner exception" on the error when running the code on another machine and opening up VS to debug when it bombed), the problem went away.
A bit of ignorance on my part that cost me a bit of time but earned me a bit of experience:
this error, for me, was caused by not putting the unmanaged (C++) library where the managed (C#) library could find it.
I am encountering some issues with one project. I need to use two libraries but one needs to be compiled with the /clr switch as the other cannot be compiled with this switch.
Would there be a way to use at the same time those two libraries in one project? Currently it's compiled with /clr and I got linking errors with the noclr library.
If there is no solution I can still launch the noclr library in batchmode but I'd like to avoid it...
My project is in Managed C++, the library tetgen - which needs /clr - is in native C++ and cannot be compiled without the /clr switch, as I get this error
error C3381: 'tetgenio' : assembly access specifiers are only available in code compiled with a /clr option
The other library triangle is in C. I am on Visual Studio 2008 and the project is compiled in 32 bits.
We could use more details, but using managed C++ you can certainly use a mix of managed and unmanaged code. (Microsoft calls their managed c++ code C++/CLI.)
EDIT:
Ok, your compiler error helped. Apparently you have specified a native class, but using public private, or some other access specifier on the name of the native class. From the MSDN docs:
The following sample generates C3381:
// C3381.cpp
**public** class A { // C3381. Remove public or make the class
managed. };
int main() { }
so get rid of the public keyword, and then try compiling again.
You can have multiple projects in a single solution. Right click on the solution in the eolution explorer and add -> existing/new project. Each library project can be added that way and have their own clr settings.
This I think is related to my use of the nlog C++ API (and my question on the nlog forum is here); the purpose of my asking this question here is to get a wider audience to my problem and perhaps to also get some more general ideas behind the VB6 IDE's failure to build in my particular scenario.
Briefly, the problem that I am having is that I am having trouble building VB6 components which reference unmanaged C++ components which have calls to nlog's C\C++ API (which is defined in NLogC.DLL). The build problems are not occurring during compile time, they are occurring when the binary is being built which suggests to me that it's some kind of linker type problem? Don't know enough about how VB6 binaries are produced to tell. The VB6 binary is produced, but it is corrupted and crashes shortly after it is invoked.
Has anyone had any similar experiences with VB6 (doesn't have to be related to nlog or C++)?
edit: Thanks for all the responses to this rather obscure problem. Still no headway unfortunately; my findings since I posted this:
'Tweaking' the compile options doesn't appear to help in this problem.
Adding a reference to the nlog-enabled C++ component from a 'blank' VB6 project doesn't crash it or cause weird build problems. So it isn't a 'native' VB6 issue, possibly an issue with the interaction between nlog and the various components and 3rd party libraries used by other referenced components?
As for C++ calling conventions: the nlog-enabled C++ component is - as far as I can see - compliant to these conventions and indeed works fine when referenced by VB6 as long as it is not making any nlog API calls. Not sure if the nlogc.DLL itself is VB6 compliant but I would have thought that that is immaterial since the API calls are being made from the C++ component; VB6 shouldn't know or care about what the C++ component is referencing (that's as far as my understanding on this goes...)
edit2: I should also note that the error message obtained during build is: "Errors during load. Please refer to "xxx" for details". When I bring up the log file, all that there is in there is: "Cannot load control xxx". Interestingly, all references to that particular control disappears from that particular project resulting in compile errors if I were to try to build again.
Got around the problem by using NLog's COM interface (NLog.ComInterop.DLL) from my unmanaged C++ code. Not as easy to do as the C\C++ API but at least it doesn't crash my VB6 components.
I would try tweaking some of the Compile options found in the Project, Properties menu, Compile panel to see if they yield any additional hints as to what is going wrong.
For example if you compile the executable to p-code rather than native code does it still crash on startup.
What error message do you get when you run your compiled binary?
I doubt the compiler/linker is the problem: project references in a VB6 project are not linked into the final executable. A project reference in VB6 is actually a reference to a COM type library (which may or may not be embedded in a .dll or other binary file type). Project references primarily serve two purposes:
The IDE extracts type information from the referenced type libraries which it then displays in the Object Browser (and in the Intellisense drop-down)
At compile-time, the compiler extracts the type information stored in the referenced libraries, including the CLSID of each class that you instantiate, and embeds this data into the executable. This allows your executable to create instances of classes contained in the libraries that you referenced.
Note that the compiled binary doesn't link to any code in the referenced libraries, and it doesn't even contain the filenames of the referenced libraries. The final executable only contains the CLSID's and other type information that it needs to instantiate COM objects at run-time.
It is much more likely that the issue is with NLog, or with how you are calling it from your code, rather than something gone awry in the VB6 compile process.
If you think it might be a linker problem, this should crash it the same way:
create a new standard project (of any kind)
add a new module and copy the "declare"-statements into it
compile
If it doesn't crash it is something else.
It would help an exact description of the error or a screenshot of what going on.
One thing to check is wherever NLogC.DLL or the C++ DLL you built have the correct calling convention defined. Basically you can't have the DLL function names mangled or use anything but the STDCALL calling convention. If the C++ DLL has not been created with those two things in mind then it will fail to work with VB6.
MSDN Article on Calling convention.
"Cannot load control xxx" errors can be caused by .oca files which were created from a different version of an .ocx than currently used. If that is the case, deleting the .oca files helps.