Import common targets if LanguageTargets property isn't set.

[dsplaisted]

This will allow restore to succeed. Fixes #448. Fixes #373

Rather than generating an error (as specified in #448), this PR imports the common targets if the LanguageTargets property isn't set. This means that restore can succeed even if the language targets aren't otherwise set, which means that F# or another language could be provided solely as a NuGet package instead of an MSBuild SDK.

@enricosada How does this look to you? Once it is possible to have third party SDKs (see dotnet/msbuild#1493), you may still prefer to use an SDK for F# over a NuGet package. It would make the project files more succinct and might avoid the project showing up differently in solution explorer when you create or open a project before the restore completes.

[borgdylan]

👍 for this. I have a similar use case and this will unblock me.

[enricosada]

@dsplaisted sorrry for really really late replay, i missed that. thx for ping.

It's ok, I think we are going to continue use Sdk as you said because is more succint. And make sense because sdk is just a implementation detail, not a first class package (for user) of the project

Like this is possibile to use a .proj (custom extension, so no language) and dotnet pack it?
My use case is to create packages without compiled assemblies, just contents and <PackageReference />. Used as complete replacement of a .nuspec file and nuget pack who has an annoying sintax for props, and is not easy to author like a csproj (for deps)

[dazinator]

I raised a related issue recently #1051 that seems relevant to this PR.
My experience, was that I had a custom project type, using the new SDK attribute. My proj file extension was .Dnnproj. I declared csharp capability (cps) expecting csharp language features to light up. They did.. but no csharp would compile. No real error information anywhere either. Was left wondering what the problem could be. I even compared my proj file to a brand new csproj file. There was no real difference. It was only after delving into these targets, i discovered what was going on, i.e that language targets are inferred based on proj file extension and not capability. Further more, if language can't be inferred, rather than error, common targets are imported. Please consider inferring language targets based on presence of respective capabilities.