Why do I need a Reference in Visual Studio
-
On 14/02/2014 at 00:53, xxxxxxxx wrote:
References used to only be of interest if C++/CLI was the concern, but since VS2010 it is recommended way of adding your libraries instead of using project dependencies.
Check this post: http://blogs.msdn.com/b/vcblog/archive/2010/02/16/project-settings-changes-with-vs2010.aspx
-
On 14/02/2014 at 01:01, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Steve might know more about it. He's the guy I leaned my workflow from. I'm just the trained Monkey pushing buttons. And following his directions.
-ScottAHey Scott, don't follow them too closely... I started out creating plugins absolutely from scratch because I wanted to understand how it was done. But since then I use the method everyone else uses - copy over the examples project into a new folder, delete all references to existing source code and then you have all the project settings correct and ready to go.
Steve
-
On 14/02/2014 at 01:28, xxxxxxxx wrote:
Ok, thank you for participating in this discussion
I feel I am banging my head against the wall here. The topic title is "Why do I need a Reference in Visual Studio" and I still do not know why I need a Reference in Visual Studio to compile these plugins.
What happens when the reference is there? Is Visual Studio then reading from many files, a few files or just one file in the _api project? The funny thing is that I can unload the _api project from the Visual Studio Solution, and it compiles just fine, as long as it belongs to the solution. Loaded or unloaded - doesn't matter.
When it is not referenced, I get 730 (believe it or not) errors:
If someone who knows what information Visual Studio gains from adding the reference, and /or what files it reads to get such information, I would be glad.
So - why am I so occupied with this? The reason is that I believe, in reality, that Visual Studio needs only one file, for example the _api_Win32_Debug.lib, because this is the only new file I can observe when building the _api project. Then - it should be possible to tell Visual Studio where this file resides, and not use the reference thingie. I have indeed tried to add the path to this file on several places in the properties sheets and the property manager, but no matter what I do, I get errors. -
On 14/02/2014 at 07:18, xxxxxxxx wrote:
What the reference is doing is telling VS what library to use when linking. If you remove it, the linker can't find the object code from the SDK to link to, so you get a zillion linker errors.
You don't need the reference if you set the project up yourslf - you can just set the linker properties to use a specified library file and where that file is located. There are other linker settings though which plugins need, the pages on my site Scott was referring to mentions those (but bear in mind I wrote that back in 2009, it may well be out of date now).
Regarding the framework, who knows why it's there, but you aren't using managed code so you can probably forget it.
-
On 14/02/2014 at 08:16, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Hey Scott, don't follow them too closely... I started out creating plugins absolutely from scratch because I wanted to understand how it was done. But since then I use the method everyone else uses - copy over the examples project into a new folder, delete all references to existing source code and then you have all the project settings correct and ready to go.
Steve
Hi Steve,
I can't stand that copy & delete method of creating plugins. It's like fingernails on a chalkboard to my brain.
I much prefer to make them from scratch using the addition method. And only add exactly what I need.
My (your) addition method just feels like a smarter, more comfortable way to build them to my brain.-ScottA
-
On 14/02/2014 at 09:05, xxxxxxxx wrote:
Does the method I outlined still work for later SDKs? I'd be interested to know if there's anything wrong or missing now we're on to R15, if there is I can always update it.
Steve
-
On 14/02/2014 at 09:39, xxxxxxxx wrote:
I haven't tried it on R15. Because I can't build plugins using V.S. 2013 without also having V.S. 2012 installed. And I refuse to install V.S. 2012 on my computer.
So I'm waiting for proper V.S. 2013 SDK support before trying to build plugins for the newer releases.
But I can't imagine any reason why it would not still work.The instructions I posted here are fairly different from what's on your website. But they are still based on your instructions.
I just organized it a bit differently that was easier for me to follow.
https://developers.maxon.net/forum/topic/7088/8035_some-newbie-questions&KW=Set+Additional+Library+Directories&PID=33341#33341The only big changes for R13++ that I needed to make from R12 was to add the projectsettings.props file from the cinema4dsdk folder to the properties manager.
Just like how we add the DebugWin32.props & ReleaseWin32.props files.
And we don't really need to set up the command Line with: /vmg /vms
Everything else stayed the same as before.-ScottA
-
On 14/02/2014 at 12:17, xxxxxxxx wrote:
Originally posted by xxxxxxxx
What the reference is doing is telling VS what library to use when linking. If you remove it, the linker can't find the object code from the SDK to link to, so you get a zillion linker errors.
Now we are talking
Originally posted by xxxxxxxx
Regarding the framework, who knows why it's there, but you aren't using managed code so you can probably forget it
I will try to forget it. The confusing thing, even when reading pure C++ blogs on the Microsoft sites, the often mention "assemblies". I work with assemblies, almost every day, but that is .Net and C#, not C++. I Guess it is all bad design, sloppy GUI management in Visual Studio.
Originally posted by xxxxxxxx
You don't need the reference if you set the project up yourslf - you can just set the linker properties to use a specified library file and where that file is located. There are other linker settings though which plugins need, the pages on my site Scott was referring to mentions those (but bear in mind I wrote that back in 2009, it may well be out of date now).
Yes, here is the file:
I should have listened to Scott a little more. Ok, the solution is here, as he said:
http://www.microbion.co.uk/graphics/c4d/create_plugins2.htmI followed point 7. and point 8.
It compiles just fine now.Point 9. is about "change Randomized Base Address to Disable Image Randomization (DYNAMICBASE:NO)"
This is Greek to me, have no idea what it means and what it does, and if it is important. So I let it untouched.What this _api project really does is a little unclear. Maybe it is there to speed up builds, right? Or wrong?
In any case, I am MUCH wiser now than when I started this thread, thanks a lot folks
And a big thank you to Steve for his website. In fact, it was this website that put me on the right track, leaving the blind alley called Python, and move on to a real programming language for C4D plugins. -
On 14/02/2014 at 14:24, xxxxxxxx wrote:
Originally posted by xxxxxxxx
It compiles just fine now.
Point 9. is about "change Randomized Base Address to Disable Image Randomization (DYNAMICBASE:NO)"
This is Greek to me, have no idea what it means and what it does, and if it is important. So I let it untouched. What this _api project really does is a little unclear. Maybe it is there to speed up builds, right? Or wrong?
If you look at the linker properties from the R11 SDK example project, it has the property Linker->Advanced->Randomized Base Address set to No (the linker command line switch for that is /DYNAMICBASE:NO). More recent SDK examples leave it set to the default 'Yes' so it doesn't appear to be important. If the plugin links and runs, it's good.
The _api project contains all the object code of the SDK. If you look at the project properties you will see that a Cinema plugin is basically just a DLL - it's nothing fancy. But it is statically linked, so at build time the linker pulls the required object code out of the library and links it to the compiled project object code to form the executable. The alternative would be to dynamically link the plugin code to a library DLL but for what I am sure are excellent reasons, Maxon didn't go down that route.
So you need to tell the linker where to find the object code to link with. If the linker can't find the code for the specified SDK function(s), it generates an error. You can link other libraries to Cinema plugins, take a look around the net and you'll find lots of interesting things you can use. Or you can have your plugin dynamically load other DLLs instead of static linking.
If you didn't use a library you would have to compile and link the SDK functions every time you built your plugin. With a library you build it once and never again, unless the SDK is updated (which happens sometimes with new versions of Cinema, occasionally breaking a plugin in the process) or you clean the project, which deletes the library object code.
-
On 14/02/2014 at 16:01, xxxxxxxx wrote:
Hi Steve, and than you for helping me out here, great explanations on what is going on. Most of this is obvious to me, and (hopefully) all programmers in general, but I am no real C++ programmer yet, so there were thing that made it unclear.
Originally posted by xxxxxxxx
If you didn't use a library you would have to compile and link the SDK functions every time you built your plugin. With a library you build it once and never again, unless the SDK is updated (which happens sometimes with new versions of Cinema, occasionally breaking a plugin in the process) or you clean the project, which deletes the library object code.
This, combined with your points 7. and 8. on your very good website, is what I was asking for when I started this thread. And it is the way I suspected! It is there to save unnecessary build operations, like assemblies are used in C#, and DCU (Delphi Compiled Units) files are used in Delphi. What made it so difficult for me is that I did not know how to omit the _api project and just use the LIB file.
Finally - I have all the answers! At least to the _api project question