We have a very old applications setup launcher developed with Installshield's DemoShield software. We are now looking to replace this with something better.
Although, we are already using Wix Burn with Custom Bootstrapper written in C# and planning to use this technology to build a custom launcher.
Alternatively, we can use C# to build a simple application which would do the same job. But still looking for better and some ready made template based solution.
Are there any open source solutions to this? Any open source code/script based solution would also do the job.
Related
I currently have a custom XAML build workflow which performs a lot of validations based on code structure, folders, file content and even database configuration.
Currently we need to consider to migrate it to TFS 2017, and I'm trying to understand the possibilities, effort and pitfalls and this is where I could use your help.
I have logic built in C# and then I look at MSDN documentation the language seems to be Javascript, GitHub samples seem to be Typescript. Am I forced to use one of this languages? any preferred one or limitations that I should be aware of? Can for instance, I connect to a database directly? or it's better to have an API and just use REST calls?
Can I for instance, use .Net object which have already some wrapped logic?
I also noticed that on the manifest file I can declare inputs, but can I somehow use outputs? For example, I have a task that does validation and in the end I would have a task to send an e-mail with the result of that validation. Is this possible?
Thank you in advance.
You are right in concluding that XAML builds are deprecated. The new Task based system is much more flexible and now that we even have YAML support, you can move to Builds as Code.
The reason you're seeing Build Tasks in TypeScript (which is a superset of JavaScript) because of the cross platform nature of NodeJS. This allows your tasks to run on Windows, Linux and Mac. In the mean time we also got .NET Core support. You can also use PowerShell if that's more of your liking.
Regarding your 'can I connect to a database' question. Yes you can, if you want it is another question. This will massively slow your build down and will make your build fail if there are issues with database connectivity. I would suggest asking a second question here on Stackoverflow to describe your situation and discuss if there is a better alternative.
You can use output variables from your task and reuse these in the next tasks. That's all supported and no problem (see https://roadtoalm.com/2016/08/11/set-output-variable-in-a-powershell-vsts-build-task/ for an example).
There are too many questions here and they are broad.
Whatever, XAML Build are deprecated in TFS 2017 and will not be available in the next version of TFS. VSTS already no longer supports them. So you need to Migrate from XAML builds to new builds (vNext builds). Also this similar thread for your reference : Converting TFS XAML Build Custom Activities into TFS 2015 Build Tasks
Marketplace
While you can make use of custom build tasks with XAML build there is
no centralized or integrated solution for browsing available tasks,
installing them or managing them. With the new builds you can make use
of the quickly-growing Visual Studio Team Services Marketplace. Here,
you can search and browse the many extensions currently available in
the Marketplace.
See WHY SHOULD I LEAVE XAML BUILDS for details.
So, you can find the existing extensions in Marketplace and install them to extend the build process (add correspinding tasks). You can also custom your own extension based on your specific requirements. See Extensions overview.
You can build custom applications or services that integrate with your
Visual Studio Team Services (VSTS) and Team Foundation Server (TFS)
accounts by using the REST APIs to make direct HTTP calls, or
utilize our .NET Client Libraries.
Source here : Integrating with VSTS and Team Foundation Server
To add a custom task you can reference below articles:
Add a build task
Reference for creating custom build tasks within extensions
Developing a Custom Build vNext Task
For the "outputs" validation, you can try it with build alerts.
I want to make a MSI installation using WiX and EmbeddedGUI. I really want to make it highly modular - ie the main MSI will contain only the basic files (the required ones), and all other features will be split into separate MSI files, which will be downloaded from internet if not present on hard drive and installed only if selected in my EmbeddedGUI.
But I am totally new to WiX, and I can't find a way to actually how to make that modules? MS Office and MS Visual Studio seems to be using this scheme, by using the modules which it downloads over internet and installs them in case of need - something like this:
It seems that Fragments is mostly like "static libraries", not "dynamic libraries" which would be more useful in such a situation. There is also the Chaining mechanism, but I'm not sure I will be able to bundle the features as the same application (only one entry in "Install/Delete" window) because it seems to be calling external MSIs completely separately (more like invoking "separate exes" instead of loading "dynamic libraries").
So, what is the way to go for making a highly modular setup package with WiX?
Use a bundle (chain). The Burn engine, which manages bundles, will show only the bundle in Add/Remove Programs and can download any packages that aren't already present -- for example, using the MsiPackage/#DownloadURL attribute.
I am using WiX for make installer for any product. But I don't want to use default UI dialog which is using in WiX. How to improvise UI of a installer ? Is there any tool for designing UI for a installer with highly customize ?
Rich GUI is done in bootstrapper (aka. chainer). Chainers are made in tool called Burn (B is for bootstrap). I'm not all that familiar with it, but it was supposed to replace all the GUI available by Windows Installer that you can set in .msi files. This GUI is restrictive, and suitable only for simplest tasks, so the idea is to build .msi only as a database file that is to be consumed by Windows Installer to actually install something, and transfer all the GUI to bootstrapper.
The only thing I've come across is WixEdit, although it seems buggy and may have been abandoned. Still, it allows you to do basic UI design of the WiX dialogs.
I recently came across something called Wix#. It lets you make custom dialogs using a Winforms-like designer.
I know it's 9 years later, but if it helps, great.
I am creating a windows application setup project using Visual studio 2008 setup project. This setup will have following steps:
Splash screen
Select Installation folder/directory
Database configuration
Select Components
I am having trouble finding a way to create such installation window in setup. could you please help me to find a solution for this?
Visual Studio's routine for creating install/setup files is fairly weak compared to what you can find out there. Personally, I use a program called Inno Setup. It's an extremely powerful scripting program that allows you to completely customize the installation process. You may have to spend a little bit of time learning the basics of the scripting language it uses but will be well worth whatever time you may spend understanding the language to use the setup utility to create complete installation files for your current and future programs.
Generally when I use ClickOnce when I build a VB.NET program but it has a few downsides. I've never really used anything else, so I'm not sure
what my options are.
Downsides to ClickOnce:
Consists of multiple files - Seems easier to distribute one file than manageing a bunch of file and the downloader to download those files.
You have to build it again for CD installations (for when the end user dosn't have internet)
Program does not end up in Program Files - It ends up hidden away in some application catch folder, making it much harder to shortcut to.
Pros to ClickOnce:
It works. Magically. And it's built
into VisualStudio 2008 express.
Makes it easy to upgrade the
application.
Does Windows Installer do these things as well? I know it dosen't have any of the ClickOnce cons, but It would be nice to know if it also has the ClickOnce pros.
Update:
I ended up using Wix 2 (Wix 3 was available but at the time I did the project, no one had a competent tutorial). It was nice because it supported the three things I (eventually) needed. An optional start-up-with-windows shortcut, a start-up-when-the-installer-is-done option, and three paragraphs of text that my boss thinks will keep uses from clicking the wrong option.
Have you seen WiX yet?
http://wix.sourceforge.net/
It builds windows installers using an XML file and has additional libraries to use if you want to fancify your installers and the like. I'll admit the learning curve for me was medium-high in getting things started, but afterwards I was able to build a second installer without any hassles.
It will handle updates and other items if you so desire, and you can apply folder permissions and the like to the installers. It also gives you greater control on where exactly you want to install files and is compatible with all the standardized Windows folder conventions, so you can specify "PROGRAM_DATA" or something to that effect and the installer knows to put it in C:\Documents and Settings\All Users\Application Data or C:\ProgramData depending on if you're running XP or Vista.
The rumor is that Office 2007 and Visual Studio 2008 used WiX to create their installer, but I haven't been able to verify that anywhere. I do believe is is developed by some Microsoft folks on the inside.
I agree with Joseph, my experience with ClickOnce is its great for the vast majority of projects especially in a corporate environment where it makes build, publish and deployment easy. Implementing the "forced upgrade" to ensure users have the latest version when running is so much easier in ClickOnce, and a main reason for my usage of it.
Issues with ClickOnce: In a corporate environment it has issues with proxy servers and the workarounds are less than ideal. I've had to deploy a few apps in those cases from UNC paths...but you can't do that all the time. Its "sandbox" is great, until you want to find the executable or create a desktop shortcut.
Have not deployed out of 2008 yet so not sure if those issues still exist.
Creating an installer project, with a dependency on your EXE (which in turn depends on whatever it needs) is a fairly straightforward process - but you'll need at least VS Standard Edition for that.
Inside the installer project, you can create custom tasks and dialog steps that allow you to do anything you code up.
What's missing is the auto-upgrade and version-checking magic you get with ClickOnce. You can still build it in, it's just not automatic.
I don't believe there is any easy way to make a Windows Installer project have the ease or upgradability of ClickOnce. I use ClickOnce for all the internal .NET apps I develop (with the exception of Console Apps). I find that in an enterprise environment, the ease of deployment outweighs the lack of flexibility.
ClickOnce can be problematic if you have 3rd party components that need to be installed along with your product. You can skirt this to some extent by creating installers for the components however with ClickOnce deployment you have to create the logic to update said component installers.
I've in a previous life used Wise For Windows Installer to create installation packages. While creating upgrades with it were not automatic like ClickOnce is, they were more precise and less headache filled when it came to other components that needed to be registered/added.