Should we expose the ability to make an installation call to the Web Platform Installer?

https://github.com/chocolatey/chocolatey/wiki/CommandsWebPI

They should probably all be the same on the 0.0.0 level.

Because otherwise nothing gets logged.

Just to let you folks know, the Chocolatey GUI is not very accessible for those using screen readers; we are not able to navigate it via the keyboard, nor is any part of the interface spoken.
[...]
This is exactly what needs to be done; describe all user controls!

An introduction into this topic can be found here:

• http://msdn.microsoft.com/en-us/library/aa350483.aspx
• http://msdn.microsoft.com/en-us/library/cb35a5fw.aspx

I'm very new to chocolatey
I've installed chocolatey (command line) and installed ChocolateyGUI. The installation seems okay, but when I start the ChocolateyGUI.exe the process is started (I see it in the Windows taskmanager), but then closes after a short time without any notice or ever showing a GUI window).
What could be the issue?
is there some logfiles, I could check (didn't find any in C:\Program Files (x86)\ChocolateyGUI)?

I am running Windows 7 Ultimate 64-bit

Does it make sense to expose this as another service?

https://github.com/chocolatey/chocolatey/wiki/CommandsPython

Probably in the settings. Sources like Myget, nuget and chocolatey.org.

When using the Build Services from MyGet, you see the following in the log file:

"D:\temp\tmp2F81\Setup_ChocolateyGUI\Setup_ChocolateyGUI.wixproj(43,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\Wix.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk."

This would suggest that Wix is being referenced from the default installation location, rather than in Source Control.

Suggest that this is updated to change the Import Statement to the Source Control location.

Gary

C:\> chocolatey uninstall chocolateygui

gives

=====================================================
Chocolatey (0.9.8.19) is uninstalling chocolateygui from "C:\Chocolatey\lib".
=====================================================
You have the latest version of chocolateygui (0.0.5) based on: '-Source 
"http://chocolatey.org/api/v2/" -Source "https://go.microsoft.com/fwlink/
 ?LinkID=230477"' (if value is empty, using sources in nuget.config file).
 -------------------------
  PowerShell uninstall (chocolateyuninstall.ps1)
 -------------------------
This package has a chocolateyInstall.ps1 without a chocolateyUninstall.ps1.
You will need to manually reverse whatever steps the installer did. Please
ask the package maker to include a chocolateyUninstall.ps1 in the file to
really remove the package.

Again in the build log from MyGet Build Services, the following error is generated:

"CSC : warning CS1607: Assembly generation -- The version '0.0.6.*' specified for the 'file version' is not in the normal 'major.minor.build.revision' format [D:\temp\tmp2F81\Chocolatey Explorer\Chocolatey.Explorer.csproj]"

Does it make sense to adhere to a full Semantic Version number strategy?

Gary

this is the -pre switch.

Make it possible for the user to install multiple packages at once. Let them select and then click install selected or something.

Greetings! I decided to give this a go, and it immediately crashed on me :-( Call stack below - looks like a hard coded path :-)

System.IO.DirectoryNotFoundException was unhandled
HResult=-2147024893
Message=Could not find a part of the path 'c:\nuget\lib'.
Source=mscorlib
StackTrace:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator1.CommonInit() at System.IO.FileSystemEnumerableIterator1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost)
at System.IO.Directory.GetDirectories(String path)
at Chocolatey.Explorer.Services.PackagesService.ListOfInstalledPackagsThread()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

TSIA.

If even possible. Because it will only get slower to load that list.

In installedPackagesService and AvailablePackagesService.

This is going to take awhile.

Even fullscreen, the text width is severely constrained - also the tooltip shows that its width seems to be too low as well.

http://i.imgur.com/87SZ5Qt.png

Loaded the application (in debug) with no saved settings. Went to menu and configured my settings folder. Clicked the "Installed Applications" tab and the load bar start going at bottom. Received an IndexOutOfRangeException:

System.IndexOutOfRangeException was unhandled
  HResult=-2146233080
  Message=Index was outside the bounds of the array.
  Source=ChocolateyGUI
  StackTrace:
       at Chocolatey.Explorer.Services.ChocolateyLibDirHelper.VersionChangeFinished(String version) in c:\Users\Tarwn\Documents\Visual Studio 2010\Projects\chocolatey-Explorer\Chocolatey Explorer\Services\ChocolateyLibDirHelper.cs:line 63
       at Chocolatey.Explorer.Services.ChocolateyService.InvokeOutputChanged(String output) in c:\Users\Tarwn\Documents\Visual Studio 2010\Projects\chocolatey-Explorer\Chocolatey Explorer\Services\ChocolateyService\ChocolateyService.cs:line 53
       at Chocolatey.Explorer.Services.ChocolateyService.OutPutChangedHandler(String output) in c:\Users\Tarwn\Documents\Visual Studio 2010\Projects\chocolatey-Explorer\Chocolatey Explorer\Services\ChocolateyService\ChocolateyService.cs:line 58
       at Chocolatey.Explorer.Powershell.RunSync.Run(String command) in c:\Users\Tarwn\Documents\Visual Studio 2010\Projects\chocolatey-Explorer\Chocolatey Explorer\Powershell\RunSync.cs:line 20
       at Chocolatey.Explorer.Services.ChocolateyService.Help() in c:\Users\Tarwn\Documents\Visual Studio 2010\Projects\chocolatey-Explorer\Chocolatey Explorer\Services\ChocolateyService\ChocolateyService.cs:line 41
       at Chocolatey.Explorer.Services.ChocolateyLibDirHelper.ReloadFromDir() in c:\Users\Tarwn\Documents\Visual Studio 2010\Projects\chocolatey-Explorer\Chocolatey Explorer\Services\ChocolateyLibDirHelper.cs:line 53
       at Chocolatey.Explorer.Services.ODataPackagesService.ListOfInstalledPackagsThread() in c:\Users\Tarwn\Documents\Visual Studio 2010\Projects\chocolatey-Explorer\Chocolatey Explorer\Services\PackagesService\ODataPackagesService.cs:line 119
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

Have it build on commit and run unit tests and at a later stage have it make the chocolatey package and push it to chocolatey.org.

Use the odata feed to have a better search. search in tags, description and title,

Rather than checking in the packages folder to Source Control, does it make sense to Enable Nuget Package Restore?

Looks like there is a new version of this nuget package, so I would suggest that we go ahead and get this updated, assuming that there aren't any breaking changes.

Hi,
It's nice to see you've started to work on chocolatey-Explorer again!

I think a filter box for the package views (both of them) would be handy. User writes a string and only packages contain that string in their name shows up.

Thanks!

Looks like there is a new version of StructureMap ready to get installed, I would suggest that we go ahead and get this updated, assuming it doesn't have any breaking changes.

Improve the filename to package name parsing to satisfy the tests @chrissie1 added in a27b035.

See notes for #34

Just ran the Unit Tests, and looks like there are 8 failing tests. We should probably get these passing :-)

Changing the folder doesn't seem to take effect without restarting the application. Or I'm doing something wrong, also possible :)

Does it make sense to expose this as another service?

https://github.com/chocolatey/chocolatey/wiki/CommandsCygwin

Kick out structuremap and use tinyIoC.

Apparently you can install windowsfeatures with chocolatey too.

chocolatey-archive/chocolatey#150

We now cache all the things but the user should be able to empty that cache to get new data. Cache is renewed automatically every 60 minutes for the list and every 30 minutes for the packages.

Does it make sense to expose UI components to make calls to the Chocolatey Helper Methods?

Such as PinnedItems, DesktopShortCut, etc?

https://github.com/chocolatey/chocolatey/wiki/HelpersReference

And make it have a dependency on PackageVersionService and handle the event in there.

Does it make sense to expose this as another service?

https://github.com/chocolatey/chocolatey/wiki/CommandsGem

It would be nice to provide an option to update all installed packages at once. As a first step binding the chocolatey 'cup all' command to a menu item would be sufficient. Later on there could be a list of packages that need updates to choose from.

This means you can do the update even when there i no new version. More or less a reinstall. cup packagename -force.

Kick out log4net and use this.log and nlog.

The strings have the format like (from CouchPotato) python:[2.7, 3.0):|Git.Install::|rktools.2003::|PyWin32::|SABnzbd:[0.7.5, ]:
This becomes

        python (≥ 2.7 && < 3.0)
        Git.Install
        rktools.2003
        PyWin32
        SABnzbd (≥ 0.7.5)

At the moment these string is just splitted at the "|" character without any further parsing.

the algo has a problem doing a good job when the name ends in -pre like ChocolateyGUI.0.1.5-pre

In order for the Unit Tests to run on the MyGet Build Services, looks like the version of NUnit that is being used currently needs to be updated:

"Running the tests.
[warning] File 'Chocolatey.Explorer.Test.dll' is not supported by any installed test framework. It will be ignored.
Location: D:\temp\tmp2F81\Chocolatey.Explorer.Test\bin\x86\Release\Chocolatey.Explorer.Test.dll
[ignored] Unsupported Chocolatey.Explorer.Test.dll
Detected a probable test framework assembly version mismatch.
Referenced test frameworks: 'nunit.framework, Version=2.5.10.11092, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77'.
Supported test frameworks: 'nunit.framework, Version=2.6.0.0-2.6.65535.65535', 'nunit.framework, Version=2.4.8.0-2.4.8.65535', 'nunit.framework, Version=2.5.0.0-2.5.3.65535'."

For the powershell interaction we use WMF3 (Windows Management framework 3.0 http://www.microsoft.com/en-us/download/details.aspx?id=34595 ) which is not always installed it seems. We should probably have WIX install this.

http://wix.sourceforge.net/manual-wix3/install_directx9.htm

Installed packages are read from the chocolatey lib dir. It looks like directories of old package versions are not removed (not sure if that's a bug or a feature). So ChocolateyLibDirHelper tries to guess which version is the highest one by string comparison of the version string. This works fine in following case:

• git.install.1.8.0
• git.install.1.8.1.2 <-- highest and reported as highest

And it fails for example in following case:

• freefilesync.5.9 <-- reported as highest
• freefilesync.5.11 <-- highest

cver freefilesync reports the correct version. But using this command for detecting installed versions would worsen performance a lot.

Since the application is dependent on .Net Framework 4.0, should we add this as a dependency, in the same way as we did PowerShell? There isn't currently a chocolatey package for .net 4.0, but there is one for 4.5:

http://chocolatey.org/packages/DotNet4.5

So we could copy that one, and just install 4.0.

Thoughts?

Currently, all the old versions of the packages are pushed to MyGet, every time the build happens, rather than just the latest one. After a conversation with the MyGet team, the suggestion is to place all these items into a packages folder in source control, so that they are not included in the update.

Also, suggest changing the output of the msi build, so that it also goes to the BuildArtifacts folder, which is not part of Source Control.

see subject.

I want to add an export of installed packages in JSON format so that you can save it and import and install those packages on another machine.

Suggested enhancement:
Allow the option to generate Boxstarter URL for selected packages as well.

Translate to C# and add to code.

You're welcome.

Imports System.Runtime.CompilerServices

Namespace Extensions

    Public Module ControlExtensions
        <Extension()>
        Public Sub DoCrossThreadCall(Of TControl As Control)(ByVal control As TControl, ByVal controlAction As Action(Of TControl))
            If control.InvokeRequired Then
                control.Invoke(controlAction, control)
            Else
                controlAction(control)
            End If
        End Sub

    End Module

End Namespace

See subject

Looks like there is a new version of RhinoMocks ready to be updated, so I would suggest that we go ahead and get this updated, assuming that there aren't any breaking changes.