Use project references in sfaproj projects

Azure / service-fabric-mesh-preview

Service Fabric Mesh is the Service Fabric's serverless offering to enable developers to deploy containerized applications without managing infrastructure. Service Fabric Mesh , aka project “SeaBreeze” is currently available in private preview. This repository will be used for tracking bugs/feature requests as GitHub issues and for maintaining the latest documentation.

MIT License

82 stars 12 forks source link

Use project references in sfaproj projects #154

Open allanFunrock opened 6 years ago

allanFunrock commented 6 years ago

Currently the sfaproj projects automatically detect service projects via the ´FindServiceProjects´. while this might be convenient in some cases it breaks solutions that contain more than one application (as our solution currently does). In my opinion its also not how msbuild projects works in general.

Instead, sfaproj files should use ProjectReference like other dotnet projects does. Not only would it be more consistent, you could use existing targets to find project references.

allanFunrock commented 6 years ago

Ah, I see now that multiple applications in a solution is supported since the service.yml specified what application the service belongs to.

However I still think ProjectReference should be used:

Its more idiomatic to dotnet
Its faster since all projects does not need to be examined
It would allow a single service to be part of multiple applications
It would make services completely independent of applications witch would allow them to be packaged separately possibly as nuget package (something I've been thinking about for ServiceFabricSdkContrib)

BigMorty commented 6 years ago

@sgreenmsft

sgreenmsft commented 6 years ago

@MikkelHegn - Perhaps you could comment on the idea of removing the Application name from service.yaml and making the service a standalone entity?

tomkerkhove commented 6 years ago

That would be great because that will be required for #147

mikkelhegn commented 6 years ago

The Service Fabric Mesh application model doesn't know about services as independent entities. The top level resource is Application and you will not find e.g. Deploy Service APIs in the runtime. So whatever hits the cluster or service will have to be an application, which is similar to the concept most of you know from the Service Fabric Native model we have today.

This doesn't mean that you cannot combine your containers or service.yaml files in different application constellations, but it has to be a feature supported by some tool. The service.yaml to application resource feature today is in the SDK tool which basically takes any set of yaml files and overlays them to one as an output. You could be fairly creative with the feature for the above use case.

E.g. add the following yaml files to the tool: service1.yaml service2.yaml override-service1.yaml override-service2.yaml service3.yaml and output an ARM template. service1.yaml service3.yaml and output an ARM template.