Project initialization fails due to unrecognized keyword "platform"

[natemcmaster]

dotnet-cli added"type": "platform" to project.json schema. When launching omnisharp on a project that has this in the project.json, omnisharp crashes.

eg.

{
  "version": "1.0.0-*",
  "compilationOptions": {
    "emitEntryPoint": true
  },
  "dependencies": {
    "Microsoft.NETCore.App": { "type": "platform", "version": "1.0.0-rc2-23911" }
  },
  "frameworks": {
    "netstandard1.5": { }
  }
}

The project system 'DotNetProjectSystem' threw exception during initialization.
unknown keyword platform
   at Microsoft.DotNet.ProjectModel.ProjectReader.TryGetProject(String path, Project& project, ICollection`1 diagnostics, ProjectReaderSettings settings)
   at Microsoft.DotNet.ProjectModel.WorkspaceContext.AddProjectEntry(String projectDirectory, FileModelEntry`1 currentEntry)

[hal-ler]

I assume the solution is to pin a newer version of dotnet-cli during build.
@david-driscoll This might be considered as you bring in the new build system (the option is in build.json).

[david-driscoll]

yeah, that's probably the fix... I should have time to look tonight.

[troydai]

Solution #1: take in new CLI packages to keep up with project model changes.
Solution #2: use the project model server model. in this case, another process, like the old DTH, runs side by side with O#. the process is updated with local SDK.

Choice?

[david-driscoll]

I'm fine with #1 eventually we'll stabilize once we hit rc2/rtm.

We could investigate in a daily release build, that produces new github releases every day with the latest bits. We might run into a case or two where we have a break, but we can solve those as we hit them.

[troydai]

/cc @davidfowl
The question will be as dotnet begin to support side by side SDK. it is possible for one solution to require one version of SDK and the other to relies on another one. If a SDK is specified in global.json, then we have no choice but go to solution #2.

[DustinCampbell]

OK. What is the plan here? We need to get something happening since OmniSharp is broken with the latest .NET CLI bits.

[DustinCampbell]

FWIW, I'm interested in solution 2, but it's probably too ambitious of a change to get in quickly.

[troydai]

I'll work on #1 first then we have to eventually move the #2.

[hal-ler]

I got it to work and will create a PR soon as I polish it.

[hal-ler]

#485

[troydai]

Fixed in #486. Thanks, @hal-ler .

[DustinCampbell]

Awesome guys -- should we kick off a release with this change?

[hal-ler]

I was hoping that we can validate it a bit using an editor. I had some silent failures that did not show up in the tests while making this change.