Yes - you should be able to use the same approach with winforms projects.
Now I'm sure Scott is a smart .NET developer, but this type of `xcopy deployment` that is tightly coupled to build automation is crazy. Furthermore, I know he's not alone in this thinking since if you pick up practically any .NET book you won't find deployment covered until the end of the book and even then it's a cursory look at VDPROJ as if deployment is that simple.
Build ( Core Code and Installer Packages ), Installation and Configuration are NOT the same thing. They are distinct steps in an overall process of deploying an application.
You may very well need to do all three of these steps within a single transaction ( for example automatically deploying an application to a Dev Integration Lab as part of a CI process ) but the steps are still separate.
Now some people disagree on whether an Install should actually configure a product or not. Regardless the build output should consist of a setup package. If you want to automate the deployment the build should then call staging automation to apply the package. If the package contains configuration logic, the staging automaton should pass those values to the package. If not, the staging automation should call an external utility and pass the values so that the product is ready to be used. In this way the staging automation could be invoked multiple times to stage Dev, QA, Production, whatever.
Scott's solution might be `OK` for an in house application that only gets `deployed` to a limited no of locations, but if you are working on a real `Product` that gets sold and given to customers all over the world you will really want to make a proper investment in automation.
2 comments:
It's rather unfair to say that "if you don't deploy to multiple customers, you don't have a "real" application".
The webdeployment project and web.config replacement works excellently for web projects, and the same process can be applied to .net apps.
Yes, his example uses Visual Studio. It is better to use something like CC.Net so that you have the next step of automation.
Not everyone can afford, or wants to spend money on expensive automation tools.
Based on your paraphrasing, I don't think you understood what I was saying at all.
I didn't say an in house application wasn't a "real" application, I was saying it's not a "product".
When I say "product" I'm talking about something that is fully shrinkwrapped and sold on the open market. Think Sharepoint or Team Foundation Server. These installers have to be very robust and easy to use.
An internally hosted application is more of a service and hence can have simpler deployment requirements. Hence why the solution is "ok".
Post a Comment