Skip to content

If a dependent assembly is .NET 4.5.1, and the current project is .NET 4.5, it will silently fail #1442

Closed

Description

@sharpe5

How about a meaningful error if paket is failing to import dependent assembles, due to a .NET framework mismatch?

Scenario: We had an entire team of 10 developers trying to fix issues with Paket. No matter what we did, a "paket install" would not import a required assembly.

Eventually, after 4 hours and some senior developers had tried and failed to fix the issue, we realized that the dependent packaged assembly was .NET v4.5.1, which wouldn't load into a project configured for .NET 4.5.

Activity

  1. forki commented on Jan 29, 2016

    @forki
    Member

    Unfortunately that is not always an error. Many packages are only used for some .NET framework versions and have counterparts in other nuget packages or the framework itself for other framework versions.

    That said: would it have helped you if we provide a big yellow warning? We could warn if a framework was selected in the project but the install conditions create a empty lib set.

  2. forki commented on Jan 29, 2016

    @forki
    Member

    It could look like this:

    image

  3. added a commit that references this issue on Jan 29, 2016
    c07c4f9
  4. forki commented on Jan 29, 2016

    @forki
    Member

    corresponding PR #1445

  5. added a commit that references this issue on Jan 29, 2016
    0ea63a2
  6. sharpe5 commented on Jan 29, 2016

    @sharpe5
    Author

    Thank you for your quick reply. It would definitely help if there was a yellow warning.

    In Visual Studio, unfortunately, I think the "Output" view is monochrome if the Paket Extension Tool is used, so it might be an idea to empahasize it with some surrounding stars.

    On 29 January 2016 15:42:03 GMT+00:00, Steffen Forkmann notifications@github.com wrote:

    Unfortunately that is not always an error. Many packages are only used
    for some .NET framework versions and have counterparts in other nuget
    packages or the framework itself for other framework versions.

    That said: would it have helped you if we provide a big yellow warning?
    We could warn if a framework was selected in the project but the
    install conditions create a empty lib set.


    Reply to this email directly or view it on GitHub:
    #1442 (comment)

  7. sharpe5 commented on Jan 29, 2016

    @sharpe5
    Author

    Brilliant, that would work nicely!!

    On 29 January 2016 16:46:55 GMT+00:00, Steffen Forkmann notifications@github.com wrote:

    It could look like this:

    image


    Reply to this email directly or view it on GitHub:
    #1442 (comment)

  8. CumpsD commented on Apr 7, 2016

    @CumpsD
    Contributor

    Any way to be smarter then the resolver and ask paket to reference a "wrong" target framework? :)

  9. forki commented on Apr 8, 2016

    @forki
    Member

    Only manually
    On Apr 8, 2016 12:29 AM, "David Cumps" notifications@github.com wrote:

    Any way to be smarter then the resolver and ask paket to reference a
    "wrong" target framework? :)

    —
    You are receiving this because you modified the open/close state.
    Reply to this email directly or view it on GitHub
    #1442 (comment)

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions