0
votes

This post is not for a specific coding issue. Rather, what would be the overall, best practice file structure in a Visual Studio solution of microservices in Azure Service Fabric as well as test and debug?

This may be an obvious question with simple answer. However, I couldn't find an explicit answer in MSDNs or other articles.

Two questions which are also tied together:

  1. I currently have a couple of Visual Studio solutions with each solution containing multiple projects (services). My concern is how decoupled these services are in terms of publish, deployment and versioning in the Service Fabric environment. I hope I am wrong in thinking that these services are now tied together in terms of deployments and versioning. Hopefully each individual service can be deployed and published independently onto Service Fabric.

  2. A lot of times these multiple services in multiple Visual Studio solutions work in chain in achieving end to end business flow. I literally have to open multiple Visual Studio instances to debug and test. I almost thought of merging them into a single solution to make debugging more convenient. I wish there was a more effective and convenient way to test and debug without having to combine them all into single solution or running 10 Visual Studio solutions.

1
I literally have to open multiple Visual Studio instances to debug and test. A potential option is to write a script that deploys multiple services. Then you could use Visual Studio to debug the remaining service. This wouldn't take advantage of your local cluster, however.Super Jade

1 Answers

0
votes
  1. Yes, services are individually versioned. Even the elements that make up a service are versioned (code, data, config). Everything can be updated independently.

  2. When you deploy an application to a (dev) cluster, you don't have to delete it after debugging. You can just leave it running. This way, you can debug a single service, while the others are running without a debugger.