I need to do a http get in RAD Studio XE5 C++. The tutorials on the RAD Studio site discuss a RESTCLient that is not included with the version I have. I found the Casablanca project, which is specifically for Visual Studio, and I made a small program in VS that does the simple http get and handles response in the way I need.
What do I need to do to successfully use Casablanca from within RAD Studio?
There are the steps I have taken so far.
Compiled Casablanca in Visual Studio 2013
Copied the .lib and .dll over to a folder in the RAD Studio project
added that folder to the link path in the RAD Studio project
added the .lib to the project
added dll imports to classes that should be in the .lib to the .cpp I want to use the function in.
class __declspec(dllimport) http_client;
class __declspec(dllimport) filestream;
class __declspec(dllimport) producerconsumerstream;
class __declspec(dllimport) rawptrstream;
There was a OMF error, and I used a tool that came with RAD Studio to convert the .lib, that got past the error.
I don't know how to declare the dll prototype's of the functions, because the returns types are from a namespace in the library itself so they aren't recognized. http_client is an unrecognized structure.
I tried this as well without the class keyword.
DLLs that export classes are not portable across compilers. So you will not be able to use a Visual Studio compiled DLL in C++Builder if it exports classes. Either flatten the DLL interface to export plain C-style functions instead (and then use C++Builder's command-line IMPLIB tool to create an import .lib file for the DLL, do not use the .lib file created by Visual Studio), or else find another solution.
For instance, C++Builder (and Delphi) ships with Indy 10, which has a TIdHTTP component. You can use its TIdHTTP::Get() method to perform an HTTP GET request. But if you need to actually use REST, you might be better off simply upgrading your XE5 to a version that has TRESTClient available (BTW, Embarcadero's REST classes use Indy internally).
Related
A couple of years ago, I wanted to add some open source C++ code to my C# project.
The C++ author, though a briliant physicist was a horrible programmer, and rewriting it into C# was proving very difficult. My solution at the time was to make a CLR DLL with the C++ code with a little extra code to convert to/from C# data types.
Problem solved. My C# program uses the CLR dll file and all is well.
Fast Forward to 2020 and I am considering upgrading from using Visual Studio 2015 to using Visual Studio 2017.
When I open the CLR DLL project I get an error:
The main .h file which was long ago created by Visual Studio and modified by me, will not even be displayed.
Has visual studio 2019 dropped support for creating and using C++ CLR DLL ?
Seems Visual Studio automatically commented out some of my include statements which I had written which contained the letters mfsk
Problem solved.
I want to create a simple application with a few static libraries from OpenCV. I managed to link all necessary .lib files, including opencv_world300d.lib, but at run-time it requires the opencv_world300d.dll. I can add the directory where this DLL is, but I just want a single .exe (no additional files). I clicked everywhere the option \MT or \MTd (no dlls)
How can I achieve this?
It is for x86, visual studio 2012 (v110) and OpenCV, version 3.0.0. In the lib file there is a reference to the dll, unfortunately.
OpenCV application on MS visual studio c++ needs a DLL?
Not necessarily. You can link to OpenCV static libraries, which are in the folder staticlib, under OPENCV_DIR/build/.../staticlib.
The libraries in the lib folder are for dynamic linking, so you need also the .dll.
You can have a look at this answer for the step-by-step configuration.
Since Visual Studio 2013 Update 2, it is possible to create Portable Class Libraries (PCLs) that can reference Windows Runtime types (which was not possible before) as long as they only target Windows 8.1 and Windows Phone 8.1 and no other targets.
I tried this in C# by adding a C# Class Library (Portable for Universal Apps) and it works, which means that you can consume and produce Windows Runtime types as if the project was a Windows App or Windows Runtime Component.
Since F# also supports PCLs and Windows 8.1 and Windows Phone 8.1 are supported targets, I would like to achieve the same with F# PCLs (if possible). While Visual Studio 2013 Update 4 does not offer creating F# PCLs that only target Windows 8.1 and Windows Phone 8.1, it is possible to modify the .fsproj file of an F# PCL to match the .csproj file of a C# PCL with those targets that was created with Visual Studio. This requires changing the XML elements to the following:
<TargetFrameworkVersion>v4.6</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile32</TargetFrameworkProfile>
and adding the following to an <ItemGroup>
<TargetPlatform Include="WindowsPhoneApp, Version=8.1" />
<TargetPlatform Include="Windows, Version=8.1" />
After these changes, I was able to consume and produce Windows Runtime types in the F# PCL as in the C# PCL (without complaints from Visual Studio in the F# PCL or C# (Universal) Windows App), but when I actually run the (Universal) Windows App I get the following exception when a function that uses Windows Runtime types is called in the F# PCL from the C# (Universal) Windows App:
An exception of type 'System.IO.FileNotFoundException' occurred in
[application name].exe but was not handled in user code
Additional information: Could not load file or assembly 'Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null' or one
of its dependencies. The system cannot find the file specified.
When I check the references in the Solution Explorer of Visual Studio, the C# PCL shows a reference named Windows, which is missing from the F# PCL. The Reference Properties of that reference look like this:
I tried adding this reference manually to the .fsproj file of the F# PCL by adding
<Reference Include="C:\Program Files (x86)\Microsoft SDKs\Portable\v12.0\110C4FEFF2BA61C0746933A9ED6E248D\Windows.winmd" />
to an <ItemGroup>. After this, the reference does show up in the F# PCL in the Solution Explorer with the following Reference Properties:
but does not fix the problem. That is, I still get the same exception as before.
I also tried copying and pasting the Windows reference via the context menu of the Solution Explorer of Visual Studio, but it complains with an error message.
Do you know how to properly add the Windows reference to a F# PCL? This would be really awesome, because that would make it possible to write (Universal) Windows Apps almost entirely in F#! If you know for a fact that this is not possible, then could you please explain what is preventing this from being possible?
EDIT: improved formatting of exception message
You're making a portable class library. F# does not support windows store apps, so the only way you can use F# in such a situation is to call it from C#. If you manage to succeed, you'll be the first of anyone.
I can't find a feature comparison list. I believe they can both can create native unmanaged code, right? Does Delphi by itself feature RAD?
Yes. Both Delphi and RAD Studio contain the IDE and Delphi itself, so they both create the same unmanaged native code.
RAD Studio includes other product lines as well (XE2, for instance, included C++Builder, HTML5 Builder and Delphi Prism in addition to Delphi itself). The Delphi product simply included Delphi. Both products lines, though, use the same IDE for Delphi (and C++Builder, in the case of RAD Studio).
I am using WSPBuilder on Visual Studio 2010 to create a feature with a feature receiver assembly for SharePoint 2010. When I try to build the WSP using WSP Builder I get this message in the output window:
The assembly MyAssembly.dll is unmanaged. The assembly will be excluded from the WSP package!
The defined Project Assembly seems not to be a valid assembly!
Solution compatibility: SharePoint 2010
The resulting WSP that gets built does not contain my DLL.
My DLL is strongly named, and I cant think of any other obvious reasons why this is happening.
Any idea why WSPBuilder is not able to package my assembly in the WSP?
Ahh... Found the answer. My code was getting compiled against .Net Framework 4.0. Changed it to .Net Framework 3.5 and Voila! WSP gets built without any problems...