How to version and separate Service Fabric applications?

Yep, it's possible - I've done something along these lines before. These are the thoughts that spring to mind immediately...

In each Service Fabric solution have a "public" project containing just the interfaces that you want to expose from the services in that application. The output from this project could be packaged as a nuget package and pushed onto a private repository. You could call it the "interfaces" project I guess, but you wouldn't have to expose all the interfaces if you wanted to consider some of them internal to your application; these could be defined in a separate, unexposed project.

Other solutions that want to reference the services exposed by another application just had to pull down the relevant nuget package to get a reference to the service interfaces.

Now this isn't without problems:

• The consuming application still need to know the addresses for the services in order to construct proxies for them. You could either expose them as constants defined somewhere in the nuget package, or if you're going down the full DI route and don't mind coupling yourself to a DI container everywhere (or fancy trying to abstract it away), you could expose a module from the nuget package that can register the services interfaces as a lambda that does the service proxy creation on behalf of the dependent applications.
• You are much more vulnerable to breaking contracts. You need to be really careful about updating method signatures as you are now responsible for the granularity and co-ordination of application/service deployments.
• You can go too granular - as you mention, the Service Fabric tooling guides you toward having multiple services in one solution. Even with the above approach I would still try to logically group my services to some extent, i.e. don't go for a one-to-one mapping between an application and service - that will definitely be more pain than it's worth.

Hope that helps.

EDIT:

An example of registering a service interface in a DI module, (Autofac style)...

This would be the DI module you expose from the public nuget package:

using System;using Autofac;using Microsoft.ServiceFabric.Services.Remoting.Client;public class MyAppModule : Module{    protected override void Load(ContainerBuilder builder)    {        builder.Register(component => ServiceProxy.Create<IMyService>(new Uri("fabric:/App/MyService"))).As<IMyService>();        // Other services...    }}

And in the Program.cs of your consuming application, you'd include something like this:

public static void Main(){    try    {        var container = ConfigureServiceContainer();        ServiceRuntime.RegisterServiceAsync(            "MyConsumingServiceType",            context => container.Resolve<MyConsumingService>(new TypedParameter(typeof(StatefulServiceContext), context))).GetAwaiter().GetResult();        ServiceEventSource.Current.ServiceTypeRegistered(Process.GetCurrentProcess().Id, typeof(MyConsumingService).Name);        Thread.Sleep(Timeout.Infinite);    }    catch (Exception e)    {        ServiceEventSource.Current.ServiceHostInitializationFailed(e.ToString());        throw;    }}private static IContainer ConfigureServiceContainer(){    var containerBuilder = new ContainerBuilder();    // Other registrations...    containerBuilder.RegisterModule<MyAppModule>();    return containerBuilder.Build();}

Of course, this approach will only work if you aren't partitioning your services...

You can also use less loosely coupled protocols eg http based using either xml\wsdl or json\swagger and autogenerated or manually created httpclient proxies.

The cost of managing a nugget lib ,nuspec etc is high.