Minimal Service Fabric integration

[ReubenBond]

In contrast to #2070 (Deep Service Fabric Support) and the related issue #1059, this implements minimal Service Fabric support.

This is a replacement for OrleansContrib/OrleansFabricSilo and introduces a new NuGet package,
Microsoft.Orleans.ServiceFabric, which is referenced by both the client and silo.

A sample project is also included in its own solution. Note, however, that the sample relies on a non-existent version of the nuget packages, so either I can split the samples into a separate PR and wait unitl NuGets are published, or we can determine when this will ship and I can stick those versions in the samples.

Please let me know if you have any questions.

[ReubenBond]

I'd be happy to remove code which sets DeploymentId - it's unnecessary. When deeper integration is done, there will be other ways to configure the target SF service on the client.

[sergeybykov]

There's no easy way to test this, right?

[galvesribeiro]

So this is just the Stateless service support, right?

[ReubenBond]

@sergeybykov I investigated a little bit and no, there is no easy way to write automated tests for this without writing abstractions for various SF classes. In this case, where the support is very rudimentary, I don't see much value in going to those lengths. If you prefer, I'm happy to try to mock/abstract the SF bits.

@galvesribeiro yes, you're right, this is essentially a port of the OrleansFabricSilo repo

[sergeybykov]

In this case, where the support is very rudimentary, I don't see much value in going to those lengths.

I agree.

If you prefer, I'm happy to try to mock/abstract the SF bits.

If it's relatively easy to do.

[jdom]

please remove transitive dependencies from other projects (DI and Json)

[ReubenBond]

Will do, thanks

[ReubenBond]

I'm removing some of the code, push incoming.

[ReubenBond]

The latest revision upgrades the packages to v1.3.0 and removes the code used to detect the IP address, using code already in Orleans for that. I also dropped the DeploymentId stuff, since it's not needed.

[ReubenBond]

I simplified the code further. I'm happy with it now. OpenAsync is the only noteworthy method.

[ReubenBond]

Added basic tests & improved error handling: now errors should occur on construction rather than when opening the listener. I believe this PR is ready for review now (I know, it should be ready when I first submit it - apologies for the many revisions.)

[ReubenBond]

Is anyone able to review this for inclusion into 1.3.0? It does not touch any core Orleans code, it's purely new code and it's very simple.
cc @onionhammer, @miker1423, @kwal, @moswald, since you have used OrleansContrib/OrleansFabricSilo and this is slated to replace it.

[galvesribeiro]

LGTM

[ReubenBond]

Note that this is no longer a transitive dependency since it's being used to return the endpoints to SF

[kwal]

👍

[miker1423]

I'll test it. Great job @ReubenBond!

[moswald]

The only comment I have is that if you're going to be adding new projects, then I would prefer to see project.json instead of packages.config. Otherwise, it all looks good to me.

[ReubenBond]

Thanks all :)
@moswald the Samples projects have packages.config just because VS added them that way, but the main package uses project.json instead. Do you think the sample should be changed?

[onionhammer]

Please dont convert to project.json; we don't know what the future of that format is going to be, do we?

[moswald]

The Nuget team has replaced packages.config with project.json. This is not going away. The Asp.Net team tried to replace the .csproj-based system by extending project.json (with nearly-empty .xproj files), but there is just too much tooling around the xml-based system for it to be replaced outright. They are working on moving their "extra" project.json stuff back into a slimmer, more agile .csproj.

[moswald]

To answer your question Reuben, yeah, I'd prefer to see all projects with project.json support. It's so much easier to edit with the cascading dependency support. This really helps new users (the ones who will be looking at the samples) figure out what's important.

[onionhammer]

I don't know the statistics for this, but I suspect the majority (by a large margin) of Orleans users are using Visual Studio, not VS Code. Orleans does not even currently support dotnet core. I see now reason to use anything 'ahead' of what Orleans itself uses. Wait for the project.json/xproj tooling to go beyond preview/alpha.

[moswald]

I think you misunderstood me. The combination of csproj and project.json is permanent.

[jdom]

The reason samples use packages.config is because they can be opened even without the new tooling. It's OK to have Orleans contributors be on whatever tool we find more useful (especially since these tools are free for OSS projects), but we should not mandate that on users of Orleans that want to check out the samples

[moswald]

There seems to be some misconception about project.json: it's not a part of the dotnet core stuff. It's the preferred file format for Nuget 3.x.

However, we're kind of getting off topic here. I don't really care -- I'm a consumer here, not a contributor and didn't mean to derail anything.

In short, 👍 to the PR. :)

[jdom]

Yup, I'm aware of it. It still requires nuget v3.5 and VS2015, where all of our samples can run in VS2013 (or even 2012 I believe).
Also minor thing: but since dotnet core is dropping project.json, nuget will probably start using packages.json instead (no big deal though, as it will be the same structure). That probably does not mean that the current file name will stop working in the next nuget release, but it will not be the default any more

[ReubenBond]

Fixed the NuGet package headers, thanks @jdom 👍