Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

When adding framework specification to paket.dependencies .props include is moved to the bottom of csproj file #1487

Closed
theggelund opened this issue Feb 24, 2016 · 7 comments
Closed

When adding framework specification to paket.dependencies .props include is moved to the bottom of csproj file #1487

theggelund opened this issue Feb 24, 2016 · 7 comments

Comments

@theggelund
Copy link

I have a nuget package that includes both a .props and a .targets. Then I wantet to specify which frameworks should be included when installting packages.

Added framework specification

framework: net40, net45, net46

source nuget_repo

nuget MultiTarget
nuget Dapper
nuget NUnit

After this the .props include statement was moved to the bottom just before .targets import

image

image

Reproduced in repo paket_bug with latest commit

Just run reproduce.bat

Reproduced on
image
@forki forki closed this as completed in cebbbee Mar 1, 2016
@forki forki reopened this Mar 10, 2016
@forki
Copy link
Member

forki commented Mar 10, 2016

#1233 shows that it should not go to the top since it contains a property that is defined later.

@forki forki mentioned this issue Mar 10, 2016
Closed
@forki
Copy link
Member

forki commented Mar 10, 2016

I'm reverting this for now since the fix was obviously incorrect. But what would be a correct fix?
/cc @inosik

forki added a commit that referenced this issue Mar 10, 2016
@forki
Revert #1487
00c1310
@inosik
Copy link
Contributor

inosik commented Mar 11, 2016

The problem is that Paket generates a __paket__xyz_props property for .props (and .targets) that aren't framework specific, when there is a framework restriction. So (I think) we should handle this special case when we generate the <Choose />-blocks for the contents of the package.

@forki
Copy link
Member

forki commented Mar 11, 2016

the question is: is @theggelund's csproj file broken or is it just "different" after adding the framework specification.

@inosik
Copy link
Contributor

inosik commented Mar 11, 2016

It's not broken, it's different to what NuGet would generate.

@forki
Copy link
Member

forki commented Mar 11, 2016

But the issue got opened here. So I assumed the generated xml was not working

@theggelund
Copy link
Author

after adding the framework specification the .props got moved to the bottom of csproj. It's not framework specific or anything. Is it being processed as framework specific and with no specification? (how would you specify this if that's the case?) It just got moved and I think that's the bug.

@inosik inosik mentioned this issue Mar 22, 2016
Closed
@mlidbom mlidbom mentioned this issue Mar 23, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@forki @theggelund @inosik