StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
1977398
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2009-12-29T22:46:48.203
FavoriteCount
0
LastActivityDate
2009-12-29T22:46:48.203
LastEditDate
LastEditorUserId
0
OwnerUserId
60096
ParentId
1977371
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
MSI pros: <ul> <li>Application/service/site gets installed and registered like most other Windows apps, and shows up in Add/Remove programs</li> <li>Some built-in support for re-installing, upgrading</li> <li>Has some built-in support for installing Windows services/IIS sites/lower-level Windows features</li> </ul> MSI cons: <ul> <li>Seems really cryptic once you get "under the hood"</li> <li>Seems more difficult to customize than using a custom script</li> </ul> Script pros: <ul> <li>Easier to customize, although certain steps might require lots of/cryptic scripting (working with IIS, lower-level computer administration)</li> <li>Don't have to deal with low-level weirdness of MSI</li> </ul> Script cons: <ul> <li>.bat scripting is not the most readable or writable language. (Powershell is better, but then you have to worry about whether Powershell is installed on the target machine).</li> <li>Low-level operations require a lot of administrative scripting for commit/rollback behavior</li> <li>No built in support for installing or rolling-back (MSI has some support built-in)</li> </ul> One thing I've come across that helps with MSIs is WiX (<a href="http://wix.sourceforge.net/" rel="nofollow noreferrer">http://wix.sourceforge.net/</a>), but even WiX seems pretty cryptic in a lot of ways. We use a combination of MSBuild and WiX to do automated builds and deployment/installs, and it works okay for us. Overall, I'd probably lean more towards doing MSI/WiX (or other installer toolkit) deployments over scripts. MSIs are the standard way of doing installs on Windows, and once you get it working, you usually don't have to change too much. MSBuild or some other build framework (NAnt, etc.), can be useful for setting up the deployment (renaming files, doing string replacements, etc.), before putting together the final MSI package.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODeployments: MSI packages vs Scripts
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAndy White
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. PODeployments: MSI packages vs Scripts
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.