Solved R25 - Compile plugin issue

Hi Guys,

Trying to compile our plugins for R25 but running into some visual studio issues.

Using the latest Visual studio and project tools.

Severity Code Description Project File Line Suppression State
Error MSB8013 This project doesn't contain the Configuration and Platform combination of Debug|Win32. customcommandline C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets 436

Hopefully you guys see what is going on!

Thank you!

Hello @jwzegelaar,

thank you for reaching out to us. Your screenshot, build error message, and the structure of the solution explorer as well as the fact that there are no frameworks in your solution explorer indicate that you have:

1. Either opened a project in your solution instead of the solution itself. So, if you have a directory \myFancysolution\, then there should be a file \myFancysolution\plugins\project\plugins.sln, which is the one you have to always open to build or debug a solution. Your screenshot does cut unfortunately the title bar and with that the file path of the opened "thing", but it looks very much like that you have opened something along the line of \myFancysolution\plugins\customcommandline\project\customcommandline.vcxproj. I.e., a .vcxproj project file instead of a .sln solution file.
2. Or that your solution has been somehow corrupted. In this case I would recommend rebuilding the solution with the project tool. There are two projectdefinition.txt files which your solution should contain at least. One in \myFancysolution\plugins\project\ which should define the build targets (Win64, OSX) and the included projects (at least your customcommandline project) and one in \myFancysolution\plugins\customcommandline\project\ which must include the frameworks your project is using, again the target platforms, the project type (likely DLL in your case) and other things. More information on the projecttool and its features can be found in the Project Tool Help Page.

Cheers,
Ferdinand

Hello @jwzegelaar,

thank you for reaching out to us. Your screenshot, build error message, and the structure of the solution explorer as well as the fact that there are no frameworks in your solution explorer indicate that you have:

1. Either opened a project in your solution instead of the solution itself. So, if you have a directory \myFancysolution\, then there should be a file \myFancysolution\plugins\project\plugins.sln, which is the one you have to always open to build or debug a solution. Your screenshot does cut unfortunately the title bar and with that the file path of the opened "thing", but it looks very much like that you have opened something along the line of \myFancysolution\plugins\customcommandline\project\customcommandline.vcxproj. I.e., a .vcxproj project file instead of a .sln solution file.
2. Or that your solution has been somehow corrupted. In this case I would recommend rebuilding the solution with the project tool. There are two projectdefinition.txt files which your solution should contain at least. One in \myFancysolution\plugins\project\ which should define the build targets (Win64, OSX) and the included projects (at least your customcommandline project) and one in \myFancysolution\plugins\customcommandline\project\ which must include the frameworks your project is using, again the target platforms, the project type (likely DLL in your case) and other things. More information on the projecttool and its features can be found in the Project Tool Help Page.

Cheers,
Ferdinand

It is a bit unfortunate that the project tool does not generate an .sln file along with the .vcxproj.

While that makes sense for a large project, where several projects are in the same solution, and usually have to be built together, the normal plugin developer usually only has one project file, and the frameworks. They mostly have the solutoin file in the same folder as the project file. Having to effectively create the solution manually is quite error prone, as there are dependencies and references to to be added.

If there was an option to generate both, the .vcxproj and the .sln file, it would make it easier for plugin developers to get going.

Cheers,
Frank

Hey Frank,

I agree, but the problem is that projecttool also does play an automated inhouse-tool role, as you might still be aware of, and there these additional files are likely not welcome. But I will try to find a place for this idea, which then would have to be an option of the tool on a per project basis.

Cheers,
Ferdinand

@ferdinand said in R25 - Compile plugin issue:

Hello @jwzegelaar,

thank you for reaching out to us. Your screenshot, build error message, and the structure of the solution explorer as well as the fact that there are no frameworks in your solution explorer indicate that you have:

1. Either opened a project in your solution instead of the solution itself. So, if you have a directory \myFancysolution\, then there should be a file \myFancysolution\plugins\project\plugins.sln, which is the one you have to always open to build or debug a solution. Your screenshot does cut unfortunately the title bar and with that the file path of the opened "thing", but it looks very much like that you have opened something along the line of \myFancysolution\plugins\customcommandline\project\customcommandline.vcxproj. I.e., a .vcxproj project file instead of a .sln solution file.
2. Or that your solution has been somehow corrupted. In this case I would recommend rebuilding the solution with the project tool. There are two projectdefinition.txt files which your solution should contain at least. One in \myFancysolution\plugins\project\ which should define the build targets (Win64, OSX) and the included projects (at least your customcommandline project) and one in \myFancysolution\plugins\customcommandline\project\ which must include the frameworks your project is using, again the target platforms, the project type (likely DLL in your case) and other things. More information on the projecttool and its features can be found in the Project Tool Help Page.

Cheers,
Ferdinand

Hi Ferdinand,

The solution was number 1, meaning just my lack on knowledge haha. I do this every year but was so sure i needed the open the file inside the plugin folder instead of the project folder.

Will remember for next time:)

Thank you for your time!

@fwilleke80 would indeed also make more sense to me:)

Hi Ferdinand,

I agree, but the problem is that projecttool also does play an automated inhouse-tool role, as you might still be aware of, and there these additional files are likely not welcome.

I remember very well. I just didn't want to spoil any details here, without anyone from the SDK team mentioning it first
It does make sense in the Maxon context where one solution hosts a multitude of projects. Just for plugin developers, it usually results in having the Project Tool generate a nice project, but then having to build the solution manually, with all included framework projects, build dependencies (even between the framework projects), and references. That's error prone, generates more support noise for you, and annoys the plugin developers

But I will try to find a place for this idea, which then would have to be an option of the tool on a per project basis.

I think there could be a very easy solution (well, at least it sounds easy... things are rarely as easy as they look on the outside, I know): The projetdefinition.txt specifies what type of file should be created:

For projects:

// Type of project - can be [Lib;DLL;App]
Type=DLL

For solutions:

Type=Solution

So, why not just allow something like this:

Type=DLL,Solution

It could simply do two complete runs then, one for each element in the enumerated Type. It would first do a normal run for Type=DLL, and then another one for Type=Solution. That would just require Project Tool to split the Type string by comma, and then iterate over the split parts and do one complete run for each of them.

That way, plugin developers could have a much improved workflow when creating new projects, and maxon developers wouldn't be bothered with unwanted files.

Currently, I still check in all my plugin project files for all Cinema 4D releases I support, into the source management, because regenerating them on the fly with Project Tool (which is, as far as I remember, the original idea behind it) is just way too much work.

Cheers,
Frank

Hello @jwzegelaar,

without any further questions, we will consider this topic as solved by Tuesday, November the 2nd and flag it accordingly.

Thank you for your understanding,
Ferdinand