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.

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

Property Definitions: placed after non-paket imports if they directly follow the top property groups #1561

Merged
merged 2 commits into from Mar 30, 2016

Conversation

Projects
None yet
2 participants
@cdrnet
Member

cdrnet commented Mar 30, 2016

Related to #1537

If in a project file there are non-paket imports right after the top property groups, then place the property definitions right after them (instead of before them). This makes sure that imports like Microsoft.CSharp.targets can be moved up before them, to make sureTargetFrameworkIdentifier is actually defined. Note that it does not move Microsoft.CSharp.targets up manually if it is further down (which it is by default).

cdrnet added some commits Mar 30, 2016

@cdrnet

This comment has been minimized.

Show comment
Hide comment
@cdrnet

cdrnet Mar 30, 2016

Member

Should I rather have created/forked a new integration test instead of changing existing ones?

Member

cdrnet commented Mar 30, 2016

Should I rather have created/forked a new integration test instead of changing existing ones?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 30, 2016

Member

Yeah more tests are probably better
On Mar 30, 2016 10:40 AM, "Christoph Ruegg" notifications@github.com
wrote:

Should I rather have created/forked a new integration test instead of
changing existing ones?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1561 (comment)

Member

forki commented Mar 30, 2016

Yeah more tests are probably better
On Mar 30, 2016 10:40 AM, "Christoph Ruegg" notifications@github.com
wrote:

Should I rather have created/forked a new integration test instead of
changing existing ones?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1561 (comment)

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 30, 2016

Member

but I think it's fine

Member

forki commented Mar 30, 2016

but I think it's fine

@forki forki merged commit 17c07bb into fsprojects:master Mar 30, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@cdrnet

This comment has been minimized.

Show comment
Hide comment
@cdrnet

cdrnet Mar 30, 2016

Member

Note that in the quite common case that Microsoft.CSharp.targets is further down this change will only allow to manually fix it by moving it up (and make the fix survive paket operations), but will not actually fix it itself.

Should we try to be smarter? Being smart could easily break other stuff unfortunately.

Member

cdrnet commented Mar 30, 2016

Note that in the quite common case that Microsoft.CSharp.targets is further down this change will only allow to manually fix it by moving it up (and make the fix survive paket operations), but will not actually fix it itself.

Should we try to be smarter? Being smart could easily break other stuff unfortunately.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 30, 2016

Member

I think we should wait and see what happens - also in regards to #1562

Member

forki commented Mar 30, 2016

I think we should wait and see what happens - also in regards to #1562

@cdrnet cdrnet deleted the cdrnet:project-propdefs-after-propgroupsimports branch Mar 30, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment