Currently if a package was compressed using PowerShell (Compress-Archive), SnAdmin fails to extract it, possibly because of the Ionic.zip library. We should use the built-in .Net API for extracting packages.

It would be cool if we added a telemetry layer to SnAdmin that would allow us to track what kind of packages are installed (similar to the install/download counter on nuget.org).

• When SnAdmin is executed, try to send some basic info to a central url about the package.
• Strictly anonymous, we do not want to know actually who installed what, we just want to track package usage.
• Store only:
  • package id
  • package version
  • install date
  • result (success/error)
• Only track 'official' sensenet ECM packages, not 3rd party ones.
• Clearly communicate this.
• Must be unobtrusive and robust - do not interfere with package execution in any way (e.g. send info in the background, not slowing down the execution process).

Questions

• opt in or opt out?

The algorithm of executing packages allows you to provide a package name without the (zip) extension. This is useful, because it lets us have packages as folders, without a zip file - take Admin\tools for example, a container that contains built-in tool folders, not zip files.

The problem with the current behavior is that if there is a zip file and a folder with the same name, SnAdmin uses the folder, even if the zip package is newer. This leads to a confusing install process (for example when we update a nuget package to a newer version that contains a new zip package).

Solution: if you execute the package with a name (without extension) and there is a zip file there, we should always execute the zip file. If a folder is there from a previous execution, than delete it before the operation.

The following SnAdmin parameter list results in an incorrectly interpreted param list:

SnAdmin.exe export source:/Root/IMS target:c:\temp\

Note the backslash at the end of the target path. The problem is that SnAdmin puts a quote around the parameter value and passes it over to the SnAdminRuntime tool as a command line argument. It will become this:

target:"c:\temp\"

The result is that SnAdminRuntime receives an incorrect argument (and all arguments after the wrong one will be missing) - so this problem needs to be fixed here, in SnAdmin.

Current workaround is to remove the backslash - which is OK in case of a path, but there can be a different type of parameter where that character is mandatory.

Note: using a manual quote around the target parameter does not work either, so that cannot be a workaround.

This command: .\SnAdmin.exe sn-services-patch-7.0.0-7.1.3 creates an empty directory: sn-services-patch-7.0.0-7.1 and applies it as package directory. It causes an InvalidPackageException: "Manifest not found."

Currently the sandbox folder (called run) is created next to the package that is executed. If packages are stored in multiple folders all over in the file system (instead of a single place), these run folders are created in many different places.

Possible solutions

1. configure a fixed sandbox folder path
2. always create the sandbox folder in the parent of SnAdmin.exe instead of the parent of the current package
3. always copy the package into the Admin folder and execute it from there