It seems wlfreerdp doesn’t support remoteapp. SeeTicket 6573.
On my side: wlfreerdp opens fullscreen and after login the screen is black. After waiting a few minutes the Session is closed from serversite.
So if you want to use remoteapp use xfreerdp.

RemoteApp is defined in[MS-RDPERP]: Remote Desktop Protocol: Remote Programs Virtual Channel Extension

Windows 7 SP1 to Windows Server 2008 R2 (Firefox 4):mstsc_remoteapp.zip

Even though [MS-RDPERP] mentions a single virtual channel, “rail”, the packet capture shows the client registering “rail”, “rail_ri” and “rail_wi”.

More details about “rail_ri” and “rail_wi” can be found on thispage.

RemoteApp support was introduced in FreeRDP 1.0, so you should get the latest sources from git.

./client/X11/xfreerdp -u <username> -p <password> --app --plugin rail --data "<exe_or_file>:<working_dir>:<arguments>" -- <hostname>

exe_or_file: usually a program alias prefixed with “||”, otherwise a full path to an executable file.

working_dir: the working directory to use for running the application

arguments: arguments to pass to the application when it is being launched (it has to be allowed on the server explicitly)

For instance, if you configure your server to export the command prompt, it will have the “cmd” alias by default. You could then get the windows command prompt with a command like this:

./client/X11/xfreerdp -u Administrator -p Password --app --plugin rail --data "||cmd" -- 192.168.1.200

If you haven’t installed FreeRDP globally on your system and you are running from the source tree, change —plugin rail.so to —plugin channels/rail/rail.so.

Alternatively, it is possible to use full paths to launch a program instead of an alias. Please note, however, that Windows Server 2008 R2 SP1 disallows this by default and you need to enable it in the group policies. In this case, the command would look like:

./client/X11/xfreerdp -u Administrator -p Password --app --plugin rail --data "%windir%\system32\cmd.exe" -- 192.168.1.200

You may also want to try newer syntax:
xfreerdp /u:user /d:domain /p:password /app:"||calc" /v:server

There is currently an issue where the usage of the colon ‘:’ conflicts with the —data argument separator, so paths like “C:\Windows\System32\cmd.exe” won’t work. If you are experiencing such issues, use environment variables like%windir% to work around the problem until a more permanent solution is found.