.props files are broken

[inosik]

Since v2.24.7 framework specific .props files (as in xunit.core, or our beloved xunit.runner.visualstudio) do not work anymore.

The problem is, that the framework specific part of the path (__paket__Package_Name_targets MSBuild property) isn't set, when the file gets imported.

[inosik]

As I see now, the normal .props files are also broken, because we resolve the whole file name.

<Choose>
  <When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v4.5'">
    <PropertyGroup>
      <__paket__Package_Name_props>Package.Name</__paket__Package_Name_props>
    </PropertyGroup>
  </When>
</Choose>

[forki]

I can reproduce.

[forki]

could you please try latest alpha?

[inosik]

Thanks, that solved the issue. But now we have #1219 again.

@theggelund Are there any issues at all if the .props aren't imported at the top of the file?

[forki]

We have still #1219 covered for props that are global. There is an
integration test
On Nov 17, 2015 2:02 PM, "Ilja Nosik" notifications@github.com wrote:

Thanks, that solved the issue. But now we have #1219
#1219 again.

@theggelund https://github.com/theggelund Are there any issues at all
if the .props aren't imported at the top of the file?

—
Reply to this email directly or view it on GitHub
#1233 (comment).

[forki]

we can't put this up to the top since the properties for the case block are not defined at the top.

[theggelund]

Ordering is important. Using conditional checks for variable not set is used to support amongst other features, multi-target builds

Accordning to nuget, props should be put at the top and targets should be put at the bottom.
Ordering is important, and by using conditionals that check if variable is set and giving a default value, multi-target solutions can be supported in visual studio

[inosik]

@forki Sorry to bother you with this again, but we have to reopen this issue. Framework specific .props files get imported at the top of the project again.

[forki]

do we already have an integration test for this? (and did I break it ?)

Can you name a public nuget package which has this issue?

[inosik]

The infamous xunit.runner.visualstudio strikes back again. I prepared this repro sample.

IIRC we have an integration test for the opposite case: .props files which reside directly in build/, not in build/{framework}/.

[forki]

I will take a look

[forki]

xUnitTests.expected.csproj is that what you expect it to be? In 28116e0 the test suggests that this is actually the result that paket gives you.

[forki]

so what did I do wrong in the test?

[inosik]

Sorry, somehow I edited the expected result back again to the wrong one. This is how I'd expect it to be, the <Import /> should come either at the end of the file, or right after the <Choose />.

[forki]

I don't understand. Why should it go to the end?

[forki]

ah I see. the property is not defined

[forki]

so this was changed in #1487 and I'm not completely sure what the correct way is

[forki]

so I guess this one is "fixed", but please help with #1487