I've just learned about Visual Studio 2010's Command Window, and am hoping it might be able to automate a short set of tedious steps.
Is it possible to put several Command Window commands into a file and execute them?
The scenario I have in mind is:
open a particular source file (hard-coded path is known)
set a breakpoint at a particular (fixed) line number in that file
I want to be able to do this easily in a given, open solution - without having to go to the line number by hand, and set the breakpoint by hand.
(The line is the point where a null smart-pointer is dereferenced, and so is a very common location for breakpoints.)
Edit - possible alternatives
Recording a macro - I almost mentioned in the original post that I'd considered a macro, but I was wanting to version-control the commands, and macros are binary files, so not amenable to version control
Creating an add-in - Creating source-code and a DLL, to run some simple commands seems unnecessarily complex to me.
Visual Studio 2010 and newer provide a built-in mechanism to answer the specific scenario in the question, namely a way to easily set a break-point in a specific line in a specific file.
The mechanism is well-written up in VS 2010 Debugger Improvements (BreakPoints, DataTips, Import/Export).
This screenshot whose VS 2010 exporting breakpoints to XML files – which you can then share with another developer, or re-load later:
There is also a corresponding "Import breakpoints from a file" button.
Related
I have a dtsx file that deals with more than 200 table export and script that log information before and after completing export of each table. I am trying to change the logging to include more details, It is a time consuming process to open one by one log script object, click edit and make my changes. I opened the dtsx file in notepad++ with regex, I updated the script text by adding more log information. But my changes are not in effect when I run SSIS.
When I open the modified dtsx file in visual studio 2013, double click log script object, click edit then add a space save on all the log objects then my changes are in effect.
I compared those two files (one modified from notepad++ other from visual studio), other than some GUID difference and my new space character there is no change. Why my changes are not in effect when I make them in notepad++? Am I missing something?
Excellent! The root issue is that much like if you make a change to a C# class file, those changes wouldn't be reflected in the application until you compile. That's what's happening here, you've changed the source script for the SSIS package but you need to compile that script into byte code so it can actually be run.
The 2005 release of SSIS allowed us to specify whether the code should be compiled at run time versus design time but that didn't work out well at all so at some point in the lifecycle of 2005, that ability was nixed and the code had to set at design time.
I think I've seen code to compile a script task/component but whether that was on SO or elsewhere is a mystery at this point. I believe Matt Mason indicated there were changes in how things compiled between 2005/2008 and 2012+ but I can't find the post. There is this post which might give you a shove in the right direction for which classes you'll need to use to get the packages to compile.
I'm currently using Visual Studio 2010 and Visual Assist X to do rename refactorings in managed C++ code. For small codebases or renaming items which are not used very often in the code it works great.
It's almost impossible to rename an item which is used frequently in a large codebase because Visual Assist keeps every changed file open and unsaved. This means if there are a lot of files open the next file takes even longer to be opened.
Since I'm using version control this does not make sense to me because I could revert all the changes if something went wrong.
Is there a way to do that refactoring without keeping files open? Maybe also with another VS extension? I did not find any information about so far...
For example:
I have a solution with about 100 projects, if I rename a class which is used frequently Visual Assist X's execution of renaming takes about 30 minutes or more. It opens every file which must be changed. As longer the renaming runs, the more files are open in VS and the more longer it takes to open another file...
At least there is a workaround.
When I have too many tabs open, I close them via Window / Windows ... and there Ctrl+A, de-selecting one or two needed windows and then "Close Window(s)".
Additionally I use File / Save All excessively. I have it mapped to Ctrl+Shift+S but I'm not sure if this is standard.
I know I will miss so much of Visual Studio but I am getting really sick of it crashing all the time and being slow, PLUS it is always changing things in my repository that I don't want to change, so I want to just edit with Notepad++. However, now I will have to load up VS just to build things. Is there a way I can build from command line and make a script for it and what not? Will it show the compile errors?
Please don't try to troubleshoot VS for me, I am just asking what is in the question and the rest was just given for context and so nobody was like 'Y U NO RIKE VIZAL STUDIA?'.
build: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "PATH TO YOUR SOLUTION FILE"
help: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /help
What you need is directly calling csc.exe, the C# compiler (which is called by the build system of Visual Studio, anyways). If you ever worked with GCC, it is quite similar except that options are passed Windows-style with / signs instead of -- and there are no object files or additional linking. The MSDN library has documentation: http://msdn.microsoft.com/en-us/library/78f4aasd.aspx.
Generally, you'd need something like:
csc /target:exe /out:Something.exe *.cs
plus any /reference's you would add in Visual Studio.
If your project is large, it may be uncomfortable to maintain a .bat file to do the compilation, so a build tool like NAnt may be needed, which is quite similar to the Ant used for Java.
This is of course if you want to eliminate Visual Studio entirely. Otherwise, Snowbear's solution of invoking MSBuild.exe will be just as fine.
I have been playing with the Command Window in Visual Studio (View->Other Windows->Command Window). It is great for several mouse-free scenarios. (The autocompleting file "Open" command rocks in a non-trivial solution.) That success got me thinking and experimenting:
Possibility 1.1: You can use the Alias commands to create custom commands
Possibility 1.2: You can use the Shell command to run arbitrary executables and specify parameters (and pipe the result to the output or command windows)
Possibility 2: A previously setup external tool definition (with project-relative path variables) could be run from the command window
What I am stuck on is:
There doesn't appear to be a way to send parameters to an aliased command (and thus the underlying Shell call)
There doesn't appear to be a way to use project/solution relative paths ($SolutionDir/$ProjectDir) on a Shell call
Using absolute paths in Shell works, but is fragile and high-maintenance (one alias for each needed use case). Typically you want the command to run against a file relative to your project/solution.
It seems you can't run the traditional external tools (Tools->External Tools...) in the command window
Ultimately I want the external tool functionality in the command window in some way. Can anyone see a way to do this? Or am I barking up the wrong tree?
So my questions:
Can an "external tool" of some sort (using relative project/solution path parameters) be used in the Command Window?
If yes, How?
If no, what might be a suitable alternative?
StudioShell is another good, powerful, option. There's nothing quite like navigating around your solution (and Visual Studio as a whole) as if it were a file system. Scriptable of course. I've just begun to scratch to surface of this tool.
Seems as if there may, indeed, be a (much) better approach.
How about a VS extension that embeds powershell into the IDE and allows one to use DTE (Visual Studio Automation Objects)?
Yeah. That would do the trick and much more.
"An interactive, scriptable shell?" you ask? "Yes!" I say.
autoexp.dat does not seem to take affect in Visual Studio C++ 2005 debugger.
I am not trying to add any custom rules. Just want commonly used stuff like stl::string, to display in a friendlier manner.
Does anyone know. how I can accomplish this? Is this just question of specifying a path to the autoexp.dat file somewhere. The file is available under the Visual Studio installation directory.
I had a similar problem in 2008, with the debugger showing only the e.g. std::vector _Myfirst,
_Mylast members rather than the vector size and children.
Open Tools/Options/Debugging/General and clear the flag "Show raw structure of objects in variable windows"
(Presumably the suggest
This got me the closest.
http://garrys-brain.blogspot.com/2007/12/stlport-visual-studio-2005-visualisers.html
It would appear you need to make adjustments for types while using ports.
Also you might have to make changes to the display to display exactly what you want.
I think this may have to do with the infamous VirtualStore in Windows Vista/7. I could change this in XP but when I try to update the autoexp.dat file in Win7 it creates a copy in AppData\Local\VirtualStore.... instead. I assume that the studio does read the original file when starting, so my changes are not seen. If anyone knows how to be able to edit the actual file please tell me how!