I am about to publish my first small piece of software. The software is in VB.NET and I have used Visual Studio 2013 as my IDE.
What are the steps I should think about before publishing and do you have any suggestions on how to complete each successfully?
Here is an incomplete list of the steps that I have thought about so far. But I don't know if I may be missing other important steps
Create an installation package (Status: I have created one using WIX)
Obfuscate the code (Status: I have obfuscated it using the built-in obfuscator in VS 2013)
Have a T&C that doesn't make me liable if my software causes problems (Status: I haven't looked into this yet)
Create a demo and a registration mechanism (Status: I don't know how to do this yet)
Please let me know if my list is pretty complete or if there might be other things that I haven't thought about and that might cause problems for me down the road.
That sounds probably obvious but:
Try to install/update the software on every supported platform
Install and test the software on a different machine than your development machine to find dependencies that users may not have
Ensure that Logging is working as expected and that it gives you the information that you will need to fix issues
Test how you will fix issues (integrated update, ...)
List all 3'rd party libraries you have used with their licenses
Create a Help/FAQ or Documentation
Figure out how to licence the application and how this behaves when uninstalling etc.
A good list can also be found here.
Related
How can I create an automated Installer for a program that has a regular Installer with questions like:
Install Directory,
Accepting License,
Creating Icon on Desktop
etc...
Assuming that I am OK with building an Automated Installer for every program I want to separately, Or i want to put files in a Self Extracting Archive and run the Installer after unpacking.
Do I need a third party program for it? Should I use Command Prompt? Do I need to learn Lua? (I'm learning C#)
EDIT:
To clarify I'll use an example:
Let's say i wrote a program but that program has a requirement, like
DirectX, or Adobe Air, or Maxthon Browser.
I wrote my program in such a way that I have to be sure that that is
installed in a very specific Drive/Folder on the PC or with some
specific preferences/parameters.
I include an installer for this program, but I want to specify where
it gets installed on the PC and with what parameters.
Preferably Installing this requirement right after or during the
Installation/Extraction of my own program.
I'm looking for a way to be able to run the Installer of any given program and navigate through the install wizard of it with out the user having to/being able to change the settings I need (with the foreknowledge and permission of the user of course).
It doesn't need to be silent install or anything.
I have rewritten my answer.
Your mentioned setups requirements seem very common to me for the class of installation programs (setups) and not at all unusual.
Generally you have two options:
You write everything on your own, you create the install dialogs, the way the settings are saved, and so on. Then you are fine with C# (or any other language).
It is quite uncommon to do so, because it is time consuming, and you are reinventing things which have been solved in standard ways several times. Moreover you will fall in common setup error traps which are maybe already captured (or at minimum documented) if using tools.
If you want to use a tool, it is your first decision, if you want a tool based on MSI (Windows Installer) or not. MSI is the most powerful and most industrial-accepted setup technology in Windows, but it is a quite complicated matter, and no tool can shield this 100% from you. Google for WiX (Open Source) or InstallShield as starting points for MSI tools but there are of course more.
Some tools are already integrated or integrateable in Visual Studio for example.
Selfextracting tools are a starting point, but the following tools offer far more and are a good intermediate way between the extreme points SFX and MSI:
InnoSetup
(has also a home here on SO).
Nullsoft Scriptable Install System (NSIS) on SourceForge
One self extracting program in Windows I want to mention, because it is not widely known, that "IEXPRESS.exe" is already included in the OS.
Concerning your special question of navigating through the install wizard:
Every mentioned tool has ways to save install settings and of course is deciding which settings are changeable by the user part of the 1*1 of setup creation. With the tools you can design the install dialogs like you want consisting of the parts you want.
I hope I got your point.
P.S. While most tools have kind of a scripting language or something similar included, you are normally free to extend the installation process with your own actions written in nearly every programming language you like.
Firstly, I saw some topics about these two but weren't my answer.
I'm looking for a good FPC(Free Pascal Compiler) IDE on GNU/Linux.
There are some IDE's like Lazarus and CodeTyphon. I need suggestion to choose one of those.
I've tried Lazarus once but all windows was separated. It looks messy and not interesting.
I would like to know what are the distinguishes between these two ?
I would like to know advantages / disadvantages each of those. Thank you
CodeTyphon is a distro of Lazarus, like Ubuntu and Debian are distros of Linux.
CodeTyphon comes with a large package of components and plugins, that otherwise you would have to google and download and install.
CodeTyphon have their own idea what are stable versions and what are not stable yet for both of FPC (compiler) and Lazarus(IDE). Whether their assessment is better or worse than upstream's Lazarus Team's, I don't know.
What about one-single-window plugin, it is work-in-progress and it doesn't seems to me it is ready for production use, no matter would you get it as part of CT or download and add it to vanilla Lazarus. However maybe it better works on Linux than on Windows, I don't know.
There were however issues with code legality in CT grande bundle. It is widely believed that Orca (if I remember the name) violates copyrights of glScene/vgScene, which also happened in early Delphi FMX releases but was fixed by EMBA later. There also were disputes in FPC forums/wiki about CodeTyphon pirating some open-source components. See answer by Peter Dunne below.
Your question is akin to asking the difference between Linux and Ubuntu. Lazarus is an IDE/component library, based on FreePascal (FPC). And CodeTyphon is a distribution of Lazarus and FPC. So CodeTyphon is just one way to install a functioning installation of Lazarus.
Lazarus uses the same floating window design as older versions of Delphi. Installing from CodeTyphon won't change that.
Myself and several friends highlighted several licensing issues with codetyphon
most of which could have been corrected by sourcing the included files from known good source and ensuring the correct license headers were included
PirateLogic refused to correct the issues which means they are using code in direct violation of the original license terms
The fact its open source code does not change the fact they are pirating the code by not including the correct license even after the issue was highlighted
I also found several instances of copyright code included which appears to be proprietary and not FOSS at all
They also changed the path & file names on some libraries so that source is no longer compatible with standard lazarus/component installs
This in my view is totally illogical
These 2 factors heavily undermine what was potentially the best FPC/Lazarus distro
Hardly professional
Lazarus can be a daunting installation process due to it's nature as a cross compiling environment. You don't just download an installer and click ok. A typical "installation" is actually a bootstrap FPC compiler doing a three-pass compilation of an "install". There are plenty of good installation scripts/methods from the official Lazarus/FPC team and in the community for a . But, understandably, the installation process is a skill in itself.
CodeTyphon is a a different/separate branch of an installer system, which is more of a utility suite/tools/third party code compilation library. If you want the simplest installation experience go with CodeTyphon. It has the nice graphical front end for managing the compiler. You can conveniently do the fancy stuff like build "cross-compilers" for almost every "target" operating system out there. It also is jam packed with hundreds of the best components/libraries pre-installed. It is a very actively maintained project and very professional. A whole lot of work is done for you.
Even if you want to be learn the low level compiler capabilities, CodeTyphon is a good place to start. It is written in FCP/Lazarus and is open source. Simply study it as "working demo app" and the other info on the compiler details. If you crash it, at least you don't have to learn to climb the hill. You get to get to start from the top and lose control on the way down. Start from scratch (and a three hour reinstallation) Hahaha
Lazarus also has a package "AnchorDock" which allows you to dock all the windows into one. Either install the anchor dock design package after installing Lazarus, or install Lazarus using the script at getlazarus.org which will do it for you.
I have written a plugin for an application which has an installer as an executable. My plugin is installed using an msi, written in wix. We've now been given permission to distribute the two together. Ideally, this would be in a single file with two installations. Both parts would need to be updated seperately, particularly the main program, I have read that this restricts the methods of installation.
I'm having trouble installing the main program first, then the plugin. I have tried including this main exe in the wix as a custom action, but I'm worried that this will mess things up when either program needs updating. I have seen something called an MsiEmbeddedChainer but can't seem to find anywhere that describes how to implement it.
Any advice, or pointers of useful articles would be greatly appreciated.
Most of what you need to know is linked from the Not supported in Windows Installer 4.0 document, but it will likely still take a lot of trial and error. This blog post has a lot of interesting points to help with rough patches along the way. However let me warn you that my experience with InstallShield has shown that MsiEmbeddedChainer chaining is not as reliable as bootstrap chaining, at least in environments with Terminal Services.
We have our source code stored in Kiln/Mercurial repositories; we use MSBuild to build our product and we have Unit Tests that utilize MSTest (Visual Studio Unit Tests).
What solutions exist to implement a continuous integration machine (i.e. Build machine).
The requirements for this are:
A build should be kicked of when necessary (i.e. code has changed in the Repositories we care about)
Before the actual build, the latest version of the source code must be acquired from the repository we are building from
The build must build the entire product
The build must build all Unit Tests
The build must execute all unit tests
A summary of success/failure must be sent out after the build has finished; this must include information about the build itself but also about which Unit Tests failed and which ones succeeded.
The summary must contain which changesets were in this build that were not yet in the previous successful (!) build
The system must be configurable so that it can build from multiple branches(/Repositories).
Ideally, this system would run on a single box (our product isn't that big) without any server components.
What solutions are currently available? What are their pros/cons? From the list above, what can be done and what cannot be done?
Thanks
TeamCity, from JetBrains, the makers of ReSharp, will do all of that. You will have to configure it for what specifically it means to "build your product", but you can configure up everything you specified with it.
The software can alert you to failed builds, even down to alerting only the person responsible for checking in code that broke the build. It even comes with handy web pages you can view to see only your own changes, which builds they've been through successfully, which ones are pending, and which ones are currently being executed.
Since it is a distributed product, you can make it grow with your organization and product. If at some point you discover that you're waiting for the build to complete too much, because a lot of builds are being queued up, you can add more build agents. The build agents are basically separate client programs you install on additional machines, that execute the actual build configurations.
It comes in two flavors, the professional version and the enterprise version. The professional version is free, can contain up to 20 build configurations, 20 users, and 3 build agents. The enterprise version has unlimited users and build configurations, and you can also use LDAP based security (think domain verified users.) There's also some other bonuses from the enterprise version. You can also buy licenses for more build agents if you need more than the initial 3.
Now, if "no server components" means you don't want it to act like a web server, you're going to be hard pressed to find something that will react to your commits.
However, if you mean that you don't want to have to install a server OS, then TeamCity can work on workstation versions of Windows as well. That isn't to say that you shouldn't consider setting up a proper server for it, but it will run on a workstation if that is what you require.
Our product BuildMaster does all of the things you listed by design and there is a free, somewhat limited edition (e.g. you can only have a limited number of issue tracking providers integrate with it, the database change script packaging tool isn't included in the free version, etc.) for 5 users or fewer.
What you've described is the basics of a CI Tool, so every CI Tool should be OK.
I use Cruise Control.NET but it is bugged with Mercurial and is not very straightforward at first glance. I am nevertheless happy with it. Other tools that come in my mind are Hudson, Team Build (from TFS) and TeamCity.
I have not tried other tools but you can see pros/cons here :
TeamCity vs CC.net
Hudson vs CC.net, Link 1 and Link 2
CC.net vs TFS
EDIT : I forgot to mention that Hudson and Cruise Control.net are Open Source project, you can easily write plugins and patches to your install.
EDIT² : Mercurial bugs seem to be fixed in the upcoming 1.6 version of ccnet (changes commited to the trunk this week).
There's always BuildBot which I like (and have contributed some code to ). It's fairly easy to set-up and run on any OS, and to do simple tasks like that you say, and remarkably flexible if you need it.
What you might find missing is batteries-included log-scrapers and/or report generators that other more commercial CI-servers comes with, especially for Enterprise-y frameworks.
It scales pretty well too, Mozilla and Chromium use it, amongst others.
I found that Wix v3 uses a tool (heat.exe) to "harvest" information into WiX fragments. Either I am looking in the wrong location, or this is thinly documented.
What is the best way to auto-generate a WiX fragment (likely using heat.exe) for a complex folder structure that contains media files:
Of varying types (ico/png/xaml/etc)
That may change regularly (names/locations/adds/removes)
That are classified as "Content" and included in a .csproj
such that they can be built into an installer via WiX and would withstand upgrades and patches with decorum?
Background Information
I found heat.exe, which seems to solve the autogenerate WiX fragment requirement
In getting the "dir" harvester working, I noticed the "project" harvester (commandline help)
Media is already in C# project file, and so noted that "-pog:Content" might do very well
Cursory search found out of date documentation that didn't mention "project" harvester
Realized entire project installer could probably done with "project" harvester, but was unsure how well this was supported, and what the pitfalls were.
Saw the generation of "PUT-GUID-HERE" and realized that autogeneration of guids would likely have upgrade/patch implications.
Realized that there must be people who use these tools for similar purposes and could probably point me in the right direction.
It was (fairly) pointed out that v3 is not yet "done" (thus the scarceness of documentation and tutorials). The sense that I get now is that it is non-trivial to automate this in my build scripts, and the tools are growing right now to ease this.
In my experience John Robbins' Paraffin solves alot of the issues with tallow.exe (heat.exe in v3). I'm not sure if Paraffin plays nicely with v3, but it might be worth checking out.
FYI, I've used Paraffin in a build process and it allowed me to remove the previous 2-3 step cleanup process that involved a powershell script.
For the upgrade implications of auto-generated setups, read this. The take-home message:
Windows Installer doesn’t let you
remove components in a minor upgrade
It is hard to guarantee that components continue to exist if you generate your setup automatically. Therefore you have to chose between auto-generation of components and the ability to do minor upgrades.
If you have some auto-generated components, then just stick to major upgrades. You can use this sample by Rob as an example.
Thanks for the background, I wasn't aware that they were working on a new version of Wix. According to the project page, it isn't RTM yet, so that may explain the problems you're having. I hope to hear from the WIX developers in one of the replies.
I can't help you use the under-development heat.exe features. However, I have been in your situation and my solution was to create a tool that took directory and file information as input and generated valid wix project files as output. A .vsproj file is just an XML file, and you can use XSL, C#'s LINQ, PowerShell, or a number of other tools to do the work. I personally have used (pre-LINQ) C#/XMLDOM to parse VS project files for this purpose.
Good Luck,
Dave
For documentation, check out the help file that is installed with WiX - WiX.chm provides the most up to date information (along with the command line -help option).