By default, if you open a new file you get a new tab in your document window. After awhile, you can end up with forty two open tabs. To get things back under control, you have to use the Windows | Close All Documents choice, or right-mouse click on the one tab you want to keep open and select the Close All But This option).
If you want, you can have Visual Studio open any new document in your current window (provided that the current window has no unsaved changes). So, when you double-click on a file in Solution Explorer, the current window's content is replaced with the content of the file you just opened. You only get a new tab if the file in the current window has unsaved changes.
To turn this feature on, go into Tools | Options and in Environment | Documents check the "Reuse current document window, if saved" option.
Taking advantage of the feature does require a different mindset. When I use this feature, I start off by opening new tabs until I do a build or a debug (that saves all of my current changes). After that, when I open a new file, that new file replaces the file in the current tab. I find that I start searching my currently open tabs for "Which file do I want to get rid of?" I then select that file's tab and open a new file. It keeps the number of tabs under control, but it is a different way of working.
Do you have a Visual Studio tip, you'd like to share? Send it to me at phvogel@1105media.com.
Posted by Peter Vogel on 04/26/20110 comments
I never delete code -- you never know when you might want it back. So I spend a lot of time commenting out code. I do this so often, and mousing up to the menu takes so long, that I've memorized the keystroke combination for commenting/uncommenting code. It’s actually one of the few keystroke combinations -- other than Undo -- that I remember.
To comment a group of lines, first select the lines. Then, holding down the Control key throughout, press K, then C. To uncomment, hold down the Control key and press K, then U. (These two stroke combinations are called "chords.")
Do you have a Visual Studio tip, you'd like to share? Send it to me at phvogel@1105media.com.
Posted by Peter Vogel on 04/19/201157 comments
You can get Visual Studio to create classes for managing (or, at least, observing) computer resources for you. In Server Explorer, under the Management Classes node, you'll find a list of "things you can manage." This includes desktop settings, processes/threads, and printers (!!), among other resource.
Find the item you want, right-mouse click on it, and select "Generate Management Class" to have Visual Studio generate a management class for you.
For instance, right-mouse clicking on My Computer in Server Explorer generates a class called ComputerSystem (in the namespace ROOT.CIMV2) with all sorts of read/write properties for changing settings on your application's host computer. It also includes many read-only properties for checking the computer's state. Several enumerations are included to allow you to write readable code.
There's another way to get Visual Studio to create a class for managing computer resources for you. If you work with Message Queues (or any of the other things listed in Server Explorer), Visual Studio is more than willing to generate a control that you can use from your code to manage that resource.
Just click on the item in Server Explorer and drag it onto a form (or any other design surface). Dragging a Message Queue from Server Explorer gives you a control dedicated to that queue with Receive and Send methods (and a ton of other methods and properties). You can do this with anything listed under the Services node or any of the categories listed under Event Logs.
You can use this feature in a class library, even though classes don't normally have a design surface. In Solution Explorer, right-mouse click on your project and select Add Component, instead of your normal Add Class. That will give you a "class with a design surface" that you can drag Server Explorer resources onto.
Don't go nuts! You can drag some but not all from Server Explorer -- see http://msdn.microsoft.com/en-us/library/84s2c1k0.aspx for a list of what you can and can not drag.
Do you have a Visual Studio tip, you'd like to share? Send it to me at phvogel@1105media.com.
Posted by Peter Vogel on 04/12/20110 comments
I'm constantly creating simple projects to test out some idea or as part of reviewing a new tool. By default, as soon as you create a new project, Visual Studio automatically saves the project file and, well, everything else. After awhile, I end up with 142 projects with dummy names ("TestTool", "TestTool1", "Experimental", "Experimental1", and so on).
You can turn off this behavior so that projects aren't saved until you tell Visual Studio you want them saved (you will be asked when you exit the project). Go to Tools | Options and under Projects and Solutions | General uncheck the "Save new projects when created" option.
This doesn't work for all project types (it has no effect on ASP.NET or Silverlight projects, among others, for instance). Fortunately, it's easy to tell whether it works on the project you're creating: You won't have the Location textbox at the bottom of the New Project dialog. Don't Panic! You'll get a chance to save your stuff when you leave the project. Or, if you've done everything you need to do with the project, to not save your stuff later.
For any project that you do want to keep, though, it would be a good idea to do a Save soon after starting the project. If you don't do a save and Visual Studio crashes, you may not be able to recover your project.
Do you have a Visual Studio tip, you'd like to share? Send it to me at phvogel@1105media.com.
Posted by Peter Vogel on 04/05/20110 comments
SharePoint developers working in Visual Studio 2010 know that GUID collisions can be a needless nuisance. Brian Watts sent along this tip that he got from one of Doug Ware's
tutorials on SharePoint. Brian adds a pre-deployment command to his Visual Studio build-deploy-debug process that deletes and recreates his SharePoint site before he does any testing. Brian says he can't remember the last time he had a problem with a GUID clash.
To make this happen, in your SharePoint 2010 project, go into the Properties window, select the SharePoint tab, and add the following code to the pre-deployment Command Line box at the top of the window:
stsadm -o deletesite -url <url for his site>
stsadm -o createsite -url <url for his site>
-owneremail <your email>
-ownerlogin <your admin id, including the domain name>
-siteTemplate "STS#1"
-description "A test site"
-title "Test Site"
Brian says it might be adding a couple of seconds whenever he presses F5, but that delay is more than worth the benefits of avoiding any problems.
Do you have a Visual Studio tip, you'd like to share? Send it to me at phvogel@1105media.com.
Posted by Peter Vogel on 03/29/20110 comments
While all of the tool windows in Visual Studio (Solution Explorer, Properties, Debug) are wonderfully useful, the main editor/document window where your code lives is the one that matters.
You can instantly give yourself a document window that completely fills Visual Studio by selecting Auto Hide All from the Windows menu. This causes every (every!) tool window to turn into little labels hugging the borders of Visual Studio and popping out only when you want them (or when Visual Studio thinks you should want them). If you can't find Auto Hide All, it's because you've already closed or hidden your tool windows.
There is a downside to this: There's no "Restore to my last setting" option on the Windows menu so, you'll have to get used to having every (every!) tool window in autohide mode. You can get back to the default window layout for your configuration of Visual Studio by selecting Reset Window Layout from the Windows menu, but you won't get any customizations you've made to that setup.
There doesn't seem to be a way to save your favorite layout as the "default layout" that the reset menu choice restores. The only way to get back to your personal settings would be to have exported your settings at some point in the past and re-import them using the Tools | Import and Export Settings menu choice -- which seems like an awful lot of work (and not very speedy, either).
[Click on image for larger view.] |
| Figure 1. Big Editing Window. Auto Hide All opens up all the interior space inside the Visual Studio window for you to edit code. |
But as I said, you get all of that editing space....
Do you have a Visual Studio tip you'd like to share? Send it to me at phvogel@1105media.com.
Posted by Peter Vogel on 03/22/20118 comments
We're changing up our coverage on the Visual Studio Magazine Web site. Yes, I'll continue to
review development tools in each issue of VSM, but the focus of this blog is shifting. Rather than look at the third-party tools industry, I'll focus on making you more productive with the tools you use every day: Visual Studio and .NET Framework.
Starting this week, I'll be publishing useful tips and tricks that can make you more productive. That includes (but isn't limited to) getting more out of Visual Studio. There is a ton of useful stuff in the IDE that I don't think anyone outside of the Visual Studio development team knows about. The same is true of .NET as a whole. There are features in the .NET Framework that are waiting for you... if you only knew about them.
Now you will. I'll be mining for these valuable nuggets and delivering fresh tips to you every week. Obviously, I'm not tracking tools anymore, so we've retired the ToolTracker blog name. Starting today, the new name for this blog will be ".NET Tips and Tricks."
And if you know a cool tip, send it along to me at phvogel@1105media.com . We may put your tip in the column and put your name up in lights.
Posted by Peter Vogel on 03/21/20110 comments
If you saw my earlier post on
cool slogans from software companies , you know that the slogan from
ComponentOne is "Less Coding, More Business Logic". I like that philosophy (though personally I'd have gone with "Less grunt work, more functionality"). Still, I think
Infragistic's "Killer apps, no excuses" has more attitude.
Posted by Peter Vogel on 03/03/20111 comments
In March, we're going to round out our reviews of major product vendor suites by looking at ComponentOne's Studio for ASP.NET AJAX. It's a good time to take a look because
ComponentOne has got a new release coming out.
Well, actually, they've got a new release of their Studio Enterprise coming out: Every suite for every platform in .NET (and ActiveX, too). It's hard enough to review the component suites without reviewing suites in seven different technologies, at least some of which I'm not competent to comment on except as a beginner (e.g. Studio for Compact Framework). How to decide which suite to review?
It's not quite as arbitrary as rolling a seven-sided die (not that I own such a thing) but it's close. Fundamentally, I look at which audiences we've served recently and pick the audience that we've ignored the longest (and I also factor in the relative size of those audiences). So, if you're wondering why we're looking at the ASP.NET AJAX package, that's why.
In some ways that's too bad: ComponentOne has a new ReportViewer that they're obviously very proud of. I'll be looking at the ASP.NET version, but the press release from ComponentOne talks up the Silverlight version. I don't think it's likely that we'll have a chance to cycle back around to it -- so much software, so little time.
We'll also be looking at Telerik's TeamPulse -- an application lifecycle management tool. We've looked at other ALM tools, such as DynaTrace, Ants Performance Profiler and Sybase PowerDesigner, but it's been awhile since we've visited this topic.
The previous products performed very specific application management tasks, but TeamPulse is operating at a higher level: it's designed to "capture ideas and requirements,... and analyze project state." That's a big job. While I will look at the big picture, I'm going to be interested in how TeamPulse supports the individual developer. Does the product make life easier or harder for the programmer trying to generate code?
Posted by Peter Vogel on 02/18/20110 comments
If you use DataSets and are tired of figuring out what's in your DataSet by asking for Counts of the Rows collection and entering ds.Tables(0).Rows(0)("CustomerId") in the Immediate window, then you need Dan Green's Data Debugger Visualizer. When stepping through your code, you hover your mouse over a DataSet (or DataTable or DataRow) variable and the DataVisualizer's commandbar pops up.
I use DataSets a lot and the Visualizer has saved me endless time in diagnosing problems. The tabbed dialog lets me switch between the schema for the table and a view that shows the data in the rows. I get the row count for any table I choose and can switch between seeing "live" rows or deleted rows. The Row Filter lets me set criteria to limit the rows (useful in large DataSets). For any row, I can quickly see its state (unchanged, deleted, etc.) and, for any field, its original and current values (and any cell errors).
The tool can be downloaded from CodePlex as a Visual Studio 2005 project. Open it, build it, and the appropriate DLL is created and dropped into the right Visual Studio folder. After that, you'll find it waiting for you when you right-mouse click on a DataSet reference. While the tool is free, the author welcomes contributions.
This isn't the only DataSet visualizer out there (you might, for instance, want to check out RightHand's visualizer). Visual Studio 2010 comes with its own DataSet Visualizer, which I'm getting used to, but for old times' sake I recompiled Dan Green's tool into Visual Studio 2010. I had to update the reference to Microsoft.VisualStudio.DebuggerVisualizers. But other than that, the tool worked just like always.
Posted by Peter Vogel on 02/14/20111 comments
We recently reviewed Infragistics' "data visualization" bundle, concentrating on the Silverlight package (
Visualizing BI with Infragistics NetAdvantage for Silverlight Data Visualization). Since I consider myself a "business/database developer", the idea of a class of applications called Data Visualization was -- to the say the least -- intriguing. Fortunately, Megan Sheehan, senior product manager of Data Visualization at Infragistics, was able to take the time to talk about the product line.
Peter Vogel: What is "Data Visualization"?
Megan Sheehan: Data visualization is the process of visually representing often times complex data in a way that end users can understand. Most organizations have a plethora of data that they use to inform their business decisions, share information with customers and track their performance. Displaying data in charts, graphs and pivot tables helps people find the meaning in the numbers. Without Data Visualization, sometimes it's like looking for a needle in a haystack.
PV: Why would an organization buy your package rather than, for instance, a Business Intelligence package?
MS: NetAdvantage for Silverlight Data Visualization offers a full range of UI controls for business intelligence as well as maps, gauges, timelines, barcodes, an organizational chart and many others. The performance, quality and breadth of controls are the most compelling aspects for our customers.
PV: Who is the market for a package like "Data Visualization for Silverlight?"
MS: Silverlight developers who want to communicate information clearly and effectively, frequently as part of a line of business application. It's difficult to visually represent complex data well. The Data Visualization for Silverlight product helps developers display data in many different ways -- from charts and pivot grids to graphs, maps and gauges.
PV: What are the differences (if any) between the WPF and the Silverlight package? Why develop two different packages?
MS: We are committed to building our WPF and Silverlight controls on a unified foundation, so we have strived to have parity between the products from the onset, as much as the platforms permit. We decided to pursue this strategy for several reasons. First, we know that our customers are targeting multiple platforms depending on the needs of the project they're building, so we want to give them the tools that they need to be successful. Next, we feel we can deliver better usability and quality by sharing as much code as possible between the WPF and Silverlight versions of each control. It's easier for our customers to share/reuse code between their WPF and Silverlight applications if we ensure that our controls are comparable. By leveraging shared source code, Infragistics can deliver more UI controls to market faster.
Posted by Peter Vogel on 02/10/20110 comments
Julian M. Bucknall, CTO at DevExpress
continues our discussion on the Visual Studio/.NET toolspace, this time looking at DevExpress' users and process for extending the package.
Peter Vogel: Are there differences between creating a suite for ASP.NET developers and other developer groups (e.g. WinForms/Silverlight/WPF/whatever)? I.e. what do these target markets share and where (if anywhere) do they look different?
Julian M. Bucknall: Apart from the basic differences of platforms, yes, there are differences. For example, ASP.NET customers expect to see live demos on the website whereas WinForms developers are happy to download demos and install them to view the functionality. What we also try and do (sometimes more successfully than others) is to abstract out the non-platform-specific code into code codebases and to build on those for each platform UI. Data binding tends to be different across platforms as well, so we have to be cognizant of those differences.
PV: How does DevExpress decide what to add to the suite? What to enhance next it the suite?
JMB: It depends. Generally it's feedback from customers: they're using X in their apps, but it would be great if feature Y were available. The more feedback we get for a particular feature or control, the more likely it is we'll add it. (We essentially allow people to track particular suggestions: the more trackers for a feature, the higher the "vote". We're working on making this more transparent by implementing a Facebook Like button or a Stack Overflow vote up/down button.)
Oftentimes it's because we are tracking what popular applications are doing with their UI, Microsoft Office being the canonical example. So if you see something in the new Outlook/Word, you'll see us support the same look-and-feel pretty quickly. The same goes for Windows itself, of course. And then we monitor what websites are doing so that if there's some particular UI metaphor we should be following, we'll notice and support it for our customers.
Finally, it's the developers themselves who will decide that they need such-and-such a feature. We use our own controls in our internal applications so we as a company will notice issues and problems with our controls and request features to make our lives easier -- and of course we know where the developers live. ;)
Posted by Peter Vogel on 02/03/20110 comments