Hot-Swapping not working with VS 2017 + v140 toolset (w/o VS 2015 IDE installed)

[benjaminbojko]

This block is amazing! I haven't gotten around to actually integrating it into one of our active projects, but got the samples running and oh boy, this will change a lot for us.

One thing I stumbled over was that I was trying to get the sample running in VS 2017 Community Edition (latest version) with the 2015 toolset installed (without installing the full VS 2015 IDE). The project would successfully recompile on changes without error, but the running app wouldn't update.

Once I installed VS 2015 Community Edition (also latest version) and after another minor issue (see blow) the app successfully recompiled and reloaded.

Do you know of any compatibility issues between the v140 toolsets or runtimes available in VS 2017 vs 2015?

A bit more of a trivial (?) problem was that when switching between VS 2015 and 2017 I had to manually delete the proj/build/ folder because otherwise VS would keep complaining about missing PCH files (cleaning the solution via Build / Clean Solution wouldn't do the trick):

1>/../src/Test.cpp: fatal error C1083: Cannot open precompiled header file: '[...]\Cinder-0.9.2\blocks\Cinder-Runtime\samples\ImGui\vc2015\build\x64\Debug_Shared\intermediate\runtime\Test\build\Test.pch': No such file or directory
1>/build/x64/Debug_Shared/intermediate/runtime/Test/TestFactory.cpp: fatal error C1083: Cannot open precompiled header file: '[...]\Cinder-0.9.2\blocks\Cinder-Runtime\samples\ImGui\vc2015\build\x64\Debug_Shared\intermediate\runtime\Test\build\Test.pch': No such file or directory

Once I had the 2015 IDE installed and the project build dir manually wiped, I could run the app in both VS 2015 and 2017, so ultimately the only real price to pay was to install the full VS 2015 IDE, but would love to help investigate this more further (or at least point it out for other VS 2017 users).

[richardeakin]

Hey Ben, happy you're getting into this.

I've seen this too, where I needed to delete the build folder. Especially for the time being if anything updates, paths might be looking at the wrong place. In fact I just moved from VS 2015 to VS 2017 and it didn't work ('.pdb locked' error) until I deleted the build folder and re-ran. Working great now. This is using v140 toolset, Debug_Shared 64bit.

[benjaminbojko]

@richardeakin Ah good to hear that I'm not the only one seeing this. One thing that was peculiar was that I didn't have the VS 2015 IDE installed, just the v140 toolset for VS 2017. That's what was breaking it for me and while the source code would recompile, the app wouldn't update and the hot-swapping would (presumably) fail silently. Once I installed the 2015 IDE everything worked smoothly (minus that build cache issue). I imagine this one a little more hairy to test since now I'd have to uninstall the 2015 IDE again, but if anybody can give me pointers to what to watch for/how to narrow it down I'm happy to help out.

[simongeilfus]

Thanks for trying that out Ben!

The Build / Clean Solution and the fact that you do need to clean things manually sometimes is a known thing. We should probably do some booking keeping around what temporary files are created and should be deleted. I can also see something like rt::Compiler::instance().cleanSolution() be useful.

Unfortunately I don't see a way to integrate this with Visual Studio Build / Clean Solution without modifying the solution / project settings. But that would be lovely.

I have not done a lot of work to support VS 2017 yet, but in theory whatever can be built with Visual Studio can also be built with rt::Compiler as it's using the same process internally. @richardeakin recently added a more verbose mode that should print out some more information to the console, which hopefully could help tracking this down. Unfortunately at this point I could see quite a few different explanations so I'd need to be able to reproduce that and have a look to that log. If you happen to be able to test that on your end and want to post the log here, that would probably be a good start.

I'll try to find some time next week to add some notes about this in the (really rough) README.md .

[simongeilfus]

@benjaminbojko As you can see here compiling the code with VS 2017 force the platform toolset to be v141. I should probably parse that from the vcxproj instead and see what toolset you are actually using in your project. In the meantime you could try to force that to v140 by setting platformToolset = "v140";.

You can also see if this line matches to the right vcvarsall.bat on your machine. I think that ultimately this part should be replaced by searching the registry for the actual installation path, which would work any custom installation.

Let me know if that helps.

[richardeakin]

@simongeilfus When you build with VS 2017 and use PlatformToolset = v140 I think it is actually picking the right one, which can be seen in this screenshot (not that the debugger stepped to the line setting the string to "v140"):

My guess is this is an intellisense bug, where Visual Studio's highlighting is happening from it's default toolset, v141. Though parsing out the PlatformToolset from the .vcxproj wouldn't be hard at all, I think you can't reasonably set it to anything other than one your .exe was compiled with.

I did run into the 'permission denied' problem when testing with vs 2017 again though, I'll paste that error message here:

1>D:\code\cinder\cinder-master\blocks\Cinder-Runtime\samples\Basics\src\Basics.cpp : fatal error C1083: Cannot open compiler generated file: 'D:\code\cinder\cinder-master\blocks\Cinder-Runtime\samples\Basics\vc2015\build\x64\Debug_Shared\intermediate\runtime\Basics\build\Basics.obj': Permission denied
1>cl : Command line error D8040 : 
1>error creating or communicating with child process

Once again, deleting the build folder and retrying fixed it.