SW development life cycle for .NET FW application-CodePudding

We have legacy .NET FW 3.5 App. Me as a DevOps engineer I'm responsible for CI/CD pipeline for this app. I have experiences with deployment different kind of application. SDLC for Java, JS, Python, Docker, Helm, all of these are pretty clear to me, but I need some help with this .NET world.

I'm following git flow, so expect this behavior: Develop branch build: checkout, build nuget package, deploy this snapshot version to binary storage, deploy the nuget package to server and run the app Master branch build: checkout, build nuget package, deploy and promote the release version to binary storage, deploy nuget to server to UAT environment.

But for me it seems nuget packaging is more used for storing libraries, dependencies, etc... But what is the proper way of keeping the application binary in binary storage for some kind of .NET FW backend application for example?

CodePudding user response：

First of all: make sure to use .NET Framework 3.5 Service Pack 1 - otherwise you'd be out of support. Or even better, upgrade to a newer version if possible. But back to topic.

You're right, platforms like nuget.org are intended to be used to store dependencies, not the applications itself.

Artifactory is imho a bit special, because one could argue that it is a generic artifact storage - both for dependencies and the application itself.
So if you have a NuGet feed on Artifactory, only the application's dependencies should be placed there (either mirrored from nuget.org or company-internal NuGet packages as well).
But I think it's totally fine to create a dedicated Artifactory feed where you place the application binaries as they'll be consumed/deployed in production.

Regarding the .NET world: .NET Framework 3.5 is so old, no common and widely adopted approach existed back then to store and versionize application artifacts - at least I don't know. Some use an FTP share, others only the production servers, etc.
Nowadays it is most likely that a .NET app (e. g. microservice or web API) comes as a Docker image, stored on whatever Docker registry is appropriate.