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.
Related
I am new to Visual Studio, so if I say something wrong, please point me to the right direction.
I have a large C++ project that consists of shared library of around 20 classes and 7 executables, built by CMake in Linux. Each executable has its own CMake setup that links against the library.
I watched couple of videos on VS, managed to understand how to structure code and dependent libraries and successfully compiled the library statically.
I even managed to setup CMake in Visual studio, but started receiving an error that my .dll file is not Win32 application when I tried to build a project that links to it, so I dropped CMake and built the library by first making empty project and then adding necessary files (I thought it's CMake issue).
Long story short, now I have new setup for my library in VS that builds without issues. However I want my library to be dynamic because it makes ton of sense as 7 different projects depend on it and that's how I did it in Linux.
To my big surprise, even though selecting .dll will build, it cannot be linked to (I started all of this as empty project, not .dll template).
What I just discovered that building .dll library requires a macro that looks like (taken from https://learn.microsoft.com/en-us/cpp/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp?view=msvc-170):
#ifdef MATHLIBRARY_EXPORTS
#define MATHLIBRARY_API __declspec(dllexport)
#else
#define MATHLIBRARY_API __declspec(dllimport)
#endif
and before return type of any function in library I need to add the macro as:
MATHLIBRARY_API double some_function();
So if I understand correctly, this macro is "exporting" function names to .dll. Does that then mean that I need to open all 20 header files and wrap every single function in it with the macro?
Note that most header files are class declarations, do I need to wrap every single class method, just the public methods and is there a way to make a whole class "exported"?
It seems quite a cumbersome task just to build a shared library. I realize now this is why cmake failed and kinda begs the question on its cross platform capabilities if this wrapping to make .dll in VS needs to be done like this.
I am considering building my library statically, and in the same solution, add additional projects, and make a reference to the static library.
It kills modularity of the project, but it should work fine.
We have a VS2010 C++ project with No Common Language Runtime Support set in its project properties. Then I see that it has a source file containing some managed code and the properties for this file has "/clr" flag set. So the project does not have a /clr flag but a file inside it has. I am confused as to whether it makes the project a mixed mode one? I can open the output file in ILDisassembler which makes me believe that it indeed is a .NET assembly.
This is entirely normal, a C++/CLI project very commonly contains a mix of native C++ and C++/CLI source code files. The setting in the General setting pages merely sets the default that the compiler will assume. But turning it on for each individual source file is quite valid and common.
Other ways to do this is to keep the native C++ code in a separate library project and link it. Or by turning on MSIL code generation on and off on-the-fly in a single source code file by using #pragma managed.
The linker doesn't have to be told about it, it can tell from the content of the object file. And yes, you will get a mixed-mode .NET assembly. With the C++/CLI bits compiled to MSIL and the native C++ code compiled to machine code.
I have a native c++ dll called native.dll.
I have created a c++/cli project called cliWrapper.dll. In this I have two wrapper classes for some classes in native.dll.
And the compilation for this project works fine.
However, when I try to link cliWrapper.dll with my c++/cli console program, the linker complains that I must compile cliWrapper.dll with the compiler option /clr:safe.
Compiling with such option will generate lots of errors since most of native.dll is not verifiable code.
After googling, I see that linking two .module files requires each is compiled with /clr:safe.
Does that mean it is impossible to make a dll that will allow the user to use the wrapper class to do some stuff? I know I can always put those wrapper classes back into the console project and it will compile without problem but I'm just curious about why Microsoft wants to disable such linking?
I have native C++ dlls that I need to use in our group's new C# programs. I wanna create C++/CLI wrappers for native C++ dlls, so as to be able to import and compile them in C#.
What I need to know is how to load the dll file in the wrapper source file at the first place. Exactly the same thing that #using <...> does for MSIL, but for loading native C++ dlls.
And also, how will the objects and namespaces inside the dll become accessible then (synatically)?
EDIT:
I use
class __declspec(dllexport) radar
{
// declarations and definitions
...
};
to export my radar class from my radar.dll, and need to import it in a VC++(CLI) program like this: __declspec(dllimport) public class radar; so as to conduct it's definition into C#, but definitely I can't see radar in C#, because its not defined public in VC++(CLI). Even when I wanna use native dll's objects in VC++ dll's code, like radar pos1(); I get:
error C2512: 'radar' : no appropriate default constructor available
How can do this, having just the radar declaration at hand?
END EDIT.
Thank you!
It is automatic, you don't do this yourself. You specify the native DLL import libraries (.lib) in the linker settings for the C++/CLI project, Additional Dependencies setting. The linker links in a reference to the DLL name into the C++/CLI assembly. As soon as the C# code uses any of the managed types in the C++/CLI assembly, the CLR loads the assembly. Windows notices the native DLL references in the DLL and automatically loads them.
This can only come to a good end if Windows can actually find the native DLLs at runtime. Copy them into the build folder of the EXE project. That's awkward, you can do it with a post-build event or by adding them to the C# project with their Copy to Output Directory property set to true.
I have a DLL project in VS 2008 Pro which uses OpenMP. I use /MT as 'code generation' option, because I want all my dependencies statically linked into my DLL, since I do not want to distribute many libraries to my clients - everything shall be included in this one DLL file. The problem is that my resulting DLL still depends on VCOMP90.DLL.
How can I get rid of this dependency?
Some information:
/openmp is set in compiler options
I statically link against vcomp.lib
include is set
using multithreaded library (/MT)
Thanks a lot for your help!
I don't think you'll be able to get rid of the DLL dependency - vcomp.lib is an import library for the VCOMP90.DLL - it's not a static library:
http://msdn.microsoft.com/en-us/library/0h7x01y0.aspx
It doesn't look like a static lib is provided.