|
Have anyone used WixSharp? I've used it only once on a small project and it was simple to use. But I cannot say anything more.
|
|
|
|
|
Using Ghost Installer myself. Dunno if it's THE BEST EVA, but it works.
There's also ClickOnce (which is actually what MS offers, that's integrated into Visual Studio).
|
|
|
|
|
Yet another vote for Inno Setup[^]. Basic setups are handled using the built-in facilities, starting from a text file script. It includes competent scripting support based on Pascal. For really heavy lifting you can call out to DLL's. Scripts can be compiled from the command line. It receives pretty steady support from its author.
As others have mentioned, Inno Setup's only lack is that it doesn't support MSI. For my money, that's a benefit. MSI and the Windows Installer are over-engineered and poorly documented and supported for the task they are meant to accomplish. Most of the installer-building apps based around MSI are just expensive lipstick on a pig.
You mentioned you're using InstallShield. Be advised that they are #2 on my list of development teams first-against-the-wall-when-the-revolution-comes. We bought their 'international' edition for over $1K a little over ten years ago after the salesperson told us that it supported most European languages, along with Japanese, Korean, and Chinese. Come to find out, the international edition only supports English. You had to pay an additional $500 for each language you wanted to localize your install to. We chucked those ripoff f***ers and went with Inno Setup.
Software Zen: delete this;
|
|
|
|
|
I've used .msi installers forever, but had to give them up a few years ago because of their basic clumsiness, their lack of bigcorp support and the fact that they throw security principles to the wind. Advanced Installer was my last one used.
It took me more than 3 years to develop my distributed installer called Hiveware. It overcomes the security issues and the ease-of-use problem as the user only sees the asked-for app functionality. The platform was finished in December, 2017.
|
|
|
|
|
Another vote for Advanced Installer. It has an unbelievable range of options but the defaults are sensible, and support for occasional bugs is excellent.
|
|
|
|
|
My first question is, what about this application cannot be delivered over the internet?
Make it a webapp, just deploy it to servers you control.
|
|
|
|
|
We have a client/server WinForms application. We use a standard VS setup project to create an MSI for our initial installs, but the application is "self updating". We upload new EXEs and DLLs into our SQL Server database. The application looks for new components when it launches and when it finds new ones, downloads them to a temporary location, launches an "updater" EXE, and kills itself. The updater moves the new EXEs/DLLs from the temp location to the application folder and re-launches the main EXE. Works like a champ.
|
|
|
|
|
Ditto! We do the same, only using an installer (InstallShield) for the initial installation. After that, the application handles any updates to itself and associated files. Of course there are manual update mechanisms in place just in case we put out an update that breaks the updater! 
We also use home-brewed installers for add-on modules using 7-Zip self-extracting libs to create 'smart' installers that detect where the payload needs to go and optionally (on a first install) prompt for a password. They also clean up after themselves.
"Go forth into the source" - Neal Morse
|
|
|
|
|
I use InstallAware. It's pricey, but does everything easily. We have several complex installs and lots of files, so for us it was worth it.
Bond
Do everything as simple as possible, but no simpler.
|
|
|
|
|
InstallShield is still the reigning king for us - 30 years and counting
Do you use InstallShield Standalone Build for CI?
|
|
|
|
|
Currently, we have a scheduled task that runs every morning to build the installers (IsCmdBld).
The main issue we have with InstallShield is that its something that is hard to maintain (people add/remove files from the distributions but there's only one of us that can update the installshield project).
I'd rather be phishing!
|
|
|
|
|
Quote: InstallShield is still the reigning king
King - Reminds me of the fable of the King's new cloths 
|
|
|
|
|
Windows? WiX for the WIN!
And it has a Microsoft connection in that it was one of the first Microsoft open source projects.
|
|
|
|
|
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least.
1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced.
2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win.
3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers.
4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable.
5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable.
6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number.
7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm.
8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantially reduce that contribution to the complexity equation.
9. That most of the software written out there is written by people who have not done exactly that thing with exactly those tools and techniques ever before, and that this will always be a major contributor to bugginess, delivery problems, etc... Even if there are very experienced people involved, they most likely have not done something just like that using those tools and techniques, and that this is a big part of the complexity problem.
10. That, as a corollary to #9, we don't REALLY need more tools and techniques to create good software. There's been enough around for a long time to do that. Sometimes, if you want to create something really significant, you just have to choose a set and stick with them for the long term.
11. That, related to #10, too many people in the software business worry too much about software related minutia than the real reason that software exists, which is to create software for other people outside of the software business for the most part. All customers care about is does it work, is it reliable, does it meet my needs. They could care less if it was created with C++ 0 or C++ 50 or Rustoleum or Anaconda. This is sort of a problem with all specializations I guess.
12. That, as a corollary to #11, the people who work completely within the realm of creating software for other software people tend to suffer a double dosage of this problem.
13. That SFINAE, though it works, is a pretty sub-optimal way to achieve things relative to something designed specifically to achieve that goal, resulting in incomprehensible error messages, and the possibility that some small change could cause a significant change in the actual workings of the program without any indication that this happened, because so much of the 'code' is actually being selected at compile time on the fly, not through explicit selection by the developer. So much depends now on a ladder of magical matches and failures, that most people using them probably have no real clue as to the possible gotchas of. Maybe I'm being too cynical, but it seems that way to me.
14. That all software doesn't need to be all things to all people. Don't massively increase the complexity of an already very complex piece of software to meet the needs of the 5%. Let the 5% fend for themselves with tools specifically designed for their off the beaten path needs. Deliver to the 95% a product more likely to be bug free and remain so over years and huge changes, and with more features because you spend far less time dealing with complexity.
15. That the browser has been one of the biggest detriments to software development ever. All the same growing pains just started over from scratch, and endless effort trying to make the browser into a viable application delivery mechanism and it still is pretty pathetic. We'd have been better off putting that effort into create a widely supported common API that can be supported on major platforms for semi-native cross platform development. But of course human nature, being what it is, would never have allowed for that. It's like VHS won, and we just kept trying to make VHS do more and more stuff it was never intended for.
16. That we are inevitably being pushed towards a cloud based world where not only won't the customers own their own software, the developers won't even own their own experience base. More and more of the actual code will be provided by the cloud vendor and running there. I don't think that is in any way a good thing. Push everything to be as complex as possible and to require enormous computing and AI resources, so that more and more companies can't even try to do it, they'll just be people gluing bits of code together that they not only don't ever never see the insides of, they never even actually have on their own machines. At least in the mainframe days it was your own code you handed to the guy in the lab coat.
17. That open source software, though it clearly serves a useful purpose in the area of 'plumbing' type software, and though I've written my share, is actually counter-productive once it goes beyond that. It competes with products in the same space that would actually create jobs and new experienced software engineers. In the ultimate sense it's a self-defeating proposition, because it's only the availability of jobs in the software industry that encourages people to become software engineers and get good enough to contribute high quality code to such projects. Yes, there are some companies that pay people to do that work, and I was one, and they support that work via other means such as services. But that could never support more than a tiny fraction of what is out there.
18. That software languages (and their official related supporting libraries) shouldn't try to be all things to all people. That tends to lead to ever great complexity and feature creep, which makes it harder to learn and harder to understand the ramifications of using any particular aspect of it. That makes it less likely it will be chosen by new developers, which then becomes a counter-productive cycle, i.e. that it will become more and more byzantine in order to try to compete and 'stay relevant' and seem 'active'.
19. That it is a negative for the supporting libraries of a language to become a requirement in order to use core language features or to have significant amounts of privileged functionality. That locks that language into a single paradigm and limits creativity in application of that language to provide alternative ways of working. Yes, in some higher level languages that's just a given because of how they were created, but in lower level languages I argue it's something to be avoided, because it means you can never fully impose your own unique character to a system built on top if it (unless you are willing to sacrifice those magic capabilities, and maybe not even then.)
20. That 'design patterns'-speak has become a sort of dogma and failure to comply sometimes creates so much negativity that it overwhelms the important issues of the concepts and techniques involved and being discussed.
21. That the modern trend towards pushing a button and some package manager downloads tens to hundreds of packages that the developer knows nothing about, and may never even once look at, is one of those things in the 'makes it easier but worse' category, particularly given the security landscape these days. And we are all just happily running that software, well maybe not happily but still.
22. That none of the major languages currently in existence really even come close to optimal for the needs of modern software development. But, OTOH, even if one exists out there, it has almost no chance of becoming a new major language. Even ones that are backed by huge companies will probably not manage to be more than niche languages. And I various others here could probably design one, but that would be even orders of magnitude more futile. It's a huge chicken and egg issue. MS managed it because they owned the predominant desktop OS and the development tools used by most people on it (not that I think C# is anywhere near optimal.) No one is in that position anymore, I don't think.
23. That software engineers, though not all of us are totally on the Asperger's spectrum, are mostly pretty dang close to it, and that creates a lot of the problems that exist in the software world. Add the always present dogmatism and tediousness that accompanies most heavy specializations with a heaping lack of social graces and ability to deal with disagreement well, and the testosterone heavy population of young males that dominate this thing of ours and, well, here we are.
24. That, it seems to me, anyone who really loves software development will take on their own projects independently of their mercenary work life (unless of course their mercenary work life is their own project.) When I said that this is something I'd put a good bit of emphasis on if I was choosing candidates for a job, some folk acted like it was some sort of racism and that it should be disallowed by law. Of course my mercenary work life is my own project, but I worked on it hard for a decade on the side first. I look at like this: If I need a heart operation and my choice is the guy who lives it all the time, or the guy who golfs as much as possible and only thinks about it when he's getting paid, which one am I like to hire? Doesn't mean golfer-dude is going to flub it, but I have to make that choice before the operation, not afterwards.
25. That the current trend against OO is basically driven by the same forces that make one generation want to choose any music not that of the previous generation's.
26. That, related to #25, I think that may folks, having come up in the OO world, and never seen anything else at scale, see the problems that OO has and think that there must be something else that is better. So they gravitate towards something that was proven to be far worse, and hence the reason that OO became dominate. But the complexities of the problems being solved and of the real world are not going to go away or be lessened by moving to some functional or non-OO paradigm. Those are inherent to the task at hand, not the fault of the OO toolset. And OO has proven itself to be (IMO) the least least capable tool to tackle these complex problems.
27. That the influx of people into software development who came from the web world is creating an imbalance in the force. The fast and loose style of Javascript is not appropriate to larger scale development. And #21, which is big in the web development world, would be a horrible thing for more serious development, though I see it happening more and more. C# has sort of become that now in some ways, though most of the bits and bobs are from the language vendor themselves. Still, it's all sort of auto-magical for a lot of folks I think, and that's never been a recipe for more robust software, IMO.
28. That the 'democratization' of software development has done as much damage as it has helped, maybe more. This is always a touchy subject; but, as much as I believe in democratization of most everything, my belief doesn't necessarily mean it's always going to improve things, human nature being what it is. So many people are going in so many different directions, that we are in the Lollapolooza phase of software development, where two people can go to the same festival and never even hear the same band.
29. That the state of cross platform development is woeful. I'm all for competition, but had the major players made any sort of efforts over the last decade they could have put enough support in place on their respective platforms to support a non-hacky, reasonably featured portable API layer for the development of at least applications of modest proportions. The ongoing attempts by various parties, including some of the major players in isolation, are mostly just sad at best.
30. That there is maybe serious age'ism in this industry? Combine that with the always present 'not invented now' syndrome that every generation has, and that just makes it worse?
|
|
|
|
|
tl;dr
Better in your blog than here where it'll disappear soon.
modified 14-Feb-19 13:36pm.
|
|
|
|
|
TL:DR
Having said that, I agree with #30.
P.S. I've never had to scroll the screen down just to click on "Reply" before.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
rule number one would put the odds of a bug at 100% after the first copy/paste?
modified 20-Oct-19 21:02pm.
|
|
|
|
|
That seems to be about right for me.
|
|
|
|
|
31. Having read 1, 2, 3 and 29, 30, I believe 4 through 28 are probably true as well.
Latest Article - Slack-Chatting with you rPi
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I can't find mention of Firefly, so you may want to make some revisions.
[edit] It's a bit much to discuss, BTW. Maybe if you made one or two statements per posting, and gave us a day or so to work through them, before posting the next -- a TIBtbTOTD, as it were [/edit]
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Maybe I've discovered a way to post something semi-opinionated on the internet and not get attacked as an infidel. Just saturate their sensors and they can't see what I'm saying.
|
|
|
|
|
Dean Roddey wrote: Just saturate their sensors and they can't see what I'm saying.
Doesn't that retract the whole point of posting to begin with?
|
|
|
|
|
Actually, caring enough about other people to worry if they read your posted wisdom is so 2010s. The internet has now moved beyond the 'look at me' phase, and is now moving into the 'just me' phase.
|
|
|
|
|
And, just to throw another one in there:
31. That every new post I make on this form will get marked as potential spam and held.
|
|
|
|
|
Dean Roddey wrote: 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable.
Every time a language update includes "shortcuts" that pack more stuff into 1 line of code, the reliability goes down and the duration to produce Production level executables goes up. On my current project, this is case in point. We tear apart such code in order to be able to debug it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
