1

In my C++ project Visual Studio (2017) fails to detect changes in a property value when I trigger a "build" (e.g. via F5 requesting a debugger start).

I want to be able to use the property pages dialog in visual studio to specify a path variable to another library.

The simplified versions are here. First I use a .targets file: 

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <ItemGroup>
        <PropertyPageSchema Include="$(MSBuildThisFileDirectory)\overrideSettings.xml" />
    </ItemGroup>

    <PropertyGroup Condition="'$(myDir)' == ''">
        <__my_IncludeDir>somewhere\include\</__my_IncludeDir>
    </PropertyGroup>

    <PropertyGroup Condition="'$(myDir)' != ''">
        <__my_IncludeDir>somewhere_else\include\</__my_IncludeDir>
    </PropertyGroup>

    <ItemDefinitionGroup>
        <ClCompile>
            <AdditionalIncludeDirectories>$(__my_IncludeDir);%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
        </ClCompile>
        <ResourceCompile>
            <AdditionalIncludeDirectories>$(__my_IncludeDir);%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
        </ResourceCompile>
    </ItemDefinitionGroup>
</Project>

And an .xml file for the settings:

<?xml version="1.0" encoding="utf-8"?>
<ProjectSchemaDefinitions xmlns="clr-namespace:Microsoft.Build.Framework.XamlTypes;assembly=Microsoft.Build.Framework">
    <Rule Name="ProjectSettings_NugetDevOverride" PageTemplate="tool" DisplayName="Nuget Development Override" SwitchPrefix="/" Order="1">
        <Rule.Categories>
            <Category Name="myTest" DisplayName="myTest" />
        </Rule.Categories>
        <Rule.DataSource>
            <DataSource Persistence="UserFile" ItemType="" />
        </Rule.DataSource>

        <StringProperty Name="myDir" Category="myTest" />
    </Rule>
</ProjectSchemaDefinitions>

Now, this does work to some extent.

However, Visual Studio fails to correctly detect changes in the property variable defined on the property page.

  • I build the project -> 1 succeeded
  • I build the project again (F5) -> 1 up-to-date
  • I change the variable myDir using the property page; making it empty or setting a value, so that the other property group in the .targets file is triggered.
  • I build the project again (F5) -> 1 up-to-date This is wrong!
  • I re-build the project -> 1 succeeded with correctly used new property value.

Where is the problem in my setup? Can I explicitly add myDir as property to be checked before the build is marked as up-to-date?

I found one workaround: DisableFastUpToDateCheck

https://stackoverflow.com/a/36004494/552373

But this is horrible, since my real project is very large and the fast-up-to-date-check really helps.

Update 20171128:

I now also tried the following:

  • I build the project -> 1 succeeded
  • I build the project again (F5) -> 1 up-to-date
  • I change the variable myDir using the property page; making it empty or setting a value, so that the other property group in the .targets file is triggered.
  • I close Visual Studio and open it again. No file-save dialog popped up.
  • I build the project again (F5) -> 1 up-to-date This is wrong!

The fact, that even this does not work, points at a real problem with the FastUpToDateCheck in Visual Studio.

Does anyone have a further idea?

Knowleech
  • 1,013
  • 2
  • 9
  • 15
  • How often to you change this property value? Could you do a clean and rebuild? – 1201ProgramAlarm Nov 27 '17 at 17:35
  • does the project file change? could be issues when project files aren't saved (click "save all"). Usually you'd also add `UpToDateCheckInput` items to indicate to the project system that an input to the up-to-date check has changed, but that is meant for files (might work for directories as well) – Martin Ullrich Nov 27 '17 at 19:23
  • 1
    For some reason, Visual Studio would not run the updated version of the target file contained in the project. It seemed like the target file was somehow cached when Visual Studio opened and would not replace it with the version that was editing in the property. To resolve this issue, you can try to force VS to reload the target on each invocation as different filename: https://stackoverflow.com/questions/4919204/how-to-turn-off-caching-of-build-definitions-in-visual-studio/6217800#6217800 – Leo Liu Nov 28 '17 at 08:11
  • @1201ProgramAlarm: I am seeking for an idiot-proof automatic solution. Manually triggering a rebuild does work. – Knowleech Nov 28 '17 at 12:25
  • @Martin Ullrich: The setting is stored in the user-file, not the property file. That file is not even saved on "save all", but only when Visual Studio wants too. The problem seems to be the "fast up to date check" in Visual Studio, which does not check those properties. – Knowleech Nov 28 '17 at 12:27
  • @Leo Liu-MSFT: The problem seems to be the "fast up to date check" within visual studio. Setting the parameter in the GUI does not change the targets file at all. It changes a setting in the `.user` property file. As such I am not show if I could do anything here with randomized file name magic. – Knowleech Nov 28 '17 at 12:29
  • @MartinUllrich: I tried to use "UpToDateCheckInput". Did not change anything. – Knowleech Nov 28 '17 at 13:30
  • Would creating a new build target be feasible? Rather than just Debug and Release, there'd also be Debug_Mydir and Release_Mydir. This could also then build the two version in separate subfolders. – 1201ProgramAlarm Nov 28 '17 at 17:05
  • @1201ProgramAlarm: this idea is not bad. However, if I try introducing those, many people on the dev. team will get very angry. Some of our projects needs to support a plethora of different compiler versions. So, there we already have like 8-10 configurations for debug/release each. Introducing yet another factor of two ... I would fear for my life ;-) – Knowleech Nov 29 '17 at 10:03

0 Answers0