Thanks for doing this. Here are my observations of the process.

Windows 10 Pro, version 1903, OS Build 18362.476

Note: I have an existing berrybrew installation, and this seems not to be expected by the installer.

========

Symantex Download Insight ate the file. After extraction from quarantine it ran.

I saw one cmd window flash past.

The second window ran the strawberry perl download. (This takes a little while, so a download progress indicator or spinner would be nice).

Once that completed a few more cmd windows flashed past.

On opening a clean cmd window I ran echo %PATH%. The strawberry perl instance is in the path at the front, but the newly installed berrybrew is not.

berrybrew version
1.22

"c:\Program Files (x86)\berrybrew\bin\berrybrew.exe" version
1.27
[download]

So it seems to have done everything except put berrybrew itself in the path. Note that I have not tried rebooting to see if it gets picked up that way.

On uninstall it removes the c:\program files(x86)\berrybrew folder. The strawberry perl it installed is still there. It has, however, removed my pre-existing berrybrew from the path.

Thank you for this.

I should have made note about previous installs.

A side effect I didn't consider is that internally, I call berrybrew unconfig but not using the full path, so it likely used the existing 1.22 berrybrew, which would have blown away the original PATH. Probably that's the reason the new path wasn't added as well.

Was there any indication as to why the malware software caught it? I don't use Windows except for developing berrybrew and testing things for a few Windows-based clients I have.

If your 1.22 version was using C:\berrybrew as its Perl instance directory, re-adding that version to PATH should fix things right up. If you want to carry on with the new version, it will happily use your old instances, or the new 5.30.0 instance you installed as part of the test (using berrybrew switch $version). The new 1.27 is backwards compatible with 1.22. It just has many new features and error checking.

I'm still working out kinks. This is my first time creating a Windows installer :)

Again, thanks. Very helpful feedback.

The AV issues are mostly time related. Once a few users have reported the exe it should be sorted.

Some key details from the log:

There is not enough information about this file to recommend it.
This file has been seen by no Symantec users.
Symantec has known about this file approximately 2 days.
[download]

I re-added the older berrybrew to the path and it worked again so that part is corrected.

I then ran berrybrew upgrade, and now I get this error. I had to revert the changes to the perls.json file in the git repo for it to work (this is not new). I don't imagine this is due to the installer, and is more likely something else in the development process, or how I have things set up.

berrybrew version

Unhandled Exception: System.ArgumentException: Item has already been a
+dded. Key in dictionary: '5.26.2_64_PDL'  Key being added: '5.26.2_64
+_PDL'
   at System.Collections.Hashtable.Insert(Object key, Object nvalue, B
+oolean add)
   at System.Collections.Specialized.OrderedDictionary.Add(Object key,
+ Object value)
   at BerryBrew.Berrybrew.PerlGenerateObjects(Boolean importIntoObject
+)
   at berrybrew.Bbconsole.Main(String[] args)
[download]

UPDATE:

I ran a git pull on the repo and the issue has now gone away. The issue was perhaps something to do with berrybrew upgrade and git.

I installed berrybrew 1.22 on a vanilla win10 VM, installed and switched to Perl 5.10.1_32, then ran the new installer.

I have made some changes to the installer after the OP (you can get it here.

Here's the result of those actions:

C:\Program Files\Mono>echo %path%

C:\Program Files\Mono\bin\;C:\berrybrew\5.30.0_64\c\bin;C:\berrybrew\5
+.30.0_64\perl\bin;C:\berrybrew\5.30.0_64\perl\site\bin;C:\Windows\sys
+tem32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\Windows
+PowerShell\v1.0\;C:\Program Files\Git\cmd;c:\Users\admin\Downloads\be
+rrybrew\berrybrew-1.22\bin;C:\Program Files (x86)\berrybrew\bin
[download]

So the new path gets installed *after* the old one. I will add some checks and throw a warning window to state that the old berrybrew will be disabled if they proceed, and I'll write a routine to automatically register any custom or virtual perls they may have had installed in the old version. If the user decides not to proceed, I'll just abort the setup.

Since all my active machines already have berrybrew installed in my unique manner, and I didn't want to mess up the workflow on those, I created a new Win10 virtual machine (1809, 17763.379), and tried downloading your link. The first few times, MS Edge / Windows Defender flagged the installer as containing a virus; I installed chrome so I could download, and successfully installed it; when I tried to re-download with Edge again, or scan the berrybrewInstaller.exe with Defender, it didn't flag it as a virus this time. (So sorry, I don't have a record of which virus it thought it was.) Even after I reverted to my pre-installation snapshot, it wouldn't flag as a virus again; so sorry, I cannot tell you what virus it thought it was.

As far as the actual process went: when I first ran berrybrewInstaller.exe, UAC asked to make changes, but other than that, it worked as you described. The uinst.exe did what you expected, as did re-installing. If i tried running berrybrewInstaller.exe after berrybrew was already installed, it asks if I want to try to disable it (I assume that's the new fix for 1.28 vs 1.27 that you made in response to swl's input). If I say no, it aborts; if I say yes, it moves forward, warns me about off/config/switch, then installs overtop the old (since it was in the same location). Looks reasonable to me.

Thanks a lot for your feedback pryrt.

My next round of updates will include much better upgrade management, including the merging of existing configuration and data file information into the new files to be installed (if any information has changed between versions, which I've come to find is very rare).

hello stevieb

Before I run an installer can I examine if there would be any incompatibility issues against existing installations?

I have already downloaded an extended version of Padre which has magically installed both Strawberry and DWIM perl. I would hope that everything will play nicely after installing a versioning library.

Compiling and running Perl versions is a new discipline for me, and I'd like to help, to also advance my knowledge in these areas. Any guidance appreciated.

Installing berrybrew will have no impact at all on the installation of any existing software (including Perl installations).

It manages instances of its own portable Strawberry Perls, each which are fully contained within their own directories, and are stored and operated out of a location far away from any other software.

If you install and switch to a new Perl using berrybrew switch, then the Perl you've switched to will become the one in use on the system via the PATH environment variable, but you can disable it very quickly with the berrybrew off command to go back to using your previously installed (aka "system") version.

Recently, I added the berrybrew virtual command, so that berrybrew can allow you to add your existing Perls to berrybrew so you can use its switch and use commands with them directly as well (again though, it does NOT touch those installations; it essentially just updates a JSON file with the path information of it).

I've been working very hard on the next version which will have an even more robust installer system than I have now, and it'll also include a Windows System Tray icon allowing one to switch between Perls within the UI, and eventually provide UI widgets for most of the berrybrew operations, and the ability at install time to choose where you want the Perl installation root directory be placed (currently it defaults to C:\berrybrew with an obscure way to change it if wanted).

One more significant addition to my last version is the introduction of the berrybrew-refresh command. Run it after you've used berrybrew switch to switch to a different version, which keeps you from having to close the existing CMD window and open a new one.

Version 1.30 will be released just before Christmas as a Happy Holidays gift to all of the Windows Perl developers out there (interestingly enough, I'm not one of them... I develop the software in a language I have no other use for, for users on a platform I don't even work on myself) :)