_MSC_VER (Compiler Version) Error [SOLVED]

On 23/09/2014 at 03:25, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R16 
Platform:   Windows  ;   
Language(s) :     C++  ;

---------
Dear Supporters

we are currently updating our plugin to the R16 SDK from R15 (R15 builds work fine).

We have updated the R16 SDK/framework to use VS2013 and the v120 toolset. The SDK/framework builds are also fine. We are using the Debug target and the 64bit version.
If we build our plugin (we have updated all includes etc.) we are experiencing a linker error during linking of the "cinema.framework_Debug_64bit.lib" with our plugin.

error LNK2038: mismatch detected for '_MSC_VER': value '1700' doesn't match value '1800' in PluginName.obj 

It's strange because we are using the v120 Toolset in all of the involved projects. Intellisense is also telling us the _MSC_VER is 1800 in both, c4d sdk/framework and our plugin (although we don't trust it that much, but a debug build with printing the compiler version is also correct.)

• Do you guys use precompiled headers with an older compiler version (even the flag for not using them is set)?
• You have stated, the SDK is very well compatible with VS2012 and newer in the documentation, is this also the case with updated VS2013 from VS2012 projects?
• Are you setting the _MSC_VER during the compilation of the framework manually? (we could not find anything like that either in the sdk src)
• Is your Intelcompiler using a different vc++ compiler version? Sadly we have no access to the compiler you used and we believe that's not really a problem but anyway.

Did i miss anything? Every tip is very well appreciated.

We really want to use VS2013. So downgrading for 2012 is not really an option for us right now.

Extension:

• What is the meaning of the LibDebug, LibRelease and LibIntel targets? Is this something special to consider? (We tried using both libraries, LibDebug and Debug. No effect.)

Thanks for your time in advance and have a nice day!

*Edit*
I just quickly portet it (the plugin) back to VS Express 2012. Works fine. So it's a compiler problem?

On 23/09/2014 at 05:24, xxxxxxxx wrote:

Have you cleaned all existing build outputs or pressed "Rebuild"?

On 23/09/2014 at 05:28, xxxxxxxx wrote:

We have cleaned everything. Manually and cleaning via VS "Clean Solution" and also used rebuild. Did not change anything.

So the solution came with changing all the toolsets back to VS2012 v110. For both, SDK and plugin. I will try again to build it with v120 later.

Did some of you also experience this? The ability to change properties of a project with a x64 target is getting lost when using v110 tool sets in VS2013. The only options left are the "Code analysis" in the properties window.

*Edit*
So, i tried it again. There is no way to compile the sdk and our plugin with vs2013 yet (or at least run our plugin with a v120 toolset compiled sdk). Maybe it's our plugins fault, we are diving into this again. So we have to work with vs2012 for now.

On 09/10/2014 at 15:26, xxxxxxxx wrote:

Hi Oukie,

I've had similar problems, as updating file paths during a VS version upgrade can be messy.  Several settings, custom paths, etc. may cause this type of problem.  I'd like to give you a hand, as you're obviously in a jam.

Lets check the most likely possibilities in order, since it can be due to multiple settings at the same time:

All projects in a solution must be set to VS2013 separately

1. Load your solution in VS2013 and make sure it's set to the Debug / x64 solution configuration / platform set.

2. Set the Platform Toolset to VS2013 (v120) for every project in the solution by selecting each one in the Solution Explorer and going into Properties / General and clicking Apply. Unfortunately, there's no way to set it for the entire solution in one spot.

3. Try a rebuild, the above may have fixed it if any were not correct.

4. A reminder to do this for all of your solutions affected by the compiler upgrade.

**All paths must be set to VS2013 and the Windows SDK version included with it (8.1A)
**
If the steps above did not resolve the issue, try the following for each project in the solution:

1. Go into Properties / VC++ Directories

2. For 'Library Directories', check that the following are found in the list:
$(VC_LibraryPath_x64);$(WindowsSDK_LibraryPath_x64);

3. If they are found in the list, verify that any other entries are correctly formatted and direct the compiler to VS2013 compiled .lib files.  You might discover one or more hard coded paths require modification.

Note: When the platform is set to VS2012 (v110), the entries will be the following instead:
$(VCInstallDir)lib\amd64;$(VCInstallDir)atlmfc\lib\amd64;$(WindowsSDK_LibraryPath_x64);

You should see all the VS related paths in "VC++ Directories" change when applying a platform toolset change.  Any you've added yourself, such as for 3rd party SDKs, have to be updated manually.

4. If you changed anything, try rebuilding at this point, it may have fixed the issue.

5. If nothing changed or the changes did not resolve the issue, click on 'Library Directories' and click on the drop down button that appears on the right.

6. A box should appear just underneath.  Click on <Edit...>.

7. A box appears, listing the library directories.  Click on the "Macros>>" button in the lower right area.

8. Verify that the $(VC_LibraryPath_x64) macro is pointing to directories under the 'Visual Studio 12.0' install path.  (VS2013 is version 12.0)

9. Verify that the $(WindowsSDK_LibraryPath_x64) macro is pointing to "..\Windows Kits\8.1\lib\winv6.3\um\x64"  (Windows SDK version 8.1A comes with VS2013)

10. If any of the above had to be modified, try rebuilding, the issue may have been fixed.

If the problem persists, it would be a good idea to check the other directory paths under VC++ Directories when the platform is set to VS2013 ("Include Directories" for the headers, etc.).  The macros that start with "VC_" must point to the 12.0 set of VS directories, and the macros that start with "WindowsSDK" must point to the "..\Windows Kits\8.1\.." or "..\Microsoft SDKs\Windows\v8.1A\.." directories.

If anything above fixes the problem, you have to repeat it for each configuration / platform you want to use (ie release / x64, etc.).  You can ignore the Intel ones if you're not going to use them.

If you verified all of the above for every project in your solution(s), and still can't compile with VS2013, please post the results, and we'll move forward from there.

I hope the above helps!

Joey

On 13/10/2014 at 00:40, xxxxxxxx wrote:

@j_gaspe

First: Thanks a lot for taking the time to write this down! I really appreciate it and i might think some people really can need this.

So: I tried all of the above and unfortunately it did not help to solve the problem. The "Library Directorys" as well as the Makro paths etc. are all correct. I have also checked point 11 ;).

Just to clarify we are able to build the C4D SDK in 2013 very well. It's just the problem our plugin cannot build in VS2013 with an SDK built in VS2013. If we are building both in 2012 it's strangely enough okey. So i expect our plugin is the cause of alle trouble if there are no prebuilt binarys in the C4D SDK.

I also have to tell you here we are not only working on a plugin in c++. We are using a complete project (we have developed some time ago and are now trying to update it) that allows us to write c# plugins for c4d.

So we are trying to fix this in the upcoming days and i will inform you if we have new perceptions. So long i want to say thank you for your time again.

- Oukie

On 14/10/2014 at 08:28, xxxxxxxx wrote:

Hi Oukie,

No problem about helping you out!  If the above didn't reveal anything, I think the issue is narrowed down to:

1. A subtle issue in your project file(s).

and/or

2. Your environment variables are not correct. In particular, your paths to the various files you need to compile (includes, libs, etc.) may not be quite right.  The ordering of each entry is often the problem, as the searches are done in order of precedence.

If you don't mind sharing them with me, I can comb through them to see if they could be the culprit:

- The project file(s) in question end in .vcxproj.  I shouldn't need any of the other project related files, as only the .vcxproj files contain paths.

- The environment variables used in Visual Studio IDE should match with those found in the 'VS2013 x64 Native Tools Command Prompt'.  To get them, you launch the command prompt, and type 'set' <enter>.  The text that appears are the variables and their values, so they can either be highlighted and copy/pasted into a file, or you can go into a directory with write access, such as a 'temp' directory in the root and output them to a file (otherwise you'll get 'access denied' when attempting to create env.txt) :

example:

cd\
md temp
cd temp
set > env.txt

The file env.txt will contain the environment variable data that you can share with me.

Please let me know of any developments, because as you state, this is a common but poorly documented issue when upgrading projects to a new VS compiler version.

Joey

On 15/10/2014 at 00:52, xxxxxxxx wrote:

Hello j_gaspe,

we figured it out yesteday. The problem - what a joke - was a "read only" on the c4d plugins examples folder in windows explorer. Everytime we upgraded the project and checked all variables in vs13 (as you told me up there) it seemed to be okey. Then i saved all the changes and this was okey, at least VS13 told me so. But everytime we build it, vs13 would use the v110 toolset non the less in the background. We fixed the problem by removing "read only" for the examples SDK folder.

So as this is a very specific behavior i have to try this on another machine these days. But on my windows 8.1 prof. this was the case. Perhaps i should not have installed c4d in the Program Files folder. Do you know this behavior is intended (if so i can really see the good intentions behind this)? It would make sense to keep a basic version of the SDK but this was a real pain ;).

So, thanks for all your help. If i will get any more useful information related to this, i will post it here to help other devs.

Add:
One more, always use the props files maxon is providing. It's far more comfortable now with them.

On 15/10/2014 at 07:31, xxxxxxxx wrote:

Hi Oukie,

I'm glad to hear you figured out the problem.  It really didn't look like a read-only directory issue, but it makes sense when you describe it.  Since it doesn't warn you, VS assumes you can write in the directories you work in.  Since Windows Vista, the program files directory (or both meant for 32/64 bit apps in 64 bit editions) is set as read-only for security reasons.  It is actually a good place, if not the right place, to install Cinema 4D, but comes with the read-only issue you describe.  It can save you if you were about to modify something you wanted to keep as a backup, if you're looking for a silver lining.

Note: Since you might post more info, I'll set the thread as resolved but won't make it read-only.

Joey Gaspe
SDK Support