Can't change Platform from AnyCPU in Visual Studio 2015

[ghost]

I'm including a Sandcastle project in a VS2015 solution. I set the Documentation Sources to be a csproj file. If I go to the solution configuration the 'platform' for the solution is set to x86 (say) but the 'platform' for the help project is set to AnyCPU and I can't change it, i.e., if I try and select any other platform type and save the configuration, when I look at the configuration again the 'platform' is reset to AnyCPU.

This means that if I build the solution under anything than AnyCPU the help build fail as it's looking in the wrong directory for the assembly.

If I load the build in the SandCastle GUI and change the platform then it builds fine.

I'm running 2016.5.28.0

[EWSoftware]

Visual Studio will only list the configurations and platforms defined in the project. It's possible they got removed from the SHFB project. You can use the configuration manager in Visual Studio to add them back if they aren't there.

[ghost]

Thanks for the reply

They are all there. With the shfb I can only set the platform to whichever
type is listed first in the project file. So if I open the project file,
remove AnyCPU, I can then set the platform to x86, but nothing else.

The other thing I've noticed is that in the Solution Configuration Manager,
when I click on the platform drop down list for the shfb project, there
is no New... option. It lists the platforms from the shfb file but doesn't
let me add others,

On Tuesday, 14 June 2016, Eric Woodruff [email protected] wrote:

Visual Studio will only list the configurations and platforms defined in
the project. It's possible they got removed from the SHFB project. You can
use the configuration manager in Visual Studio to add them back if they
aren't there.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#306 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ANa5YQCvv-zTZHJuHtAkyfimw4xrSYmZks5qLvoegaJpZM4I1Nlg
.

Kevin

[EWSoftware]

I'm not sure why the platform cannot be changed or edited. As far as I know it used to work. It could be that the older MPF project system isn't working as well in VS2015. In my test, the documentation project's platform didn't make any difference. Even if left set to AnyCPU, it still picked up the correct x86 configuration assembly.

If that's not working for you, you can explicitly set the configuration and platform on the documentation source properties. When those properties are set, it ignores the values for the containing SHFB project.

[ghost]

The problem I'm seeing is that our build server builds for release and
debug with x64 and Win32, so 4 configurations.

I'm trying to set the project source to be the the project file (and not
the DLL/XML file) and as the build cycles through the configurations it
fails as it cannot find the output for the project in the expected
directory.

The symptom I saw in VS2015 was the inability to change the platform for
the shfb proj file and I'm assuming this is what is causing the build
configurations to fail (it's certainly the same error).

I've 'fixed' this for now by having the help build only for one
configuration and fixing the output path for that,

Kevin

On 15 June 2016 at 00:22, Eric Woodruff [email protected] wrote:

I'm not sure why the platform cannot be changed or edited. As far as I
know it used to work. It could be that the older MPF project system isn't
working as well in VS2015. In my test, have the documentation project
didn't make any difference. Even if left set to AnyCPU, it still picked up
the correct x86 configuration assembly.

If that's not working for you, you can explicitly set the configuration
and platform on the documentation source properties. When those properties
are set, it ignores the ones for the containing project.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#306 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ANa5YbARacHFnnmflvWoRujPi_SfDb21ks5qLzemgaJpZM4I1Nlg
.

Kevin

[EWSoftware]

Building the help for each configuration is probably unnecessary unless there are actual differences in the API based on the configuration. Limiting it to one configuration is probably the best solution.

[ghost]

Sure, on the build server that's true. Of course the problem is I have no
control over the configuration that a developer would use (in particular 64
bit vs 32 bit) so I'd like to be able to be able to build the help for any
of the configurations and it doesn't look like I can do that at the moment.

TBH that's probably not going to be an issue right now so it's something I
can live with,

thanks

On 15 June 2016 at 16:20, Eric Woodruff [email protected] wrote:

Building the help for each configuration is probably unnecessary unless
there are actual differences in the API based on the configuration.
Limiting it to one configuration is probably the best solution.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#306 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ANa5Ye7kFdjWMYAZkrnndpoa7OQ5H_-Bks5qMBhIgaJpZM4I1Nlg
.

Kevin

[eykh]

Hello,

this is bugging us as well, because we have to hickadihack on our build server to build the documentation files from x86 assemblies.

Open Configuration Manager

Change platform to x86 and click Close

Open Configuration Manager again

Hmm? Strange...

Repeat this as often as you like...

Any help would be greatly appreciated.

Thank you
Alex

[EWSoftware]

I haven't been able to find out why this stopped working. As noted above, you may be able to work around it by explicitly setting the platform and configuration to use on the documentation sources.

[eykh]

After reading it the second time, I understood what you mean, thank you!
It helped my one step further, but pushed me into the next issue: 288

I will put my further comments there.

[dparvin]

I can tell you that this problem is still happening in VS 2019.

[msedi]

The same here. When I embed the property in my project and simply set it to

<Platforms>x64</Platforms>

I cannot load the project anymore. If I completely remove it it shows only AnyCPU, which I don't want
If I set it to

<Platforms>AnyCPU;x64</Platforms>

it works.

[SteveDunn]

I experienced the same problem. For me, the problem stemmed from the fact that I changed a lot of projects from PCL (.shproj) to libraries (.csproj). Unless the project type GUID in the .sln file is changed, then VS won't change anything.

I simply replaced D954291E-2A0B-460D-934E-DC6B0785DB48 with 9A19103F-16F7-4668-BE54-9A1E7A4F7556 in each .sln.

More on project type guids here

[dbowser]

Still happening with VS2022 !
msedi's Solution worked though!

[duyn9uyen]

AnyCPU;x64

Worked for me too! The GUI seems buggy.