There is a project in Visual Studio that simulates physics. It uses some functions from the library gsl. I wrote a C++ plugin my plugin.dll to call functions from this project inside Unity. It acts as an interface, where you pass parameters and it calls the project' functions.
Initially the Visual Studio build was generating only myplugin.dll and C# was calling the C++ functions just fine. Probably because the functions it was calling didn't use the gsl functions.
After I added more functions, some of them had to use things from gsl, so when I generate the build, one more file (gsl.dll) was generated.
When I drag all build files (from the x64/Release folder) to Unity Assets folder and run my project, it breaks, giving me this error:
I'm pretty sure the problem is the need of this extra gsl.dll. The functions work fine while testing inside visual studio, so I guess gsl is fine. How can I approach this problem?
Related
I have a solution with C# and C++ projects. Visual Studio 2019 is what is being used to build. I have a target that generates a .h file which affects all the native projects (i.e. C++ projects).
I like this target be invoked before compiling any C++ code.
How do I do it?
I added a property like below and rebuilt the C++ project. I don't see MyGenFiles getting invoked.
<BeforeClCompileTargets>$(BeforeClCompileTargets);MyGenFiles</BeforeClCompileTargets>
Update
Above is the right approach to get this done. It happened to be my verifications that was the problem. I added a message task as Jonathan suggested, I could see the target getting invoked.
It is a bit of a newbie question, but I can't seems to make it work.
I know I should use CC=, CXX= and i know the vs compiler name is cl though I'm not sure it is also true for the c++ compiler.
Now assuming the compiler name is cl for both I get the error:
go build CC=cl cxx=cl --buildmode=c-shared -o ../lib/core.dll
I get: can't load package: package CC=cl: cannot find package "CC=cl" in any of: ...
If on the other hand I try to compile without the CC / CXX options then it is all working good.
SO to sum it up:
1. what is the c and c++ compiler name for vs?
2. why i get an error when trying to choose which compiler it will use?
I tried to use cgo in visual studio with Liron's method with the latest go 1.13. It's working in a little different way. I cannot use the extracted stub lib to connect the dll to visual studio. Instead I have do something that I do not quite understand to make it working:
Create a .dll (with go 1.13 and gcc compiler) with c-shared build mode.
Create a .lib with c-archive build mode.
Use .lib to compile, and use .dll to access all functions. If I directly use .lib, all functions stall when accessing. If I use the extracted stub lib from dll, the program does not even load successfully.
After a few days of playing around it seems that the only working way to create a library that would work with visual studio is to:
create a .dll (using cgo with go 1.10+)
use the bat file or the method mention in HERE to create a stub lib to connect the dll to visual studio.
a side note it might be also possible to use loadlibrary func (I did not try that as i tried to avoid this method as it seems to be not a recommended approach).
I am using Visual Studio 2015 Community Edition and I followed Microsoft's tutorial on creating implicit dll's here https://msdn.microsoft.com/en-us/library/ms235636.aspx and I referenced the dll successfully in a C++ console application (I did it just to see if it would work).
When I tried adding the dll project to the references for a Visual Basic Windows Form Application, I got an error saying "A reference to 'DLL Project Name' could not be added." After some research, I think it's because VB targets the .NET framework while the C++ dll targets Windows, but that's all I managed to figure out. I would greatly appreciate any help on reconciling this, or setting up some solution that involves a C++ dll and a GUI project that uses the dll (I just chose VB for the GUI since it's really quick and easy to set up).
Note that both the DLL project and the Visual Basic project are in the same solution.
Your tutorial won't help you invoke the code from .NET and you are correct in assuming it to be a .NET framework inter-op. issue. You can use p-invoke to import and call the DLL or create a COM wrapper around your DLL and register it in the GAC then reference it via a COM CreateObject call.
Other possibilities are to convert it to a C++/CLI .NET C++ DLL.
References:
P-Invoke
COM
-UPDATE-
I suppose I should also mention that if you target Universal Windows Platform (UWP), it also provides a clean binding across .NET and C++ and hides some of the busy COM wire-up.
A C++ DLL should be added to your *.NET application with a post-build event "xcopy" command like this one:
xcopy "$(SolutionDir)DLL\$(ConfigurationName)"\*.dll "$(TargetDir)"*.* /Y
from your selected project go to Project-->Properties-->Compile-->Build Events-->Post-build event command line
Enter the appropriate copy command.
In the above example, several C++ DLLs were collected in a "DLL" folder in the Solutions Directory. They all get copied to the application folder every time the application is built. There were DEBUG and RELEASE versions of those DLLs in separate sub-folders.
As other posters noted, you also must have correct p-invoke declarations for your C++ DLLs in your *.NET code.
I am new to DLL development and appreciated for any help.
I have an existing c++ project and am trying to build it into dll using visual studio 2012. I changed the target extension and configuration type to be dll. I also excluded my main function. When I rebuilt it, the compiler complains:
LINK : fatal error LNK1561: entry point must be defined
When I moved the main function back, I could build the project successfully.
I want to make a dll only because there are functions and objects I need to use for another project, so i don't think I need a main function for the dll. Is having a main function the only solution for this error? Thank you in advance.
Just like a program requires main, DLLs require DllMain, a place to start and handle loading and unloading of the DLL.
Rather than a DLL consider a static library. There is far less overhead, no DllMain and supporting loaders and unloaders, and they are built directly into the compiled executable so you don't have to carry an extra file around and run the risk of clients with out of date DLLs or some malicious tool replacing your DLL with theirs. If you don't need the ability to swap out the the library with a replacement, a DLL is probably overkill.
Lets say I have:
a static library project called "LIB"
a application project called "LIBAPP"
a application project called "APP"
a application project called "APPTEST"
When i add "LIB" to LIBAPP Project Dependencies, Visual Studio automatically links "LIBAPP" against LIB.
But when i add APP to APPTEST Project Dependencies, it doesnt.
Since i am doing unit tests of APP's classes in APPTEST, i have to link against APP, therefore i am currently manually linking against all *.obj files of APP (hundreds...)
Since i have to change the link targets of APPTEST everytime i add or remove a *.cpp file from APP, this isnt a nice solution.
So is there a way to force Visual Studio to do this for me automatically, like it does when adding a static library Project Dependency ?
You can't "link against APP", as you've discovered.
One solution is to put all of APP's code into its own library, leaving APP as single source file that runs a function in that library. The you can make APPTEST another single source file that links against the new APP library.
Making an application depend on another is useful for causing both apps to both be build (if necessary) when you hit Compile. If you have enough code in APP that you feel that you need to write unit tests for them, I think it would be best to break this code out into another library, and call it something like "LIBAPPUTIL" or some-such which depends on LIB, and APP will have to depend on both LIB and LIBAPPUTIL.
You have noble intentions. By putting the parts of LIBAPP into a separate library, you get a bunch of benefits:
You can build variations of LIBAPP that have different void main()s
You can build several LIBAPPUTILs, each of which test usage of different sets of dependent code.
You can have alternate implementations of LIBAPPUTIL that do not depend on LIB. If you're smart with how you use interface types (either C++ virtuals or C structures full of function poointers) you can completely abstract away APP's dependency on LIB.