I am working on a project where most of the work is done in Visual Studio 2012, implicitly using MSBuild. However I have to integrate a few unixy tools, and I even have a few bash scripts. This is possible, because we are already using msysgit; the tools and scripts work just fine
if you invoke them from the git-bash shell. But I want to run some of them from MSBuild as pre/post build actions.
The problem is how does MSBuild find bash? We assume it exists, but developers simply install it on their PC's in different locations, and will rarely add it to their %PATH%. I want a solution that involves a minimum of per-PC configuration. Ideally none at all.
I think the easiest way is to define a sensible default for your MsBuild solution and let it be overriden by developers on an as needed basis. Asking for bash or git to be on %PATH% is a reasonable default hence you could describe it as such
<PropertyGroup>
<BashCommand Condition="'$(BashCommand)' == ''">bash</BashCommand>
</PropertyGroup>
This way any developer who wanted to override the setting could do so by defining the value before importing the core MsBuild files
On the assumption that you are talking about the user installation (which we typically call Git for Windows) -- as opposed to the developer installation allowing you to develop Git for Windows itself (which we actually call msysGit) -- then you should be able to simply assume that Git is installed either in %ProgramFiles% or in %ProgramFiles(x86)%. You could even add a third option, say, %GitForWindows% which the users could set if they installed it elsewhere.
If that is not good enough, I am certain that the InnoSetup installer (or Windows' Installed Software management) leaves some trace in the registry, although that might be a little fragile: you would depend on that registry key not changing, ever.
Related
I want to append the installation folder of my program as value to the path variable of user and system variables.
I followed michaelmoo's instruction.
https://stackoverflow.com/a/21390793/9678802
The problem is that the existing value of path variable will be removed.
Digression: Adding to the Path involves some security risks, some performance issues, and can cause application interference - and probably a few other things. It is best avoided in general. It is a "known risk" avoided by deployment professionals - if they can help it.
The concept of AppPaths is a (partial) alternative to
updating the Path environment variable. It allows your application to
be started from the Start => Run dialog, but it does not work
from the command line.
Seems to not work from command prompts.
Warning: Ouch, that answer is very bad indeed (with apologies to the author who clearly tried to help others). That procedure should not be followed in any shape or form though! It is so dangerous that I have seen people sent out the door for far less. Wiping out a whole developer teams' environment path with a package deployment will cause drama - that you can be sure of. The warning really needs to be that strong in this case. I have seen it happen, and even by packages made by experienced professionals.
Built-In Support: As far as I am concerned, the correct answer from the above "thread" is this one. Windows Installer has built-in support for adding environment variable that takes care of all merging and update issues - and it even has rollback support - meaning your environment variable will be restored to its original state should the package installation fail. This built-in feature is a "must use" functionality.
Deployment Tool: So the built-in feature has to be used, but how when the tool does not support it? The best option is to get a "real deployment tool", especially since there are several further problems with the Visual Studio Installer Projects (Note: this is not pitching products, it is telling people about serious pitfalls that will cause real problems in almost all cases - what product you choose is up to you - obviously - but the VS Installer Project just isn't a complete solution).
WiX: Updating the Path variable using WiX is simple enough. And the documentation for the Environment element.
Orca: Though it is possible to "post-process" your compiled MSI and create the required entry in the Environment table, I would recommend that you use a proper tool instead that has been tested and designed to help you succeed in general. A comma wrong or a star wrong in the Environment table and you get completely wrong behavior.
Over the years our InstallShield code has grown un-manageable and messy. We're about to design an InstallShield 2015 installation from scratch for a new major release, and I was wondering if there's any way to automatically capture a set of system changes to use as a cleaner starting point for developing a new install package. Ideally, I would like to turn on some capturing software, install the oldest release from which we support an upgrade, install the latest service packs, and then apply the manual changes that will get the new release running on the system. Then I would turn off the capturing software, and it would provide an InstallShield project pre-loaded with all the files and registry entries (GAC changes, .NET assemblies, etc) that were created as part of that install. Then I could add steps to delete those that we no longer needed and do some other clean-up and refinements. Does such a thing exist?
Yes, this is called a repackager most often, in the enterprise world where sys admin and packagers prepare applications for deployment on the company machines.
Flexera has one that can create a project for InstallShield, but it is sold together with their AdminStudio solution, which is not cheap.
We (at Caphyon) have a repackager included in Advanced Installer (the architect edition) which also requires you purchase license. And of course the generated project will be compatible only with Advanced Installer, where you can configure your installers as you wish.
I think there is also a free repackager, AppDeploy from Dell, but I never used it, so I don't know how accurate it is and if you can use the results created into InstallShield or if it generates directly an MSI.
If you started looking more careful you will probably find other repackager tools, but you should know that building such a tool is not an easy task so choose carefully. Also probably only the one from AdminStudio will be able to generate a project that can be read by InstallShield.
If you already have the source projects from the older editions I would personally not try using a repackager. Instead I would go for cleaning up all the configurations which you do not understand and re-build them from scratch.
A repackager as good as it can be still has some problems. It can capture incomplete data, for example if you have a custom action that runs different code based on the OS where the installer is running the repackager will capture only its effects on the OS where you run it. On another one might run differently and have another output.
Also if your installer has prerequisites and you run the repackager on a machine where those prerequisites are installed then the repackager will not capture anything related to this, so by accident you can forget to include required prerequisites in the new package.
There is also the things like meta-information which few repackagers can detect. For example files associations which are actually a set of file and registry entries connected together or environment variables, scheduled tasks, etc...
Most repackagers capture all this data and simply show it to you as configuration files and registry entries, instead of creating the correct entities in your projects, i.e. files associations, environment variables or scheduled tasks in their correspondent views.
I have a 32-bit legacy application that allows users to specify the install path as part of the setup (pretty normal stuff...). I also have a custom action defined that runs a silent background install of another required bit of software after the initial installation is complete.
All is well when users install to the 32-bit Program Files (x86) directory.
Where I am running into problems is when users specify the 64-bit installation directory, Windows automagically changes the install path in the background to use the (x86) Program Files folder, which is fine, except that my custom actions that use the same INSTALLDIR property after the initial install is finished still think that it should be the 64-bit "Program Files" path - so the install fails when the custom action can't find the EXE file it's looking for.
My program is essentially exactly the same as the one described here by another developer but never resolved in that forum: http://community.flexerasoftware.com/archive/index.php?t-216268.html
Does anyone have a clue what a valid workaround for this is? It seems pretty basic that an installer should not fail just because users think they should install to "C:\Program Files\Appname" instead of "C:\Program Files (x86)\AppName".
I did peruse the similar questions on here but I don't see anyone else with this issue using custom actions.
In my experience you need to change to a 64 bit template to install to program files. General information in the tree > Template summary > change to x64;1033. At least one file needs to be marked as 64 bit in each directory. It is a check box on the component property. Be sure to check your custom actions still obey run conditions on major upgrades. I am having issues with that currently. Major upgrades on mine is set to remove all and it runs all custom actions no matter the conditions on the removal portion of the script.
The problem with renaming files is that if you want to take advantage of Visual Studio refactoring, you really need to do it from inside Visual Studio.
But most (not all*) version control system also want to be the ones doing the renaming.
One solution is to use integrated source control, but this is not always available, and in some cases is pretty clunky.
I'd personally be more comfortable using source control separately, outside of Visual Studio, but I'm not sure how to manage this question of file renames.
So, for those of you that use Visual Studio, which source control do you use? Do you use a VS integration (which one?) and otherwise, how do you resolve this renaming problem?
(* git is smart enough to work it out for itself)
I use SVN (TortiseSVN as the client) and use the Repair Move command from the commit dialog heavily. This allows me to rename the files within VS and resolve the rename when I'm ready to commit to keep version history.
As far as using the VS integration, like you, I find all VS integration clunky and do not use it.
mercurial usually prefers to do the renaming via hg rename however it can also detect renames from an outside source by using hg addremove -s 100 (or less than 100 if you want to match a rename with alterations) so clearly you can let VS do the rename and get mercurial to catchup with addremove.
We use SVN (TortoiseSVN to be exact), and i am always bothered with the renaming problem. The simplest solution i've found is to remove the files from the project, rename them via TSVN and add them back to the project. You have to manually update includes for renamed header files, but this is relatively easy using find&replace.
We use Team Foundation Server, and it works with no problems. I've also found that moving to using a fully integrated client has improved my workflow, as I don't need to flip between applications just to do trivial tasks.
We develop "Plastic SCM" and the Visual Studio Package supports move operations. But I see your point, I'm getting more and more comfortable with the idea of not having plugins/packages and then have the version control working behind the scenes and simply detecting what happened without having to be "plugged in" into the IDE. In fact we're working on it for next release...
Besides the above advice, for Visual Studio 2008 I found that after making all global changes to any file being renamed from within VS, including right clicking the file and renaming it, as well as a global search and replace for all strings, replacing the old file name with the new file name, you must, if the file is the initial startup file, right click and select it as "set as default page". Otherwise you'll may well get the "The resource cannot be found." error on runtime.
What's the best way to use Bazaar (bzr) as the version control system in Visual Studio 2008?
The best I found is TortoiseBZR and the command-line - nothing integrated with VS.
I wouldn't even bother with TortoiseBZR; bzr is very easy to use from the command line.
BTW: The last time I tried it, TortoiseBZR used to lock up windows explorer while it went off to a remote repository to determine the status of files, not sure if it still does this ... ? See also this SO question.
There is no native integration to Visual Studio, but there is good GUI application, called Bazaar Explorer. It's the part of official standalone installer, and also can be installed separately as bzr plugin.
Old, I know, but since this shows up on the top for Google search, the best way to integrate is a combination of Visual Studio's External Tools, and tbzrcommand.exe and bzr.exe. You can set up things like Status to go to the output window, and things like Diff to go to the tbzrcommand GUI window.
(I'm assuming you've installed TortoiseBzr here.) Using these as examples, in VS open Tools->External Tools, then Add. For the program, browse to the Bazaar directory and select bzr.exe. Name the command Status. For arguments, type "status" (sans quotes). Select that the output should be directed to the vs output window, that the command should be terminated when complete. Open a simple file under code control and add a space somewhere and save, then under external tools, choose status to verify that it shows up as a pending commit action. (You can add these to their own menu later, once they work.)
Next, add another external command and name this Diff. For the program, browse to the Bazaar directory, and choose tbzrcommand.exe. For arguments, type "--command=diff --file=$(TargetPath)" (sans quotes). Leave the options all unchecked. Then, for the file above that you added a space, select it in the solution explorer window and choose Tools->Diff. A TortoiseBzr window should appear (along with an annoying DOS window), and show differences between the working version and the latest commit version of the file.
For something like a commit, which requires a comment, you'll have to put in arguments like "commit -m " (sans quotes) and check the box to prompt for arguments (to allow the entry of a message for the commit).
There's a project in Launchpad, but it looks like it's abandoned, and when I downloaded it, I couldn't get it to build.
This is something I'm interested in myself. Tracking adds, drops and renames automatically in an IDE is the way to go. Seeing status is nice too.
If you don't need the SCC integration, just the ability to use the tool, try the setup in this article:
http://www.codeproject.com/KB/macros/Bazaar4VS.aspx
I've ported VisualHG to work with Bazaar:
https://launchpad.net/visualbzr
It's currently an alpha version, and has only been built and tested for Visual Studio 2010, but common operations should work OK.
Edit:
This plugin hasn't moved on much, but it does now support Visual Studio 2012.
Unified SCC has support for bzr. It is commercial but claims to be free for OSS projects.
UnifiedSCC
I too was trying to use this, and found that visual studio has an option of "External Tools", which can be found under the tools tool bar. Upon trial, I found that one could create a link to the bzr.exe (or any other exe tools you may want to use). Then, it asks for arguements. It is here where you can begin to use magic.
For me, to commit changes directly, I have created an arguement of commit -m "", which commits without message to the bzr branch if one exists in the working directory (to achieve this, you also have to change the starting directory to solution directory).
I also created a push command to my launchpad using similar idealogy