how to get target platform 8.1 back with visual studio 2015 after installing studio 2017?












0















I have existing projects that run (need) visual studio 2015 and target
platform 8.1. I also have projects that need visual studio 2017.
So i recently installed 2017. This worked fine, for some time, for the new 2017-based projects.



Now i need to do a bug fix on the 2015-based projects.



What i see in the IDE in Properties->General->Target Platfrom is 10.0.10586.0.
One can see a dropdown that lists "10.0.17134.0 and 8.1". Selecting 8.1 works for a second but the selection is then not taken. It jumps back to 10.0.10586.0.



Without 8.1 the whole windows.h include files are not found, compilation doesnt work.



Now the fun part - i still have yet another (tiny) project that uses 2015.
This project does list 8.1 as target platform. And it compiles.
So my overall machine install must be good.



Somehow installing 2017 must have messed a part of my 2015 projects, but
not all. This looks really bizare as the .vcproject shows as unchanged in tortoisesvn.



Does anybody know how to verify environment variables etc that are used by visual studio with respect to the sdk ? Or does Microsoft use yet another database to
store project related extra information ?



EDIT



Here is my solution : I did create a new project from scratch. This has 8.1 as default and works fine. I then opened both the old .vcproj file and copied the



<ItemGroup>
<ClCompile Include="myfile1.cpp" />
<ClCompile Include="myfile2.cpp" />
<ClCompile Include="etc.cpp" />
</ItemGroup>


This way at least all my source files can be rescued to the new project file in a minute. The xml syntax for ItemGroups is clean. For all other settings i used the IDE. Opened 2 session of visual studio and copied manually the settings for libs, paths, flags etc. Now it works again. Doing a windiff on both .vcxproj files doesnt give a clear answer.



The new project does have entries like :



 <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<PlatformToolset>v140</PlatformToolset>
<WholeProgramOptimization>false</WholeProgramOptimization>
<CharacterSet>Unicode</CharacterSet>
</PropertyGroup>


I didnt test to retrofit this to the old vcxproj since i am running out of time,
and i have a working solution now. I double checked - my old vcxproj had been indeed under source control, so it did -not- change. The most likely candidate is now Cuda.



Cuda has very nice and helpful extensions for visual studio.
my squence had been



september - visual studio 2015 works
october - added cuda 9, worked with cuda. Did not touch projects from september. Most likely the problem happened here, but i didnt see because i do not builds every day/week.
Later in october i installed Unreal Engine & Visual Studio 2017. This looked
good back then, but i again didnt build the vs 2015 projects. So
there is a possibility that this had an impact.



Last but not least i installed Intel Embree, which doesnt look suspicious.
It doesnt change anything with visual studio. The Intel Embree guys dont use the Microsoft Compiler. I just mention it so the group of possible suspect is identified.



So if you run into the same problem - build the solution (project) from scratch.










share|improve this question

























  • "It jumps bacK" is quite unusual, very hard to imagine that you didn't do something else. Maybe you ought to focus on the more obvious mishap, there is no good reason why the #include should fail with other SDK versions. That's pretty bad, we can't generally recommend the "reformat disk drive" solution although that almost surely will fix the problem.

    – Hans Passant
    Nov 13 '18 at 12:49
















0















I have existing projects that run (need) visual studio 2015 and target
platform 8.1. I also have projects that need visual studio 2017.
So i recently installed 2017. This worked fine, for some time, for the new 2017-based projects.



Now i need to do a bug fix on the 2015-based projects.



What i see in the IDE in Properties->General->Target Platfrom is 10.0.10586.0.
One can see a dropdown that lists "10.0.17134.0 and 8.1". Selecting 8.1 works for a second but the selection is then not taken. It jumps back to 10.0.10586.0.



Without 8.1 the whole windows.h include files are not found, compilation doesnt work.



Now the fun part - i still have yet another (tiny) project that uses 2015.
This project does list 8.1 as target platform. And it compiles.
So my overall machine install must be good.



Somehow installing 2017 must have messed a part of my 2015 projects, but
not all. This looks really bizare as the .vcproject shows as unchanged in tortoisesvn.



Does anybody know how to verify environment variables etc that are used by visual studio with respect to the sdk ? Or does Microsoft use yet another database to
store project related extra information ?



EDIT



Here is my solution : I did create a new project from scratch. This has 8.1 as default and works fine. I then opened both the old .vcproj file and copied the



<ItemGroup>
<ClCompile Include="myfile1.cpp" />
<ClCompile Include="myfile2.cpp" />
<ClCompile Include="etc.cpp" />
</ItemGroup>


This way at least all my source files can be rescued to the new project file in a minute. The xml syntax for ItemGroups is clean. For all other settings i used the IDE. Opened 2 session of visual studio and copied manually the settings for libs, paths, flags etc. Now it works again. Doing a windiff on both .vcxproj files doesnt give a clear answer.



The new project does have entries like :



 <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<PlatformToolset>v140</PlatformToolset>
<WholeProgramOptimization>false</WholeProgramOptimization>
<CharacterSet>Unicode</CharacterSet>
</PropertyGroup>


I didnt test to retrofit this to the old vcxproj since i am running out of time,
and i have a working solution now. I double checked - my old vcxproj had been indeed under source control, so it did -not- change. The most likely candidate is now Cuda.



Cuda has very nice and helpful extensions for visual studio.
my squence had been



september - visual studio 2015 works
october - added cuda 9, worked with cuda. Did not touch projects from september. Most likely the problem happened here, but i didnt see because i do not builds every day/week.
Later in october i installed Unreal Engine & Visual Studio 2017. This looked
good back then, but i again didnt build the vs 2015 projects. So
there is a possibility that this had an impact.



Last but not least i installed Intel Embree, which doesnt look suspicious.
It doesnt change anything with visual studio. The Intel Embree guys dont use the Microsoft Compiler. I just mention it so the group of possible suspect is identified.



So if you run into the same problem - build the solution (project) from scratch.










share|improve this question

























  • "It jumps bacK" is quite unusual, very hard to imagine that you didn't do something else. Maybe you ought to focus on the more obvious mishap, there is no good reason why the #include should fail with other SDK versions. That's pretty bad, we can't generally recommend the "reformat disk drive" solution although that almost surely will fix the problem.

    – Hans Passant
    Nov 13 '18 at 12:49














0












0








0








I have existing projects that run (need) visual studio 2015 and target
platform 8.1. I also have projects that need visual studio 2017.
So i recently installed 2017. This worked fine, for some time, for the new 2017-based projects.



Now i need to do a bug fix on the 2015-based projects.



What i see in the IDE in Properties->General->Target Platfrom is 10.0.10586.0.
One can see a dropdown that lists "10.0.17134.0 and 8.1". Selecting 8.1 works for a second but the selection is then not taken. It jumps back to 10.0.10586.0.



Without 8.1 the whole windows.h include files are not found, compilation doesnt work.



Now the fun part - i still have yet another (tiny) project that uses 2015.
This project does list 8.1 as target platform. And it compiles.
So my overall machine install must be good.



Somehow installing 2017 must have messed a part of my 2015 projects, but
not all. This looks really bizare as the .vcproject shows as unchanged in tortoisesvn.



Does anybody know how to verify environment variables etc that are used by visual studio with respect to the sdk ? Or does Microsoft use yet another database to
store project related extra information ?



EDIT



Here is my solution : I did create a new project from scratch. This has 8.1 as default and works fine. I then opened both the old .vcproj file and copied the



<ItemGroup>
<ClCompile Include="myfile1.cpp" />
<ClCompile Include="myfile2.cpp" />
<ClCompile Include="etc.cpp" />
</ItemGroup>


This way at least all my source files can be rescued to the new project file in a minute. The xml syntax for ItemGroups is clean. For all other settings i used the IDE. Opened 2 session of visual studio and copied manually the settings for libs, paths, flags etc. Now it works again. Doing a windiff on both .vcxproj files doesnt give a clear answer.



The new project does have entries like :



 <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<PlatformToolset>v140</PlatformToolset>
<WholeProgramOptimization>false</WholeProgramOptimization>
<CharacterSet>Unicode</CharacterSet>
</PropertyGroup>


I didnt test to retrofit this to the old vcxproj since i am running out of time,
and i have a working solution now. I double checked - my old vcxproj had been indeed under source control, so it did -not- change. The most likely candidate is now Cuda.



Cuda has very nice and helpful extensions for visual studio.
my squence had been



september - visual studio 2015 works
october - added cuda 9, worked with cuda. Did not touch projects from september. Most likely the problem happened here, but i didnt see because i do not builds every day/week.
Later in october i installed Unreal Engine & Visual Studio 2017. This looked
good back then, but i again didnt build the vs 2015 projects. So
there is a possibility that this had an impact.



Last but not least i installed Intel Embree, which doesnt look suspicious.
It doesnt change anything with visual studio. The Intel Embree guys dont use the Microsoft Compiler. I just mention it so the group of possible suspect is identified.



So if you run into the same problem - build the solution (project) from scratch.










share|improve this question
















I have existing projects that run (need) visual studio 2015 and target
platform 8.1. I also have projects that need visual studio 2017.
So i recently installed 2017. This worked fine, for some time, for the new 2017-based projects.



Now i need to do a bug fix on the 2015-based projects.



What i see in the IDE in Properties->General->Target Platfrom is 10.0.10586.0.
One can see a dropdown that lists "10.0.17134.0 and 8.1". Selecting 8.1 works for a second but the selection is then not taken. It jumps back to 10.0.10586.0.



Without 8.1 the whole windows.h include files are not found, compilation doesnt work.



Now the fun part - i still have yet another (tiny) project that uses 2015.
This project does list 8.1 as target platform. And it compiles.
So my overall machine install must be good.



Somehow installing 2017 must have messed a part of my 2015 projects, but
not all. This looks really bizare as the .vcproject shows as unchanged in tortoisesvn.



Does anybody know how to verify environment variables etc that are used by visual studio with respect to the sdk ? Or does Microsoft use yet another database to
store project related extra information ?



EDIT



Here is my solution : I did create a new project from scratch. This has 8.1 as default and works fine. I then opened both the old .vcproj file and copied the



<ItemGroup>
<ClCompile Include="myfile1.cpp" />
<ClCompile Include="myfile2.cpp" />
<ClCompile Include="etc.cpp" />
</ItemGroup>


This way at least all my source files can be rescued to the new project file in a minute. The xml syntax for ItemGroups is clean. For all other settings i used the IDE. Opened 2 session of visual studio and copied manually the settings for libs, paths, flags etc. Now it works again. Doing a windiff on both .vcxproj files doesnt give a clear answer.



The new project does have entries like :



 <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<PlatformToolset>v140</PlatformToolset>
<WholeProgramOptimization>false</WholeProgramOptimization>
<CharacterSet>Unicode</CharacterSet>
</PropertyGroup>


I didnt test to retrofit this to the old vcxproj since i am running out of time,
and i have a working solution now. I double checked - my old vcxproj had been indeed under source control, so it did -not- change. The most likely candidate is now Cuda.



Cuda has very nice and helpful extensions for visual studio.
my squence had been



september - visual studio 2015 works
october - added cuda 9, worked with cuda. Did not touch projects from september. Most likely the problem happened here, but i didnt see because i do not builds every day/week.
Later in october i installed Unreal Engine & Visual Studio 2017. This looked
good back then, but i again didnt build the vs 2015 projects. So
there is a possibility that this had an impact.



Last but not least i installed Intel Embree, which doesnt look suspicious.
It doesnt change anything with visual studio. The Intel Embree guys dont use the Microsoft Compiler. I just mention it so the group of possible suspect is identified.



So if you run into the same problem - build the solution (project) from scratch.







visual-studio-2015 visual-studio-2017






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 13 '18 at 17:19







MatthiasL

















asked Nov 13 '18 at 11:04









MatthiasLMatthiasL

264




264













  • "It jumps bacK" is quite unusual, very hard to imagine that you didn't do something else. Maybe you ought to focus on the more obvious mishap, there is no good reason why the #include should fail with other SDK versions. That's pretty bad, we can't generally recommend the "reformat disk drive" solution although that almost surely will fix the problem.

    – Hans Passant
    Nov 13 '18 at 12:49



















  • "It jumps bacK" is quite unusual, very hard to imagine that you didn't do something else. Maybe you ought to focus on the more obvious mishap, there is no good reason why the #include should fail with other SDK versions. That's pretty bad, we can't generally recommend the "reformat disk drive" solution although that almost surely will fix the problem.

    – Hans Passant
    Nov 13 '18 at 12:49

















"It jumps bacK" is quite unusual, very hard to imagine that you didn't do something else. Maybe you ought to focus on the more obvious mishap, there is no good reason why the #include should fail with other SDK versions. That's pretty bad, we can't generally recommend the "reformat disk drive" solution although that almost surely will fix the problem.

– Hans Passant
Nov 13 '18 at 12:49





"It jumps bacK" is quite unusual, very hard to imagine that you didn't do something else. Maybe you ought to focus on the more obvious mishap, there is no good reason why the #include should fail with other SDK versions. That's pretty bad, we can't generally recommend the "reformat disk drive" solution although that almost surely will fix the problem.

– Hans Passant
Nov 13 '18 at 12:49












0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53279614%2fhow-to-get-target-platform-8-1-back-with-visual-studio-2015-after-installing-stu%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53279614%2fhow-to-get-target-platform-8-1-back-with-visual-studio-2015-after-installing-stu%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Full-time equivalent

Bicuculline

さくらももこ