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

Warn bad install/upgrade for project w/ tfm="dotnet" #3137

Closed
rrelyea opened this Issue Jul 15, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@rrelyea
Contributor

rrelyea commented Jul 15, 2016

Details to come...

@rrelyea rrelyea added this to the 3.5 RTM milestone Jul 15, 2016

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Jul 15, 2016

Contributor

@harikmenon added the following in the dupe issue:

  1. The NuGet team will be a check in place to detect the use of the dotnet TFM during Install and Update. We will show a warning dialog that will point users to a document that will be authored by the .NET Core team that will lay out the steps required to move to .NET Standard. We will not prevent the update/install if the user needs to but we will make clear that this could cause issues. This change will be made to the 3.5 RTM release and will ship on ~ 8/2
Contributor

rrelyea commented Jul 15, 2016

@harikmenon added the following in the dupe issue:

  1. The NuGet team will be a check in place to detect the use of the dotnet TFM during Install and Update. We will show a warning dialog that will point users to a document that will be authored by the .NET Core team that will lay out the steps required to move to .NET Standard. We will not prevent the update/install if the user needs to but we will make clear that this could cause issues. This change will be made to the 3.5 RTM release and will ship on ~ 8/2
@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Jul 15, 2016

Member

Should it warn only if the project is targeting dotnet? Or also if a dotnet asset is being selected?

Should all dotnet TFMs be warned on, e.g. dotnet5.1 - dotnet5.6 as well as dotnet?

Member

joelverhagen commented Jul 15, 2016

Should it warn only if the project is targeting dotnet? Or also if a dotnet asset is being selected?

Should all dotnet TFMs be warned on, e.g. dotnet5.1 - dotnet5.6 as well as dotnet?

@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Jul 16, 2016

Member

Can we formalize this error condition? My proposal is that if the following conditions are met, display the warning dialog:

  • Preview restore fails
  • Project targets dotnet (or dotnet50, which is equivalent)
  • Incompatible packages support netstandard1.0
  • User has not checked "ignore this warning"

/cc @ericstj, @rrelyea, @harikmenon, @emgarten - thoughts?

Member

joelverhagen commented Jul 16, 2016

Can we formalize this error condition? My proposal is that if the following conditions are met, display the warning dialog:

  • Preview restore fails
  • Project targets dotnet (or dotnet50, which is equivalent)
  • Incompatible packages support netstandard1.0
  • User has not checked "ignore this warning"

/cc @ericstj, @rrelyea, @harikmenon, @emgarten - thoughts?

@harikmenon

This comment has been minimized.

Show comment
Hide comment
@harikmenon

harikmenon Jul 16, 2016

Can you explain Preview restore a bit?

Also, what do you mean by incompatible packages in this context?

harikmenon commented Jul 16, 2016

Can you explain Preview restore a bit?

Also, what do you mean by incompatible packages in this context?

@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Jul 18, 2016

Member

Can you explain Preview restore a bit?

When taking a NuGet action in the UI (install, update, uninstall) there is a "preview" stage followed by an "execute" stage. The preview stage updates no artifacts on disk and is completed prior to showing the preview dialog and the license acceptance dialog. In the case of UWP project.json, we execute the restore of the new project.json during the preview so we can detect the incompatibilities at that point.

Also, what do you mean by incompatible packages in this context?

Suppose the user is updating Microsoft.NETCore to 5.0.1 and Microsoft.NETCore.Portable.Compatibility to 1.0.1. The restore performed in the preview stage will show that a) the restore cannot complete successfully and b) both Microsoft.NETCore 5.0.1 and Microsoft.NETCore.Portable.Compatibility 1.0.1 are incompatible with dotnet. We have this granularity of detail even before the user confirms the preview or license dialogs.

Member

joelverhagen commented Jul 18, 2016

Can you explain Preview restore a bit?

When taking a NuGet action in the UI (install, update, uninstall) there is a "preview" stage followed by an "execute" stage. The preview stage updates no artifacts on disk and is completed prior to showing the preview dialog and the license acceptance dialog. In the case of UWP project.json, we execute the restore of the new project.json during the preview so we can detect the incompatibilities at that point.

Also, what do you mean by incompatible packages in this context?

Suppose the user is updating Microsoft.NETCore to 5.0.1 and Microsoft.NETCore.Portable.Compatibility to 1.0.1. The restore performed in the preview stage will show that a) the restore cannot complete successfully and b) both Microsoft.NETCore 5.0.1 and Microsoft.NETCore.Portable.Compatibility 1.0.1 are incompatible with dotnet. We have this granularity of detail even before the user confirms the preview or license dialogs.

@harikmenon

This comment has been minimized.

Show comment
Hide comment
@harikmenon

harikmenon Jul 18, 2016

Okay makes sense. Thanks for the clarification.

harikmenon commented Jul 18, 2016

Okay makes sense. Thanks for the clarification.

@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Jul 18, 2016

Member

@harikmenon and I spoke offline about this. We decided to broaden the warning to warn if there are any incompatible packages. The new criteria would then be:

  • Preview restore fails
  • Project targets dotnet (or dotnet50, which is equivalent)
  • Any incompatible packages
  • User has not checked "ignore this warning"
Member

joelverhagen commented Jul 18, 2016

@harikmenon and I spoke offline about this. We decided to broaden the warning to warn if there are any incompatible packages. The new criteria would then be:

  • Preview restore fails
  • Project targets dotnet (or dotnet50, which is equivalent)
  • Any incompatible packages
  • User has not checked "ignore this warning"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment