VS2015 update 1 "There are no property pages for the selection."

Visual Studio 2015 Update 1

Windows 10

Using the latest available version of JUCE.

here's the .jucer project: http://www.elanhickler.com/transfer/reaper_juce_example.jucer


Problem: I cannot open properties of the reaper_juce_example.vcxproj in visual studio because I get error "There are no property pages for the selection."


I tried WinMerge with the generated vcxproj vs a blank project and tried to manually edit it, but that failed as well. I couldn't tell what difference there was which would cause this problem.

What about the VS2015 projects for all our demos? Do they work for you?

examples\Demo\Builds\VisualStudio2015\JuceDemo.vcxproj works

JuceDemo works even after I use introjucer to regenerate the files.

figured it might be helpful to have the vcxproj as well: http://www.elanhickler.com/transfer/reaper_juce_example.vcxproj

By switching the configuration mode to release I was able to get it open... once or twice. I can't find any pattern to getting the properties window to show. I tried deleting the project from the sln and reloading it, that seemed to work a few times, but now it's not.

Don't really know, the project looks ok to me.. Haven't seen anything similar ourselves, and have no idea what that error means. Perhaps it can't find your main.cpp file or something?

animated gif to the rescue? (I know the project looks a bit weird, e.g. the juce files are all over the place and I added the project to the sln manually, ignore that bit. The problem occurs with freshly-made VS projects via introjucer for this particular project.)


Sorry, I have no idea at all what's going on there!

I did some more messing with WinMerge, I was able to get the properties page working in 2 out of 4 configurations (release x64 and debug win32). If I spent many hours learning exactly how the Visual Studio expects the vcxproj xml to be formatted maybe I could probably figure out exactly what introjucer is doing wrong. But then I said, "well wait a minute, what if the .jucer project is corrupt leading to a bad vs project?" I just tried creating a .jucer project from scratch and it works! Looks like the original .jucer project is corrupt.

from winmerge comparing old and new .jucer files:


        <CONFIGURATION name="Debug" winWarningLevel="4" generateManifest="1" winArchitecture="32-bit"
                       isDebug="1" optimisation="1" targetName="NewProject"/>
        <CONFIGURATION name="Release" winWarningLevel="4" generateManifest="1" winArchitecture="32-bit"
                       isDebug="0" optimisation="3" targetName="NewProject"/>


        <CONFIGURATION name="Debug" winWarningLevel="4" generateManifest="1" winArchitecture="x64"
                       isDebug="1" optimisation="1" targetName="reaper_juce_example"
        <CONFIGURATION name="Release" winWarningLevel="4" generateManifest="1" winArchitecture="32-bit"
                       isDebug="0" optimisation="3" targetName="reaper_juce_example"/>

Notice how the bad version specifies x64 and 32-bit.

Without going into crazy detail the problem has something to do with how the configurations are specified in the vcxproj xml. I don't know enough about how jucer creates vcxproj to know whether jucer is potentially messing up the vcxproj xml. I just have an idea that the problem is due to the fact that in the bad version has debug as only x64 and release as only 32-bit, and this mismatch is somehow corrupting the vcxproj xml.

...ok just did a test... and yes it looks like replacing "32-bit" for "x64" solves the problem for the original (bad) .jucer project!

Sooo... how do you specify x32/x64 in introjucer? (EDIT: Oops, found it, I didn't see there was a scrollbar)

p.s. what is a synbol?

We use 64-bit configurations all the time, and never had this problem.. Maybe VS is just expecting there to be a 32-bit debug config, and if there isn't, it gets confused?

Here's how I use 32-bit and 64-bit configuration for VS: http://www.juce.com/comment/319349#comment-319349

Never had a problem. You just have to remember that in VS, whenever you select Debug/Release you should also select x86, and whenever you select Debug64/Release64 you also select x64, otherwise bad things happen.

As for a debug synbol, I think this is infornation that expresses which progranning-language constructs generated a specific piece of nachine code in a given executable nodule :-)

Simply stated, I believe the problem is this: If release/debug has mismatched platforms, introjucer will generate an illegal vcxproj  the vcxproj badly. It's not visual studio getting confused, it's actually a badly written xml. The generated vcxproj xml has some weirdness.

Ok, playing with configuration manager in Visual Studio. It looks like it's impossible, with visual studio to have a mismatch of x32/x64. In other words, you must have x32 debug/release OR x64 debug/release OR all at once. It seems that it is illegal/impossible to have a mismatch.

Edit: Haha, thanks timur.

I’m having the precise same problem. Was working on the mac version or my plugin for a while, made a few changes, then wanted to go back to working on windows when I get “There are no property pages for the selection”. Tried to undo all the changes in the .jucer file since last time it worked, but that didn’t help.

Edit: Visual Studio 2015, Windows 10, Projucer less than a month old.

Upgrading to Visual Studio 2017 RC solved the problem for me.

It looks like it’s impossible, with visual studio to have a mismatch of x32/x64. In other words, you must have x32 debug/release OR x64 debug/release OR all at once.

It has always worked like that on Visual Studio. Having separate configurations for 32-bit and 64-bit just doesn’t work. Would it be possible to have a “both 32 bit and 64-bit” option for the Architecture field in the Visual Studio exporters?