2015-08-21

[SOLVED] Visual Studio "Attach to Process": Available Processes list appears empty

The Quick Answer:


  • Open the "Attach to Process" dialog (For VS2012: Alt-D | P)
  • Open Task Manager (right-click taskbar | Start Task Manager)
  • Find msvsmon.exe, highlight it, then click End Process button
  • Go back to "Attach to Process" and click "Refresh" button

The Story Behind the Answer:

I don't know if this will apply to more than Visual Studio 2012, but if it does, fantastic; please let us know in the comments.

A few days ago, my Visual Studio 2012 went wonky and decided to not show me the Available Processes in the "Attach to Process" dialog in most cases.

Here is what it should look like:

Here is what it looks like when the problem occurs.  Notice how, if I hover inside it, it will show me the tooltip for the process I'm currently over.  This suggests the list is actually populated, and double-clicking on that spot will actually make the debugger try to attach to it.  The information is there; the questions are, "Is it white font on white background?" or "Is there some other kind of painting/rendering issue with the dialog box?"

Looking around the internet, I could not seem to find the right phrase to search to find help with this issue; until I finally stumbled upon this StackOverflow question that was as close as I could get.  One answer suggested renaming MSVSMON.EXE in the x64 folder and copying the x86 version to it.

Not feeling comfortable with that, I decided to experiment with a similar concept.  I opened Task Manager and saw that msvsmon.exe was a running process.  

I executed an "End Task" on the process, and was met with this error:
Going back to my already open "Attach to Process" dialog, I clicked "Refresh" and BAM! ... there appeared the visible list.

I have done this several times, each time resulting in success.  I hope it works for you!

2015-07-03

Data Dynamics Reports - Enabling sorting on column headers causes abnormal height growth when CanGrow is True

I ran into a weird one today when working with a Data Dynamics Report (DDR) that needed sorting enabled on the column headers of a table.  Each of the TextBox controls in the column header cells were set to CanGrow=True, which was good to make sure each could fit their content.  Width was forced, so the only way for it to grow was in height.  It worked great until I enabled sorting.

Each column cell required sorting, so I added the SortExpression to each accordingly.  The instant I brought up the report in the WebReportViewer, it looked like the heights of the header cells were twice as tall as needed to fill the largest content of any of the given cells.

I then reverted my changes and the height went back to normal, making the height of the table row equal to the cell with the most content in it.  I deduced that DDR was computing height based on the extra sorting control being added to each cell, but somehow was calculating too much.  As I changed strings, the height would grow relative to the amount of content in the cell... so if the string was longer, the cell would grow all the more tall; looking double what the content in the cell was taking in height.

As I was about to give up and disable sorting on the report because the headers were taking up 1/3 of the page, I decided to try an experiment.

I turned CanGrow=False on every one of the column headers' TextBox controls (leaving the sorting enabled.)  The height went down to minimal, where only one line of text would show, and the rest was hidden because the row wasn't tall enough.  Great.  I have a baseline now!

The next step was to try changing CanGrow=True only on the cell I knew would have the most content in it.
Win!

So if you run into a similar issue, try the following:

  • Change CanGrow=False on all TextBox controls in your column headers, except the cell you know will have the largest content.