After developing a target plug-in myself, I wanted to pass along a few hints that made the process easier
1) While doing a build of your target, it's ok to have the target plug-in VIs open also. You can watch the front panels of the target plug-in VIs and observe parameters. If a failure occurs, the front panel values will show you the state of the system when it failed. You can switch execution target back to windows and then go run that target plug-in VI with the failing values to see what happened. (Note, this doesn't work with SystemExec.vi since it's not reentrant. You might want to wrap it with a non reentrant SubVI so you can watch its controls and indicators change and possibly re-run a command line if you need to)
2) You might want to add some boolean debug flags to your target. For example, if your "debug" command a) emits source code b) compiles the source code c) links the source code d) downloads the object code e) issues a run command to the target If you put each one of those steps into individual case statements and then use a boolean global variable that defaults to true to enable each step, if you wish to disable a particular step, just go to your array of global variables and turn off that step. Front panels of your target plug-in VIs still work even though your target is set to your embedded target
3) If an application isn't working on your target, try running it in the standard Windows target to make sure the VI works there. Then, try and build it in the Windows Console target and see if you can get it to work there. If your VI works in LabVIEW for Windows but doesn't work on your target or on Windows Console, it may indicate a problem with the LabVIEW Embedded module. If it fails on your target but works in the Windows Console target, that may indicate a problem with your implementation of the target.