Why do I need a Reference in Visual Studio

On 13/02/2014 at 13:11, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   13,14,15 
Platform:   Windows  ;   
Language(s) :     C++  ;

---------
Are you using Visual Studio? Perhaps you can help me with this.
I can compile my plugins just fine, so the reason for this question is that I also want to know more about the settings I need. In order for it to work.

The question is: Why do I need the reference? If I remove it, I get a ton of errors.
I am used to references in C#, I use them all the time. But why in C++?
I thought, that in C++, the compiler will read and compile *.h and *.cpp files. And also digest precompiled files, like *.dll and *.lib and *.obj files. But why can't I just tell the compiler where those files are? What is the deal about having to load the _api project in Visual Studio, and link to this project?
Why is the .Net version mentioned at all - hey - this is C++???

On 13/02/2014 at 14:37, xxxxxxxx wrote:

I've never used the Maxon method of copying plugins then deleting things from it.
I don't like that method for a bunch of reasons. But the main reason I don't like it is because it includes the API. Which bloats my files.

If you want to get more intimate with V.S. And learn more about the compiler settings. Then I recommend building plugins by hand the way I do it.
It's not hard. But there's several steps to it.
I posted it once a while back for someone else:
https://plugincafe.maxon.net/topic/7088/8035_some-newbie-questions&KW=Set+Additional+Library+Directories&PID=33341#33341

A nice side effect to creating plugins from scratch like this is that you learn about how to use a lot of the V.S. settings.

I haven't visited Steve's website in a long time. So I don't know if he's changed things.
But his site is where I first learned about creating plugins from scratch way back years ago.
Steve's site: http://www.microbion.co.uk/index.htm

-ScottA

On 13/02/2014 at 15:02, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I've never used the Maxon method of copying plugins then deleting things from it.
I don't like that method for a bunch of reasons. But the main reason I don't like it is because it includes the API.

Hi Scott, I have no idea about what you say here. Copying.. what? Deleting.. from what?

Originally posted by xxxxxxxx

Which bloats my files.

For me, this is absolutely uninteresting, since the files in any case are so small (the cdl and cdl64 files)

I just like to know what Visual Studio is using, what files, when I add the _api project as a reference. Exactly what files are they, why can't I just add a path to those files, why must the project be referenced, and why on earth is a .Net Framework version mentioned at all, in a pure C++ project(see my image above).
These are currently my questions, I will build a plugin from scratch when I find the knowledge gained doing it will justify the time spent doing it

On 13/02/2014 at 15:40, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I just like to know what Visual Studio is using, what files, when I add the _api project as a reference. Exactly what files are they, why can't I just add a path to those files, why must the project be referenced

Instead of adding the API in my plugins. I link to them using "Additional Dependencies".
Those references sound like what you're asking about.
But maybe we're talking about different things?

Adding the API to the solution serves no purpose.
Or to be more accurate. I should say it doesn't add anything I've ever needed.
And it just makes the solution files bigger. So I prefer to link to them with references instead.

-ScottA

On 13/02/2014 at 16:55, xxxxxxxx wrote:

Originally posted by xxxxxxxx

But maybe we're talking about different things?

Perhaps. Let me rephrase my question:
By adding C:\Program Files\MAXON\CINEMA 4D R14\resource\_api to the  Additional Library Directories  property, VS knows where to find c4d_basedocument.cpp, c4d_basedraw.cpp, c4d_baselist.cpp and so on, you get the picture.
At this stage, Visual Studio knows both where my own plugin files are, and where the SDK header and cpp files are.

Fine.

But is does not build yet, I get compiler errors.
What is still missing??

To get rid of the compiler errors, I need to add the _api project as a reference.
What information do I give Visual Studio by adding the _api project as a reference????
Do I tell Visual Studio about certain directories this way, so that it finds other, additional files? What information is given, that can't be given the usual way, by just entering a directory path?

On 13/02/2014 at 17:43, xxxxxxxx wrote:

Oh I see what you mean now.
In my plugins. I don't have that api reference in the "Framework and references" section of the compiler settings.
Mine is empty. Because I don't like to use an _api project in my plugins.

Someone else will have to help you on that one.

-ScottA

On 13/02/2014 at 17:54, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Oh I see what you mean now.
In my plugins. I don't have that api reference in the "Framework and references" section of the compiler settings.
Mine is empty. Because I don't like to use an _api project in my plugins.

Well, I neither like, nor dislike it being there.
It just has to be there to avoid compiler errors.
And I want to know what purpose it serves.

Originally posted by xxxxxxxx

Someone else will have to help you on that one.

Well, you know how to deal with it not being there, which is more than I do. And knowing how to avoid using it, implies (at least to some extent) that you also know the reason it is there, by default in the SDK samples. (My plugins are using the SDK samples as a template, as I was adviced to do when I started writing plugins.

On 13/02/2014 at 18:36, xxxxxxxx wrote:

Well.... I learned how to create plugins using the "no _api" method from my first day. First plugin.
I've never actually built a plugin the "approved" Maxon way. Not even once.
So I really don't know all that much about why, or what reason, Maxon includes that _api stuff.
There might be a reason for it. But I've never seen a need for it personally.

All I know is that making plugins from scratch without the _api. My "Framework and References" section is not used. And empty.
Other than liking that it keeps my solutions smaller this way. I don't do it that way because of some special knowledge I've gained.
I do it that way just because it's my personal work habit.

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. :slightly_smiling_face:

-ScottA

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. :slightly_smiling_face:-ScottA

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

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://plugincafe.maxon.net/topic/7088/8035_some-newbie-questions&KW=Set+Additional+Library+Directories&PID=33341#33341

The 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.htm

I 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 :smile:
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 :relieved: