Move IService and IActor to seperate NuGet packages

[amanbha]

Tracking the issue microsoft/service-fabric#179 (comment)

As per original issue by @Scythen

If using remoting, every time the Service Fabric SDKs are released every service must be upgraded due to IService and IActor dependencies.
I don’t believe this should be required because the underlying serialization and messaging is compatible. If IService and IActor were in separate packages with versions that were only changed with breaking serialization changes it would be much simpler to share service interfaces.
The current dependency model causes cascading SDK updates across all services referencing an interface.

[suchiagicha]

In remoting V2 , we have a way to create remoting service without marking interface types with IService.
These are the Apis to be used
Service Dispatcher

ServiceproxyFactory

[hanxinimm]

What about custom serialization interface nuget?

[hanxinimm]

@suchiagicha How to create remoting IActor without marking interface types with IService. And
can you move custom serialization interface to seperate? It's going to be hindered by Team development，Each time we need to solve a lot of update version！

[kevinhicks]

@suchiagicha Would it be possible to have an CreateNonIActorProxy similar to CreateNonIServiceProxy? That would solve this issue; and was your recommended solution to the same problem for IServices as well.

I have attempted to add this myself, but run into problems when the Manifest Generator runs at build time, and is not looking for the Non IActor interfaces. Seems that there is a scripted build-time component that would also have to be updated.

[esbenbach]

Getting a "non iactor" proxy and support from the tools would be VERY much appreciated, currently we are hand crafting a lot of stuff that we could otherwise generalise with the help of a "non iactor" interface solution.

Don't really care if the Interface is placed in a separate package, the primary concern is the dependency on the IActor interface, especially the fact that it has to be the root - moving it "down the chain" so we can have a composite interface would unblock us just as well.

[esbenbach]

Any updates on this issue? Is it being considered, or just on the backlog still?

[hanxinimm]

@amanbha Do you have a plan? Frequent upgrades are a bad experience.

[hanxinimm]

???

[esbenbach]

@amanbha and @masnider or anyone really - are there any plans to do something about the issues here?

[esbenbach]

@craftyhouse I know this is an ancient issue by now. Just pinging you since you were the last PM seen alive ;)
Any chance this is being worked on?