In an Actor project, the AssemblyVersionAttribute
value is used to update the ServiceManifest
version, along with the code and config version. There is no such behavior for Service projects.
This updated version is also used to update the ServiceManifestRef
's ServiceManifestVersion
reference in the ApplicationManifest
. While the ApplicationManifest
is modified on every build, it doesn't appear a manually set version within the Service project's ServiceManifest
is updated in the ApplicationManifest
either.
Is this planned or intended behavior for Service projects?
I'm running Visual Studio 2015 RC, the first preview of the Service Fabric SDK, and 4.0.95-preview1 of the NuGet packages.
Service Fabric addresses the significant challenges in developing and managing cloud apps. On the other hand, Kubernetes is detailed as "Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops". Kubernetes is an open source orchestration system for Docker containers.
Service Fabric powers many Microsoft services today, including Azure SQL Database, Azure Cosmos DB, Cortana, Microsoft Power BI, Microsoft Intune, Azure Event Hubs, Azure IoT Hub, Dynamics 365, Skype for Business, and many core Azure services.
A single Service Fabric node type/scale set can not contain more than 100 nodes/VMs. To scale a cluster beyond 100 nodes, add additional node types.
Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers. Service Fabric also addresses the significant challenges in developing and managing cloud native applications.
Short answer: This behavior difference is temporary as we improve our tooling support for versioning and upgrade.
Slightly longer answer: Part of the original goal of the Service Fabric actor framework was to abstract away the details of manipulating the application and service manifests so that you can truly focus on your business logic. Hence, the SDK includes a tool (called FabActUtil) which is responsible for doing some of that manipulation on your behalf as a post-build step. There is currently no such tool for reliable services projects. We are considering options for reconciling this difference as part of adding upgrade support to Visual Studio. We need to strike a balance between keeping you in control of your versioning scheme and taking care of the chore of cascading your version changes throughout the application as required.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With