Otherwise it will be missing when a grace cleanup email is being sent in
the startup phase.

Refers to #31

Refers to #31

Refers to #6, #25

Fixes #31

Note that they are not included in the example configuration files as
these settings can easily mess up everything and should only be adjusted
with great care.

The default settings are valid on Windows 7 and Server 2012 and were
successfully tested on those versions.

Fixes #11

This parameter has a different default setting with RoboCopy in the
Server 2012 version: "DA" (data and attributes), compared to "T"
(timestamps) on e.g. Windows 7.

Forcing this setting to be the same for 2012 and 7 seems to fix the
issue of files not being transferred. More testing is needed though!

Refers to #11

Disabling attributes and owner settings.

Refers to #11

Try to move the corresponding transfer package out of the processing
location to prevent it from being picked up again and producing the
same problem again, move it to the error location instead and reset the
transfer variables.

If a new directory is found in incoming but the move operation to
processing failed for some reason, the timestamp and username
directories (and potentially some partially moved data?) would remain
in processing. To prevent confusion about those "incomplete" transfer
candidates they are moved to the "ERROR" location.

Use a list to keep track of directories in the incoming directories that
couldn't be moved to the processing location and ignore them until the
service is restarted.

Refers to #9

This commit is successfully tested to work on Windows 7 with the latest
version of RoboSharp (at the time of writing, including the
[EnableRaisingEvents fix][1] which has not yet been merged upstream).

This closes #15

[1]: https://github.com/tjscience/RoboSharp/pull/46

Refers to #3, #11, #15

The shared approach results in conflicts if the generated class is used
in ATxCommon which is imported in the other projects. This way we can
use the symbols defined via ATxCommon in all depending projects.

The downside is that it slows down the build-process a bit as every
build from a project depending on ATxCommon (read: all others) will
change the generated code and thus force a re-build of ATxCommon and
the project itself. Since building the entire solution is still just
a matter of seconds, that's a fair trade-off.

See https://stackoverflow.com/a/10334095/2018314 for details on sharing
resources among multiple projects in a solution.

There is no need to have this only as a post-build event, providing it
at this stage will allow us to include it in the assembly information.

Refers to #18

Refers to #18

Refers to #18

Add the template files as links to the ATxService project, pointing to
the central "Solution Items" files and mark them for copying to the
build output location. Update the Make-Package script accordingly.