Project analysis

[andrew-boyarshin]

It seems we can implement some kind of analysis based on the information we gather. I've already implemented this part and I want more ideas for custom diagnostics.

• W001: Incompatible/Unsupported project type (Xamarin.*, WinForms)
• W002: Project file mentioned in solution is missing
• W010: $(Configurations)/$(Platforms) does not contain all configurations/platforms mentioned in project file
• W011: Conditional expression contains unsupported kind of subexpression (and, not)
• W012: File X that was not included before will be included after conversion thanks to wildcards
• W020: Wrong use of Microsoft.CSharp (usage on < net40, non-NuGet > net45)
• W021: Use System.* NuGet package
• W030: Consider migrating pdbonly & full DebugTypes to modern portable one.
• W031: You have MSBuild SDK version specified in your project file. A recommended approach would be using global.json for centralized version management.
• W032: You have old language version specified. Consider upgrading it to latest.
• W033: PCL profiles are obsolete. Consider migrating to .NET Standard.
• W034: Reference aliases are a feature of low support. Consider dropping their usage.

[hvanbakel]

so for W012 I actually recieved a comment that that should not happen since it alters the state of the project while we could just exclude it. I think I would rather have a clean tree though (so keep the current behavior).

I think we should be warning for moving over to package reference and therefor losing the min max constraints on dependencies that you might have specified in a nuspec file. So far I haven't found a way to make VS set those (so I want my package to be compatible with [2.1, 3) so I'm not compatible with the next major.

[andrew-boyarshin]

Diagnostics left to implement after #146:

• [ ] W012
• [ ] W013 (suggested by @hvanbakel — pending clarification)

[andrew-boyarshin]

@hvanbakel I'm not sure about your PackageReference concerns. This doc page clearly shows it should work. Do I understand your comment correctly?

[hvanbakel]

@andrew-boyarshin it can support it. The fact that the references move from a nuspec to the project file means that every package you update means that you have to go back in and (manually) set the restrictions. Because this was a separate file your old restrictions weren't overwritten which it now does (as far as I know).

[hvanbakel]

For W012, this is an interesting one, should we actually not create a node to exclude the file to keep the files included before/after the same?

[andrew-boyarshin]

@hvanbakel oh, you mean when you update deps in VS NuGet package manager for example, VS overwrites Version property with precise version instead of preserving it and merely updating local cache? That would be... Sad. I see the point in such diagnostic now.

Regarding W012, I'm not sure if that should be diagnostic or actual change in csproj-to-2017 behavior. I mean, the user should at least be warned about such cases (not done at all now). But whether to add excludes for these file... That's a question of priorities: conversion precision or output project file clarity and lack of unexpected behavior.

[andrew-boyarshin]

W012 ref #190