I have two questions, I am pretty much inexperienced in this kind of stuffs and this is my first time I want to do this so I appreciate if you give me a clean guideline and if it's possible without too many jargons.
what is the simplest way to make an installation setup for my app.exe file? I saw some answers about WIX, is it simple?
2.This is my important issue, how can I make sure the client can only installs this application on only one system. He can buy one and installs on his own computer but not any other system after that.
I would appreciate If you help me with some links to easy to follow guides, I am a total newbie in this Area and this is my first time using windows and visual studio so I am not very familiar with them.
Related
I have a windows service for a schedule some jobs. It will be sold for a price.
I created msi file for setup. After the install, installed folder have an exe file and dll's.(By the way, I am going to install service on customers' computer, so they won't be have msi file) I found out, this installed exe file can be installed with InstallUtil.exe. I have done some research but I cannot found any good explanation. My questions is, how to forbid install with installUtil for installed exe? I am new to this area, any help will be good. Thanks in advance.
If I understand correctly, you want to prevent people using your software without paying for it. Unfortunately, it is impossible.
Your code, when it runs on the client, is fully controlled by the client. While you can make things harder, in the end no matter what you do, it will always be possible to run it without your permission. Take any commercial software and then search on torrent for pirate versions. :)
You can go lengths in trying to secure it, and the effort needed from an attacker may become somewhat higher, but it is logically impossible to prevent copying if all of the code is on the client.
What you can actually do is offer your solution as an online service (like a most commonly a webapp these days). That way control remains with you.
Update: 24 Mar 2011:
Just wanted to add that I've had a look at WIX now and it looks great, I can see very clearly now how to get a nice sleek MSI based installer done that should do everything we need. Thanks very much for the assistance, much appreciated.
We deploy a product which has both server and client components. The client is currently a VB6 application (yes, yes I know...) and it uses an InstallShield installer to produce an EXE that we give to the client to go and deploy on all their workstations.
That's all fine and dandy when there are ten, but when there are 100 they understandably get a bit grumpy :)
Some of our customers are using Microsoft System Centre to automate their software roll-outs and they have asked us to get our client compatible with this so that they can deploy automatically.
I have no experience with System Centre, so while i'm trying to build up my own experience I thought i'd drop a question in here and see if some of you experts could help accelerate the process.
Basically, what do I need to produce in order to have an installer that is good for deployment automatically via Microsoft System Centre?
I think i've found out so far that it needs to be an EXE, an MSI or an MSP.
As I've said, our current installer is an EXE - however it has a fairly standard wizard installer that pops up graphical stuff and asks the user to click next a couple of times. Is that causing a problem? Or should it just work? Or, is it a case of adjusting the InstalAnywhere script to make it fully automated (the UI doesn't really need to be there) ?
I should add that I don't actually know if anyone has tried this and whether the customer question is purely "let me know if it will work" or if they've tried it and it doesn't work... I'm probably heavily leaning towards the latter because I know at one site they've got what seem like knowledgeable IT that are keen to just try things and see what happens rather than constantly waiting for approvals etc.
Lastly a few things off the top of my head...
App is written in VB6.
InstallShield is quite old, i'm currently finding out what the version number is and will update the ticket as required.
Target platforms are Windows client, currently up to XP officially but it does work ok on Windows 7 and Vista.
I'm happy to use a totally different installer if that's the best answer, we're not tied to InstallShield at all, it's only really there for legacy.
Please let me know if I can provide any more detail!
Matt.
This question is very broad so there isn't one answer I can give. Basically I spent 15 years experience writing installers and 2 of those years were on the other side of the house at Continental Airlines ( 18,000 seat AD forest ) receiving installers from companies like yours.
Our goal was to be able to silently provision and service software through SMS. Ideally we prefer to receive MSI's because they are in a standardized format and are customizable through the use of transforms. When we would receive non MSI packages we would typically "repackage" them into MSI format. This is a process in which the package is ran through snapshotting / capture tools and the whole thing is reverse engineered and refactored into MSI.
But we didn't always do this. On a (rare) occasion we would receieve a higher quality then average EXE that was 'good enough'. The goals are clear: We must be able to install and uninstall the EXE from the command line with 0 touch by a human. We must also be able to script any configuration settings such as database server name.
If we could do those things and the impact seemed low risk, we'd accept it as is. Otherwise we went about our business of taking it on ourselves.
On occasion I would create an installer that was so clean I would think "Man, I wish ABC Software Company had done this themselves." ( Of course I wouldn't have had a job... ) or "I wish we could partner with ABC to contribute this install back to them for everyone else to share in the benefits."
Maybe one of your sites has a really good install guy and you could work something like that out on the cheap. Otherwise I suggest learning MSI and it's best practices and doing a rewrite of your installer.
It was a great experience being at Continental and I now make sure that all of my companies installs won't bring such pain to their customers.
Last year, in 2009 GSoC, I participated with an organization called Winlibre. The basic idea is having a project similar to Aptitude (or Apt-get) and a GUI like Synaptic but for Windows and just to hold (initially), only open source software. The project was just ok, we finished what we considered was a good starting point but unfortunately, due to different occupations of the developers, the project has been idle almost since GSoC finished. Now, I have some energy, time and interest to try to continue this development. The project was divided in 3 parts: A repository server (which i worked on, and which was going to store and serve packages and files), a package creator for developers, and the main app, which is apt-get and its GUI.
I have been thinking about the project, and the first question that came to my mind is.. actually is this project useful for developers and Windows users? Keep in mind that the idea is to solve dependencies problems, and install packages "cleanly". I'm not a Windows developer and just a casual user, so i really don't have a lot of experience on how things are handled there, but as far as I have seen, all installers handle those dependencies. Will windows developers be willing to switch from installers to a packages way of handling installations of Open source Software? Or it's just ok to create packages for already existing installers?
The packages concept is basically the same as .deb or .rpm files.
I still have some other questions, but basically i would like to make sure that it's useful in someway to users and Windows developers, and if developers would find this project interesting. If you have any questions, feedback, suggestions or criticisms, please don't hesitate posting them.
Thanks!!
be sure to research previous efforts on this. Google turns up several similar/relevant efforts.
http://en.wikipedia.org/wiki/Package_management_system#Microsoft_Windows
http://windows-get.sourceforge.net
http://pina.plasmite.com
IIRC there was an rpm for windows at some point
Also I think there was some guy (who used to work at MS) in the news recently that basically is starting up a very similar project. I can't find a link to this now.
But anyway, yeah, it would be awesome if there was such a standard tool and repository.
I can only speak for myself, but obviously I could definitely make use of such a tool as I found your post through googling! ;)
My two use cases for this tool would the following ones:
1. I generally avoid to re-install my system as long as possible (in fact I manage to do so only for switching to a reasonable (not each an every) new version of Windows every few years or to setup new computers). But still I'd like my software to be up-to-date. Neither do I want to have to go to all the web pages and check manually if there are compatibility issues with the new version of Doxygen, Graphviz and the latest version of MikTeX for example, nor do I want to have to navigate to the download pages and run the setups all by myself. I just want to schedule ONE SINGLE (!) tool, which checks whether there are new updates or not and updates those applications which are not in conflict with any other application version.
If it unavoidably happens to me that I have to re-install my system, I don't want to get the new setups neither (and check compatibility). I even don't want to wait for one setup to finish in order to start the next one, I just want to check the tools I need, or even better, I want to simply load my "WinApt XML" batch installation file, which gets the installers and handles the setups sequentially all by itself.
I don't know enough about the architecture of .deb or .rpm but IMHO the most reasonable would be to maintain a DB with only the names, versions, dependencies and the location of the different versions' download locations. I mean, most of the tools available for Windows provide .msi packages anyways, which (I guess) is the application itself and some custom installation properties (really not sure how scripting is handled, but I know that creating a MSI in Visual Studio has very limited abilities to create custom installation steps and I can only imagine this is due to limitations of MSI protocol).
I guess a GUI will be mandatory for Windows users ;) but I personally would prefer the additional ability to handle the setups with the console.
Well, I like the idea and would love to hear from that (or such a) tool in the future.
Cheers
Check out NSIS. It's an open source MSI creator. You might be able to use it as part of your package creation software.
http://nsis.sourceforge.net/Main_Page
For the ALT-.Net tool/lib stack there have been some affords in this direction: Horn Get
However, the usability in a real world project has been subject in this SO question.
Is there any way to make an installer that is very user friendly?
I know it's impossible for a Next Next Finished installer but what can I do to ease the process?
Windows platform.
Thanks in advance.
If you've got a very simple application and basically just need to copy a few files, I'd suggest looking at NSIS. It's very simple and you can probably have an installer done in a couple of days.
If you're developing software for a corporate environment where network rollouts are a priority, then you'll probably want to take a closer look at Windows Installer and Windows Installer XML (WiX). (Warning: a very steep learning curve - you'll want to set aside a few weeks and probably read this book to help get started)
If you want the benefits of MSI, without the hassle of learning the underlying technology then a commercial tool such as Installshield is your best bet. It's not cheap but you'll get something out the door pretty quickly.
Long term I'd advise learning Windows Installer technology. It's something overlooked by most developers, it's often seen as crazy voodoo that is overly complicated and unnecessary, in reality it's rather quite simple, just a database with a whole bunch of rules, conditions, and quirks that take a bit of getting used to :)
Try BitNami WAMPStack it is open source and free (you also have Linux and OS X versions)
If I understand your question correctly, I'm not sure how you didn't find this already...
http://www.wampserver.com/en/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I recently had to struggle with one installation project (which uses most popular product for creating installations: InstallShield) to make it work for product upgrades (migrating from one version to another). In the end it turned out that I needed to use one long package code but was using some other. It wasted my 8 hours (testing and debugging installers is a pain).
Now if I think about it, once you are done all the hard part of coding, all you want to is that correct applications, libraries are copied to target computer and user just runs it. Period. This apparently simple task normally turns out to be a tricky one and "being closed to finish date" makes in even harder.
Don't you think deploying a product is made damn difficult on windows which should have been simpler? (or installer really deserves that much attention and I am just being crazy about it?)
Have you ever used simpler deployment schemes such as "copy the folder to wherever you like and run the exe. When you want to remove it, just delete the folder!"? Was it effective and made things simpler?
Painful as it is you need to wrestle with the windows installer for the benefit of your customers. Otherwise you will need to do a lot more work to
Handle situations where for some reason an error occurs during the installation. What do you do next?
Handle issues like security. What if the installing user does not have rights to particular folders/registry keys?
Correctly cleanup after installation
Patching and patch management
Performing additional tasks -- registering COM objects, creating databases, creating shortcuts, creating an un-installation shotcut and so on
Installing prerequisites
Letting users choose which features to install
Your own custom scripts to solve all these problems eventually become a bigger problem than the installation itself!
I recommend that you check out Wix. It's not exactly child's play but it gets the job done. If you install Votive as a visual studio add in you get intellisense to help you strucutre the tags correctly. With the help file you can create pretty functional flexible installations
I don't think you'll see too many disagreements here, especially regarding MSI. I think one thing to keep in mind is to watch the way many programs are using MSI files these days. Displaying UI dialogs and making complex configuration choices with an MSI is very weak simply due to the way Windows Installer was designed, so I've noticed a lot of programs being split into a bunch of baby MSIs that are installed with the minimal UI by a parent setup program. The SQL Server 2008 setup wizard does this. UPS WorldShip does this. And Paint.NET does this, too--the wizard you see is a Windows Forms app, and it launches msiexec itself (you can see the minimal UI of the Windows Installer pop up on top of the white wizard window), passing any configuration parameters as property arguments to msiexec.
A common scenario where this comes up is where someone is tasked with building an installer for an application that has both server and client counterparts. If the user chooses the server option, then they may or may not want a new database to be installed, which means installing SQL Server. But you can't just install SQL Server while you're in the middle of your own installation because Windows Installer won't let you do that. So a frequent solution is to write an app that displays a wizard that allows the user to configure all of the setup options, and then your app launches the MSI files as needed for SQL Server, your server application, and your client application in the minimal UI mode; basically, eschewing the "features" aspect of Windows Installer entirely and moving it up to the MSI level. 4.5's multiple-package installations seems to be a step further in this direction. This format is also especially useful if you also need to loop in non-MSI installers from third parties as part of your installation process, like installing a printer driver for some bizarre point of sale printer.
I'll also agree that Windows Installer lacks built-in support for common deployment scenarios. It's meant for when setup isn't XCOPY, but they seem to miss the fact that setup usually isn't just "files + shortcuts + registry keys," either. There are no built-in actions for setting up IIS Web sites, registering certificates, creating and updating databases, adding assemblies to the GAC, and so on. I guess they take the opinion that some of this should happen on first run rather than being a transactional part of the install. The freely available tooling and documentation has been awful--flat out awful--for the better part of a decade. Both of these issues are largely addressed by the WiX project and DTF (which lets you finally use managed code custom actions), which is why we're all so grateful to Rob Mensching and others' work on that project.
I've had the same experience. Installation can quickly suck up your time as you go down the rabbit hole of "Oh God, I guess I have to become an expert in this too." I second the idea that's it's best to address it early on in your project and keep it maintained as part of your build process. This way, you can help avoid that scenario of having developed a practically uninstallable product. (Trac was an example of this for a while, requiring to track down specific versions of weird Python libraries.)
(I could go on about how Windows Installer sometimes decides to use my slow, external USB hard drive as a place to decompress its files, how it seems to sit there doing nothing for minutes on end on computers that have had lots of MSI installs on them, and how that progress bar resetting itself a bazillion times during a single install is the most idiotic thing I have ever seen, but I'll save those rants for another day. =)
My two cents; please note that I really just know enough about Windows Installer to do damage, but this is my assessment coming from a small business developer just trying to use it. Good luck!
Well, its a lot easier if you build your installer first, make it part of your build system, and let it grow with your project.
I agree, the windows installer drives me insane. But there are a lot of situations that xcopy just doesn't solve. Sometimes you want to install for multiple users, not just the current user. Sometimes you have to register COM objects. Sometimes you have to make a whole bunch of changes to the system, such as registering services to run at startup, connecting to network servers, etc. Sometimes you have users that can't use a command prompt. And you always want to be able to role the whole thing back when something fails halfway through.
Was the whole MSI database approach the best way of doing it? I'm not sure. Would I rather pound nails into my head than write another line of WiX code? Probably. But you have to admit, it does a good job of doing everything you could ever possibly want. And when it doesn't there is always the CustomAction option.
Really, what I would like to see, is better documentation (really, what is a type 50 action? How about giving it a name?) and a lot more easy-to-usurp templates.
And the WiX users group alias does a good job of answering questions.
You should read RobMen's blog. He does a good job explaining why things are the way they are. He has done a lot of thinking (more than any human should) about the problems of setup.
Have you looked at NSIS: http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System ?
And 1: Yes, 2: No
Personally, I mostly agree with #Conrad and #John Saunders. I wrote about this topic a long time ago on my old blog. I think #jeffamaphone has a point about the Windows Installer complexity (and my over attention to setup, in general ) but I believe the Windows Installer is still the best all round option for installation on Windows.
"Once you have done all the hard part of coding", you haven't done a thing if all your hard work doesn't install. Installers need to be built and tested on every nightly build, every night, almost from day one. You need to test that the installer can be built and run, and you need to verify the installation.
Otherwise, who cares how much hard work you've done coding - nobody will ever see your work if it doesn't install!
Note that this also applies to XCOPY.
Another thing: what is your QA testing if they're not testing what your installer installs? You have to test what the customer will get!
For exactly the reasons you state, we've done internal releases, handled by the dev team by copying the required files, and then done the rest of the setup using scripts and our own utilities.
However, for end users you have to have some kind of hand holding wizard, I've used the MS installer from within VS and found it confusing and clunky. After that experience I've avoided the pain by getting others to do the installation step. Can anyone recommend a good .Net installer?
I use Installshield and if you are not trying to do anything too fancy (I why would you) then it's pretty straighforward - set initial setting, select files, set up shortcuts and create setup.exe.
All future updates I handle inside my code - much more convinient to the user