I've observed some problematic behavior when using the Exec task on Windows with a very long (~17000 characters) command string. There are a few points I've discovered:

• Exec is documented as running through cmd.exe -- the command is not launched directly in a new process.
• Additionally, the command itself is actually run through a batch script containing the command line and some extra commands. The script is launched via cmd.exe.

Error behavior:

• cmd.exe has documented limits on command-line length. On relevant systems, the limit is 8191 characters.
• When an extremely long command is run directly with cmd /c <command>, you get an error message: The command line is too long.
• When an extremely long command is embedded in a script and run indirectly through cmd /c <scriptfile>, you get very misleading and dangerous behavior.

It appears that cmd.exe will attempt to run a command in a script file which is over the length limit, but will silently remove individual characters at the command length boundary. In my case, characters 8192 and 16383 are being silently deleted from the command, but the rest of the command line is unchanged. I spent several hours debugging this behavior, because I thought something was wrong in my app code.

The current state (silent and confusing errors) seems undesirable. Can we do one or both of the following?

• Add an alternative task which launches processes directly: DirectExec or something like that. This could be written by anyone, but it might be generally useful enough to include in MSBuild.
  • Is it feasible for this to just be an option on Exec itself?
• Error out when a command is too long on Windows. We should be able to detect if a string is over the 8191 limit. If we do, we should not try to execute it given the above behavior.