I am required to install firebird super server on windows as a service, as a part of my application installation through wix for windows machines.
The machines might have a another firebird instance, usually default instance running, thus must be installed on a different port. User should not see any dialogues and installation should happen in the background.
I am able to do the installation through instsvc, installing firebird on a different port with a new instance name. However on windows you get the file execution security warning for instsvc execution. Thus I was looking in to http://www.mwasoftware.co.uk/firebird-msm merge modules but, it does not provide me with information on how to install on a different port/service name(if required).
Could you please provide me info on how to install firebird using wix, so that it would install firebird as apart of my wix installation, on a specified port, without obstructing existing installations, and no interaction from the user.
The Firebird installer only installs the service as the default instance with the default port. If you want to run on a different port and use a different servicename, then you need to change the port in firebird.conf yourself, and execute instsvc with an alternative servicename.
What I got from the merge module dev. While I havent tried the solution yet, seems to be straight forward.
The build scripts including WIX scripts are all available for
download. The direct link is:
http://www.mwasoftware.co.uk/download-msm/download/8-current-version/130-msm-build
To install a (possible) second server, you should do two things:
Build use a modified firebird.conf
Change all the UUIDs so that the package is unique.
You will also need to copy the build251.bat script and update the
environment variables to the Firebird version you are using. See also
readme.htm.
Related
Some programs installed by Chocolatey have the feature to self-update. Examples are VS code and PyCharm. Will there be any side effects if one uses choco to upgrade the software after the software has done the self-update?
I am using Windows 10, python 3.8, anaconda distribution.
If by "side effects" you mean try to download when they shouldn't, or download and revert to outdated files that they shouldn't, the answer is no. They don't just retrieve the packages, they manage them.
handling dependencies during installs and upgrades is the main purpose for package mgrs. to exist. They manage stuff like that so developers do not need to. Otherwise, building any type of project with current methods and standards would be extremely challenging so you don't have to.
Chocolatey, like most package mgrs., runs a 2 step process as a result of the upgrade command. First it checks for newer versions, If there are none, it does nothing. The convention for nearly all automatic upgrade processes is the same. Because of this, either one only retrieves when it needs to.
Companies like IntelliJ and Microsoft usually have relatively robust Deployment schemes, regardless of the method. If a package manager was going to break (or breaking) their automatic update, they would either fix the compatability issue or choose to forgoo the install method. So long as you verify your sources before downloading anything from anywhere, you should be ok.
Side Effects
Side effects should not be present, as it depends on whether the application also successfully overwrites the files, which should be the case.
If PyCharm executes the self-update and the Chocolatey package manager updates the PyCharm application at the same time, errors may occur and the files may not be overwritten successfully.
1. Solution — Deactivate Self-Update
You can manually disable the self-update option integrated in the application.
If the application does not allow you to disable the self-update option, try disabling the update service via the Services application.
2. Solution - Deactivate the Update Service via Services
The Services application allows you to make configurations of the services developed by the respective application.
It is strongly recommended that you create a restore point before making any changes to services.
If you make a mistake that cripples your computer, you can use the restore point to perform a system restore and undo the changes.
If you have disabled the wrong service and lost access to the computer, try booting into safe mode to change the service back.
Configure the update service via the Services application and set the status to Disabled.
Example: Deactivating the Brave Update Service
I simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
We have a productive GitLab 6.8.1 running. I've set up a parallel VM with GitLab 7.10.4. Now I want to move all data from the old installation to the new one. I've already found a way how to move the bare repositories, but I have no clue how to import the user account information, issues, etc.
EDIT: The thing is further complicated by the fact that the original installation was built from source, was running on Debian, used MySQL as a database and the whole installation was pretty much messed up. That's why I didn't manage to migrate the old server and decided to set up a new one. The new server is an Ubuntu machine with GitLab installed from apt-get package (I think that's Omnibus, but I'm not sure what this means.) The new installation seems to use PostgreSQL.
FYI You haven't specified whether the old or new server is running a source installation or omnibus, or whether you're running a MySQL or Postgres database. Instructions differ depending on these factors, so please clarify and I will update my answer.
The first thing is that you will need your old and new servers to be on the same version of GitLab. You cannot migrate anything other than repos without having synchronized versions.
Depending on your reply to the above you will either follow instructions similar to the backup and restore tasks or by running the backup and restore tasks. Both options generally require you to manually copy configuration files or migrate settings from multiple files to a single new file (in the case of going from a source install to Omnibus). The Omnibus upgrade guide above lists the configuration files that need to be migrated depending on your environment.
Update based on edited question: There's a guide specifically for that scenario in this section of the Omnibus upgrade guide, using Option 2. You still need to have the same version on both old and new servers, though, I believe.
Problem
I want to both use stable versions of KRE and the bleeding edge nightly built KRE. One ASP.NET5 application may be beta2, but another I may want to be beta4. So what I did was install both in powershell as found here.
What happened is that the stable KVM installed in C:/Users/derp/.kre and the nightly build KVM installed in C:/Users/derp/.k
Worse yet, I can only see this now
Attempts
I tried kvm install KRE-CLR-x86.1.0.0-beta2 and it failed
Shall I try moving the packages from /kre file to the /.k file? This seems hacky and like a really bad idea
RTFM - Tried to use the install feature and including the -a, but failed.
I'm doing something the hard way and can't see the obvious.
I search on here
I feel if there is an answer to what I am trying to do above, it is worth being on here for others to find as well. Thank you all for your patience.
ASP.NET 5 is under development and there is no guarantee that changes between different pre-release version are backward compatible (sorry!).
The /.kre -> ./k rename is not backward compatible and you cannot have both the old and the new kvm simultaneously on the PATH. However, you can get can have two versions of kvm on your machine but you will have to use the full path for at least one of them.
I think the key is the path environment variable of your system. You have to use two set of "kvm", one for night builds, one for public beta, to download and set correct path environment variable.
For instance, I get one kvm from Entity Framework 7 repository, which can download and use beta 4 builds. I also have another kvm from Home repository which can download and use public beta builds.
You can use either kvm with "upgrade" or "use" command to set correct path environment variable, then run your application on the runtime you need. I think even Visual Studio 2015 CTP runs your projects based on the Runtime specified in your path environment variable. For the time being, only beta 3 run times can display in the project property dialog of VS 2015 CTP, but when hitting ctrl + F5, my website starts to load beta 4 runtime and assemblies, I can see the loading in output window, I think this is because I have .k folder prior to the .kre folder in the path environment variable.
Can you try the following?
$cmd-prompt>kpm Install KRE-CLR-x86
It worked for me.
I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.
In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.
I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.