Just discovered Quantlib and am evaluating it for use. I am not a C++ developer, and no one on staff where I work really has deep experience with it, so I am pretty much following the instructions by rote found here:
http://quantlib.org/install/vc10.shtml
The next step will be to convert to C# using SWIG (based on instructions found here: Compiling Quantlib via SWIG for C#).
My question is, when I have completed all of the steps listed in both posts, will the result be a library that can only be compiled as 32-bit? The Boost download seems to indicate that it is 32-bit only.
Is compiling as a 64-bit application possible and/or are 64-bit binaries available anywhere (Windows platform) and/or are alternative wrapper libraries (like QLNet) a good alternative?
I'm a regular user of QuantLib. Why would you convert QuantLib to C#??? There's QLNet, which is a direct port of the library in C#. Regarding about 64 bits, you just need to compile the source yourself.
Related
I recently developed native extensions for mobile projects on Adobe AIR (Android and iOS).
I want to port these ANEs for desktop projects on Windows and OSX. The OSX part is not a problem because it uses the same mechanisms as for iOS. The problem is essentially on the Windows side.
Adobe AIR offers bridges to write the native part in C / C ++, I prefer to use C# to simplify the task and access more simply .NET libraries.
Has anyone ever heard of experiments or viable projects to code a native Adobe AIR extension with C#?
I have not found a complete solution to achieve this:
Create a DLL in C # including access to FlashRuntimeExtensions.h (C Header file)
Be able to use .NET libraries from this unique DLL
Produce only one DLL file
Do not use the flash.desktop.NativeProcess library
Thank you for your help or a different point of view on these issues.
According to Extending AIR, you just need access to any function on your DLL regardless what native method you used to create it.
This means that you still need to use a C++ project to link AIR to your native library but the main code can be done on C#. So you export your main code/logic into a DLL from C# and then use the C++ bridge project to Link both DLL and flash.
This link could also be useful : Windows ANE - tutorial introduction
A developer sent me this link to TUARUA's FreSharp GitHub page.
It corresponds exactly to the subject of my question. I share it so that everyone can see how to create an ANE (AIR Native Extension) from C# under Windows.
So I will be able to resume my development and port my libraries for desktop computers.
Thanks to everyone.
I am using swig to generate a C# wrapper to my code. But then I also need to link the dynamic library, which is a Linux .so file. Is it possible to do this from C#?
Thanks
Edit: using a .so file on Windows.
There is no direct way to do this. You need to create a native Windows version of all your native code (the so itself, plus all dependencies).
Other options include writing all your code on Linux, if possible, including the C# portion (using Mono). Or creating some sort of client/server setup, where your native code remains on Linux (as a server application) and your C# code goes on the Windows-client. If that is a viable solution for you is hard to tell without further details.
This Post seems to have some answers for Linux, are you trying to do this in Windows?
It's more than likely that your shared library will have been compiled to use linux command calls.
The only possible way to use linux .so files in a "windows" app would be to compile it (your app) using cygwin, but that way would make your windows app a posix app which means it would have to fire cygwin up everytime it runs.
We have a console app that runs in .NET 3.5. It connects to a USB device and spits out data received from it.
I'd like to port this over to OSX and have some questions about the strategy to do this. The USB Driver is already installed on OSX.
Mono looks promising but I don't get it. Does the end user have to install Mono or run something?
After looking at some other posts it seems that you can write a bash script and do some hacking to get the program installed...but I can't find a really good explanation of this. it also seems that mono wouldn't be installed in this process. These posts were also from '09 so I'm wondering if something has changed to make this easier.
My question is, what's a good way to approach running/porting a C# console app to OSX.
.NET is compiled down to IDL (bytecode) on all platforms including the windows platform. It is then run on the CLR (common language runtime iirc) which is a similar concept to the Java Virtual Machine. It just so happens that on most Windows machines that this CLR is installed by default. So if you wish your application to run on another platform you first need a CLR for that platform. Mono does include a CLR which can run on OSX. So either you (as part of your package/ bundle ) or the user would need to install this before your .NET will run.
The other issue you have is that .NET also contains certain API's which are not part of the ECMA standard which your application may or may not use. Some of these API's are present in mono, some of them are not. Those that are not usually have an equivalent or similar API which you can use to achieve the same thing however you may need to alter your application to deal with that scenario.
It really depends on what .NET api's your application is using as to how difficult it will be to port. I am guessing you are probably using winforms as part of your application so here is the guide from the mono site for that portion of the API
http://www.mono-project.com/Guide:_Porting_Winforms_Applications
You can bundle the Mono installer with your application (or your own build of Mono). You might even have the option of statically linking the mono runtime into your application on the Mac, I can't remember if it's supported (yet) or not. I'm pretty sure you can.
Also, wrt gordatron's warnings, if you use Path.Combine() to create paths instead of hard-coding \ as your path separator (which you should be doing anyway), you won't have to worry about having file system path problems.
For a nice easy way to check if your app uses any features which aren't available in Mono, you can use http://www.mono-project.com/MoMA to check for unsupported methods/classes and any other potentially non-cross-platform blockers like P/Invokes.
For a console application, I don't see you running into many issues (although you'll likely need to interface with the USB hardware differently than you do in Windows).
I am currently developing a 64-bit C# application that needs to import its data from an Excel spreadsheet. I have heard that the best way to do this is by using ADO data connections. However, I have read (and experienced) that in order to make this work, I must be writing a 32-bit application as there is no OleDb odbc driver for 64-bit applications.
The problem is that I cannot compile my application as a 32-bit application or other parts of the program (which are not re-writable) will break down.
The fact that I cannot import data from Excel in a 64-bit application seems like a fairly ridiculous issue. How do I solve this problem? Or if not, what work-arounds are available?
Two possible solutions for you:
Use the Open XML SDK instead. This is Office 2007 specific, but it deals directly with the files and doesn't have to go through any DB driver. This is my weapon of choice because it's much faster and less flaky than automation and can handle the more "advanced" tasks like formatting.
Compile a separate x86 binary and launch the process from your x64 app as needed. The importer app can either provide feedback using some form of IPC or simply convert the file to something like CSV which you can read natively in the x64 app. (I'm not exactly a fan of this type of kludge, but you do what you've gotta do...)
I agree that it's kind of ridiculous that we still don't have an x64 JET or ACE driver, but that seems to be the way it is for now. Even MSDASQL won't work for you; there's a 64-bit library but I've read that the Excel component still only works in 32-bit mode.
Have you looked into using VSTO (Microsoft Visual Studio Tools for Office, which I believe are now included as part of VS 2008, and were available in earlier versions as a free download from Microsoft)? Or using OLE Automation?
SpreadsheetGear for .NET is an Excel compatible .NET component which is safe managed code written in C# and compiled for "Any CPU", so it works with 32 bit and 64 bit .NET. This is one of the big advantages of .NET - one build of SpreadsheetGear.dll works equally well with with the 32 bit .NET CLR and the 64 bit .NET CLR.
You can see online samples here and download the free trial here.
Disclaimer: I own SpreadsheetGear LLC
I am writing in C#.
How can i find out which methods/functions I can use in an unmanaged dll that doesn't belong to windows?
Exmaple : I have some installed software on my computer, it has a dll, and i want to know what my options are as to creating code to connect to that software?
For native DLL's that you do not have a reference for you can use the dumpbin utility in the Visual Studio SDK to extract the list of exported functions in a DLL.
Dumpbin reference is here: http://msdn.microsoft.com/en-us/library/c1h23y6c(VS.71).aspx
And a CodeProject page giving some additional details on how to use dumpbin in conjunction with finding the correct P/Invoke signatures is here: http://www.codeproject.com/KB/mcpp/usingcppdll.aspx#Retrieve
PInvoke.net is great resource for .NET interop. They list not only the functions available in Windows native libraries, but also the signature you need to use in your .NET code.
use Depends.exe (which comes along with VS).
Depends would display all the exported function that can be invoked from Managed code using Pinvoke.
I read a blog about PInvoke Interop Assistant, which can deal with our own DLLs as well
http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?ReleaseId=14120
I would just like to add that if it's a COM assembly, like a VB6 COM component, it can be browsed in the Object Explorer in Visual Studio and that's pretty nice because it breaks everything out for you quite nicely.