I'm creating PowerShell module in VS 2012. So for comfortable debugging in debug project properties I set Start action to start external program PowerShell.exe and in command line arguments I want to add
-Command { Import-Module [MyDllFileName] }. What should I write instead of [MyDllFileName]? There should be my compiled dll.
The answer propsosed in the linked question is still pretty much valid, but you have to think it through a bit.
First of all the actual answer remains: it's simply not possible to get the assembly name onto the debug command line using the project settings.
Second there are a couple of things you can do however:
The debugger command line is stored in the projectname.vcxproj.user file as the LocalDebuggerCommandArguments property. Write a script/extension/... to set that property to $(TargetPath) and off you go.
Based on the solution propsed in the other question: use an external tool with something like devenv /DebugExe powershell.exe - Command { Import-Module $(TargetPath) }.
Like 2, but place a DebugBreak() statement somwhere in your dll and just launch PowerShell, it will coma and ask to attach the debugger when it sees DebugBreak/add.
Related
The debug tab of the project properties for a console application in VS2010 allows me to set command-line parameters to pass to the project whilst debugging.
I would like to set a parameter which is a path and the path is specific to each developer/machine, as it is a path which resides in the solution folder and each environment is different.
For pre- and post-build events, I can use macros such as $(ProjectDir), but I can't find a way to do this for command-line parameters - is there a way? A hack is fine, as long as it's not too awful!
Thanks
I haven't found a way to use $(ProjectDir) in the command line arguments, but you can access files contained within the project by:
Tell Visual Studio to copy specific files to the output directory by changing their "Copy to Output Directory" property.
Change your command line arguments from $(ProjectDir)/FileNeededDuringRuntime to FileNeededDuringRuntime.
This is more of a hack since it probably doesn't cover all the cases of using the variable, but it may get you by if you're just referencing a few files.
Macros can be used in command line arguments for C++ projects, see:
How to pass solution folder as parameter in command line arguments (for debug)?
You could have an empty C++ project "Set as StartUp Project" and change its "Configuration Properties -> Debugging -> Command" from "$(TargetPath)" (default for new projects) to "$(ProjectDir)..\OtherProjectRelativeDebugFolder\OtherProjectsOutputFileName.exe".
Since OtherProjectRelativeDebugFolder and OtherProjectsOutputFileName are relative and thus location independent you should be fine with that.
You said:
A hack is fine, as long as it's not too awful!
Is an empty project that produces an empty dll (unless you find a way to stop it, e.g. delete on post-build) too awful?
BTW. Environment variables aren't resolved in "Debug -> command line arguments" for C# either. I'll be experimenting on setting an environment variable, passing its name (because it isn't resolved) and reading it in the program. Passing the name is intended to show where the environment variable comes from, i.e. project settings.
Edit:
I hoped to find a way to set the environment variable to the value of a macro, e.g. in a build event. A simple shell "set" command is not persistent, so it didn't work out. Instead I was able to use a relative path as working folder to get things work for me. I also found a workaround that uses a file for persistent storage:
VS2010 - Project Macro Variables in Start Options Command Line Arguments
I have a solution file for a command line executable. I want to run my executable, with different inputs, through the debugger without my interaction, while also setting its output to a log file.
For example, this is sort of what I want:
devenv /DebugExe "myprogram.exe" "my inputs"
That loads VS and automatically sets my programs inputs. However, I want to do this over and over with different inputs to my program and mine the output files later. So the closest I've figured out, but doesn't work, is this:
devenv /RunExit "myprogram.exe" "my input set" /Out out1.log
devenv /RunExit "myprogram.exe" "a different input set" /Out out2.log
...
Is there any way to do this? Again, the important part is that I could queue up a bunch of runs and mine the output files later for their output.
While I did find a way to do what I want, I don't like it. So I'll wait a while before marking my own answer as accepted.
What I really needed and wanted was what I stated in my question:
devenv /RunExit sln "input args" /Out out.log
The problem is that VS doesn't allow this, "input args" is invalid - unlike if you were to use say /DebugExe but then there is manual work involved again and that didn't help me. So in the script I'm using to call devenv dynamically, I used a regex to replace the "Arguments = " line in the sln file with the appropriate arguments each time. Then this command line works:
devenv /RunExit sln /Out out%x%.log
Each call the sln is modified to contain the new set of args and so each run, I'll get different output in my out%x%.log file (which I name differently each run so I can keep track of which log file went to which inputs). Thanks everybody for watching.
I wanted to do something similar: in my case one of my parameters was a file system path, which could contain a space, which would have to be quoted, inside the string in the batch file which must be quoted. I enhanced my command line executable's code to also look at environment variables (Environment.GetEnvironmentVariable) in addition to the command line parameters to it. Then just set the specific environment variable value prior to each invocation of devenv.
Is there a way to use the popular Console2 cmd.exe replacement for Visual Studio debugging? In other words, when I debug a console app under VS, I want it to use Console2 instead of cmd.exe.
Interesting question. I looked into it, there are some options but none are pretty.
Console.exe takes arguments, so it's possible to start it with a specific tab and execute an arbitrary process. However, this process will always be run within it's own cmd.exe; for example if your program is c:\my.exe and you launch Console as console.exe -t tabname -r c:\myexe Console2 internally calls CreateProcess( ... cmd.exe c:\my.exe ... ), as a result you can't even see the output of my.exe. This is easily solved though: launch it as console.exe -t tabname -r "/k c:\myexe": the /k switch makes the cmd.exe stay active and you can see your program's standard output. (I looked through the source but couldn't find a way to 'attach' a tab to a currently running Console instance, so launching with arguments will always create a new instance, not sure this is what you are looking for?
You can easily modify the project's debugging properties to reflect the above:
Command: /path/to/console.exe
Command Arguments: -t tabname -r "/k $(TargetPath)"
When starting your exe from within VS, it will launch your exe witin a Console session. However the debugging won't work as VS will try to debug console.exe, not my.exe since that is now a different process. Putting a DebugBreak(); as first line in your exe's main() will sort of solve this, as it will present you the option to debug your exe. All in all, this may a bit too much of a hassle to achieve what you want, but i don't think there's another way: Console always spawns a new process, so the only way to get it debugged is to attach the debugger to it after that process started.
Scott Hanselman blogged about this.
He suggests using this value for Console Settings > tabs > Main > Shell :
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
Sadly for me, This does not appear to work for Visual Studio Express 2010, which lacks a vcvarsall.bat file.
I have an NUnit test assembly (a .NET DLL). When I click Run in Visual Studio I want it to launch NUnit and run the tests in this assembly. I can do all of that.
Instead of specifying the full assembly name and path in the command line arguments, does Visual Studio support some sort of macro that expands into that for the Command Line Arguments box? Most other development tools I have used support this, but I cannot find anything in the documentation about this.
I was expecting something like: %assembly_full_path%
The reason I want to do this is so if the assembly name or build location changes, then I don't have to update the command line arguments as well.
This doesn't work as far as I can tell. Macros in the Command Line arguments box do not get expanded. Not even environment variables. Bummer.
A workaround is to create a custom tool. Tools + External Tools, Add. Title = Run tests, Command = nunit.exe, Arguments = $(TargetPath), Initial Directory = $(TargetDir). Tweak as needed. You could assign a keystroke to this new tool command, even F5.
Using VS2005, the only item I need to provide in the Command Line Arguments is the name of the dll. I suspect VS sets the default working directory to the project's output directory, as I've never specified the path and yet the tests always load correctly.
I'm programming with Visual C++ Express on the command line using makefiles (GNU Make).
For this to work, I have to call the Visual Studio batch file vsvars32.bat to set up the environment. This has to be done everytime I open a new cmd.exe, before using make.
When I try to call the batch file from my makefile, it obviously executes the batch file as
an own process, because the environment is the same afterwards.
So my question: is there a way to execute scripts in cmd.exe like the built-in source command of the Linux/Unix bash? Apart from installing bash on Windows, of course.
Edit after posting my own answer:
The above question is not quite right, it should be like this:
Is it possible to call an environment-changing batch file from within a makefile, so that the changed environment persists for the other programs called in the makefile?
The answer to the original question is yes: you can use the built-in call command of cmd.exe. But since call is a built-in command and not a real program, it doesn't work in a makefile, only if you call a batch file from another batch file.
Answer compiled from the previous answers:
I made a batch file called make.bat which contains the following:
call "%VS90COMNTOOLS%vsvars32.bat"
call make.exe %*
This does the job.
But calling an environment-changing batch file from within a makefile, so that the changed environment persists for the other programs called in the makefile, seems to be impossible.
Edit: After overflowing my PATH variable by repeatedly calling vsvars32.bat, I made the following changes:
if not "%VISUALCVARS%" == "TRUE" (
set VISUALCVARS=TRUE
call "%VS90COMNTOOLS%vsvars32.bat"
)
call make.exe %*
use 'Call':
#echo off
pushd.
call "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars3235.bat"
msbuild LinqSupportClassesSDKBuild.csproj /t:rebuild /p:Configuration=Release /nologo /v:q /clp:ErrorsOnly;
popd
this is the cmd file we use to build our linq provider.
At least in my install of Visual Studio (albeit somewhat ancient VS .NET 2003), one of the links in the VS start menu group is to open a cmd.exe instance with the environment already setup. You might find these helpful:
How to Add Visual Studio Command Prompt (VSCP) to your IDE as a tool?
Running the command prompt from visual studio tools menu
Shortcut: Launch Visual Studio Command Prompt from Visual Studio
They are more geared toward launching the command prompt from the IDE, but they do include information on launching it with the appropriate environment as well which you may find helpful for your purposes.
How do you launch your console? If you are just launching 'cmd' then instead, create a shortcut that executes (%comspec% resolves to c:\windows\cmd.exe or whatever is relevent on your system)
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"" x86
Obviously, change the path to point to the proper installation folder.
More generally, as the above poster pointed out, if a .cmd file needs to process another .cmd file rather than launch it as a seperate process, use the 'call' batch command.
Wrap GNU make in a script (mmake.bat). Put the script in the path somewhere.
The script itself should run the vsvars32.bat and then make, like this
vsvars32.bat
make %*
As far as I remember, invoking a script from another script like this is done within the same shell (similar to Bash "." command).
I have found three solutions to this problem:
1) If the environment variables being set by the batch file are static (that is, they are always the same values), set those values for your entire user profile. Right-click on My Computer, click Properties-->Advanced-->Environment Variables. Add the variables from the batch file to the User Variables or System Variables section (User variables are only visible by you, System variables are visible by all users of that computer).
2) Write a wrapper batch file that calls the environment setup script then calls the Makefile.
3) Instead of using the SET command to set environment variables in the batch file, use the SETX command (requires the Windows Resource Kit). SETX is similar to SET, except it makes its changes to the master environment in the registry and will take effect in all command prompts launched in the future (but not the current one).