use VScmdshell both as addin and from shortcut

Topics: User Forum
Sep 5, 2006 at 3:05 AM
It would be very convenient to have VScmdshell available both within VS and from a shortcut.
The user interface is friendlier and easier to use than the standard cmd user interface (such as being able to use Windows-style cut and paste, etc.).
I looked at the source code and it would appear that all that would be needed would be a small host executable to call the command shell dll.
Realizing that this would not be a priority, can I get some advice to assist in implementing this capability?
Coordinator
Sep 5, 2006 at 3:28 AM
It is not too difficult to modify the code to make VSCmdShell a stand alone application especially if you are fine with keeping Visual Studio as a requirement since code is using EnvDTE namespace (Visual Studio automation interface).

ShellTextBox class is already a user control implementing all of VSCmdShell's functionality thus it can easily be hosted in a WinForms application but code would have to be modified to check if extensibility object is null and disable Visual Studio specific functionality to avoid crashes. Similarly options pane is also a user control which can be loaded in a WinForms app.

If you want to remove Visual Studio dependency, you will have to remove all references to EnvDTE namespace in the code and remove functionality specific to Visual Studio (such as executing Visual Studio commands)

Thanks,
Bertan



Sep 10, 2006 at 1:06 PM
I was able to create an exe with a DLL that uses the same techniques as CommandShellHost.
However, as you pointed out, the dependencies made this more difficult.
I used the same concept of starting an instance of cmd.exe, rather than being able to reuse the DLL itself.

I was able to reproduce one of the reported bugs with vscmdshell, and believe it is a consequence of the manner in which cmd.exe is being run.
Executing a Windows program is delayed until the instance of cmd.exe terminates.
Prefixing the windows command line with the "start" command avoids this problem.
Is there an easy way to determine that the program being executed is a Windows portable executable rather than a DOS program, other that opening and reading the code?