Wednesday, June 18, 2008

A couple of weeks ago, I was fortunate enough to attend the Tech Ed 2008 Developer conference. It was my first Tech Ed conference and I had a great time. (Yes, I still need to blog about my experiences there overall and I’m still planning on doing that.) One thing I wanted to bring up if you’ve never been to Tech Ed before is the great experience that the Hands on Labs (HOLs) provided. Basically, you walked up to the HOL computer and, in a few short steps, you had a full development virtual machine ready to go. It was a really nice experience and ensured that you could try out new features without having to set up your own VM or worse, download and install a lot of betas on your own development machine.

Apparently, Microsoft is using the same setup over the web. Maybe I’ve been in the dark for a long time, but I’ve never used a VM in a browser window before. Check the screenshot out:

image

Seriously, look at the browser title – this is in IE. On the right side of the screen, you’ve got the lab walkthrough, too. If you’ve been unable to look at new technology like .NET 3.5, LINQ, WPF, WCF, etc, you should check out Microsoft’s Virtual Labs. The MSDN Virtual Labs are at http://msdn.microsoft.com/en-us/virtuallabs/default.aspx, but TechNet also has labs for things like Windows Server 2008.

image

posted on Wednesday, June 18, 2008 7:01:36 AM (Central Standard Time, UTC-06:00)  #    Comments [2]
 Tuesday, March 18, 2008

I am a huge fan of the immediate window in Visual Studio. I say forget the watch window - I'd rather use code to check values. In case you didn't know, you can get values in the Immediate window by typing "?" and the variable name. Like so:

? myCoolVar

You can also execute commands at the immediate window by just typing them. It is a nice way to change values at debug-time.

myCoolVar = "some other blah"

What I didn't realize until today is that you can create completely new variables at the Immediate window as well! Just type in the variable declaration as you normally would in code. (note that you need the semi-colon in this case)

string myNewCoolVar = "I'm a brand new variable!";

Here's a screenshot of this behavior in action:

image

Right now, I'm using this behavior while working with a new WPF application. I've got an IMultiValueConverter and it is a hassle casting my generic array of objects into types, especially when I'm still deciding on the various bindings I'd like to pass in. With this, I can just set a breakpoint and use the Immediate window to play with the code.

This gets me a lot closer to an interactive console (like IRB) with .NET. Though I can do all of this with IronPython, F#, or IronRuby, it is nice to be able to do this at debug time from Visual Studio.

posted on Tuesday, March 18, 2008 10:53:44 AM (Central Standard Time, UTC-06:00)  #    Comments [2]
 Thursday, January 17, 2008

I couldn't find this information anywhere (yet), so I thought I'd share this. If you're already using the _NT_SYMBOL_PATH setting to download symbols from Microsoft and you want to download the symbols and source for the .NET Framework, you can set the environment variable up like so:

Variable name:
_NT_SYMBOL_PATH

Variable value:
srv*c:\symbols*http://referencesource.microsoft.com/symbols*http://msdl.microsoft.com/download/symbols

Replace "c:\symbols" with whatever path you want your symbols to be downloaded to. The key here is that the reference source path exists first. Otherwise, the PDBs will be downloaded with the source information stripped.

The rest of the settings should match what Shawn Burke shared in his post on the reference source release.

Hope this helps.

posted on Thursday, January 17, 2008 9:33:17 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Friday, January 11, 2008

I absolutely love trying out different Visual Studio color schemes. I've used John Lam's port of Vibrant for a while as well as some of Tomas Restrapo's VS themes and they're all great. After watching this VIM screencast from the Eleutian guys, I decided to give VIM another try. I'm not able to fly with it yet, but I am picking it up a lot better.

One of the things that I absolutely love about VIM as well as E-TextEditor is how it comes preloaded with some great color schemes. Not only that, but both editors are ridiculously easy to pull down new schemes from the internet. I've never really cared for editing the colors in Visual Studio, but I decided that I had to try to port Wombat over to Visual Studio. It is the theme that Aaron is using in the video and it looks great.

Here is what it looks like in VIM:

gvimwombat

Here is what my port looks like:

vswombat

As you can tell, some of the colors don't exactly match up; however, I think it keeps the overall feel and I like it. Try it out and let me know what you think. If you'd like to make some improvements, make them and then send me a copy!

Download my attempt at a Visual Studio Wombat theme (VS2005).
Download my attempt at a Visual Studio Wombat theme (VS2008).

posted on Friday, January 11, 2008 11:36:35 AM (Central Standard Time, UTC-06:00)  #    Comments [3]
 Thursday, December 20, 2007

This is probably a big duh for some of you out there, but if you're running the remote debugger that comes packaged with Visual Studio 2008 (you can find it at C:\program files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger) on a remote machine and you try to attach to that remote machine using Visual Studio 2005, you'll get an error. In fact, VS2005 will tell you that it can't find any servers running on the remote machine. All afternoon yesterday, I was trying to figure out how this one users' security was wrong and keeping me from attaching to a remote debugger he was running when, in fact, I just had an older version of Visual Studio trying to talk to a newer remote debugger.

*sigh*

Maybe now I can figure out what the original problem I was trying to debug was in the first place.

posted on Thursday, December 20, 2007 11:26:36 AM (Central Standard Time, UTC-06:00)  #    Comments [3]
 Tuesday, June 12, 2007

Last night, I installed the Orcas Beta 1 release. Aside from just a couple of issues, the whole process went quite smoothly. One of the issues I had already seen before involving finding the rmt9x.mst file and mounting ISOs. My other issue was with the install speed, but that is when I realized I had mounted the ISO from one drive just to install to another. As a result, I was completely missing out on some of the performance that my 10,000 RPM Raptor drive could provide. To rectify the issue, I mounted the ISO on the drive I was installing to and everything else was great after that.

I haven't really coded in it yet, but the application itself sure seems snappier. I'm talking about toolbar menus and the general responsiveness, which is very nice. Has anyone else noticed an increase in speed for Orcas from 2005?

posted on Tuesday, June 12, 2007 6:54:57 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Tuesday, September 19, 2006

Recently, Microsoft released version 3.0 of the Visual Studio 2005 SDK, so I thought I'd download it because I like downloading stuff.

Anyway, I thought I'd share a nifty tool that came along with it under the Visual Studio SDK Power Toys name (not to be confused with the Power Toys for Visual Studio... I'm confused, too). Here's a screenshot of Source Outliner:

Source Outliner

It acts sort of like the Class View tool window, except that it outlines the currently opened file. It also seems a lot cleaner if you happen to be deep in a namespace hierarchy. Once you have the VS2005 SDK installed, you can access this tool either by selecting Tools -> Power Toys -> Source Outliner or by using the CTRL + \ + O hotkey.

Check it out!

UPDATE: I... uhh... added the link to the download. My mistake on forgetting that :-)

Another update: Don't bother downloading the entire SDK if you're just interested in the Visual Studio SDK Power Toys... you can download them standalone! Check out Aaron Marten's post here!

posted on Tuesday, September 19, 2006 1:27:50 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Thursday, September 07, 2006

When you're creating a GUI control in Visual Studio, your public properties will be displayed in the Property Grid and you can customize this by using attributes such as the Category attribute or the DisplayName attribute. Another nice attribute to use sometimes is the Browsable attribute. If you set the Browsable attribute to false (i.e. <Browsable(False)> in VB.NET), it won't be displayed in the property grid. I typically use this to hide properties that really have no function from the GUI side.

Here's the point of the post though: even if you set a property's Browsable attribute to false, it will still be accessed by the designer. In other words, if you've got code like a Debug.Assert or something in there, it will still fire, regardless of the Browsable attribute's value. So, you might consider putting a DesignMode check around code like that because it will give you some weird behavior when running in the designer.

UPDATE:
No one ever told me about the DesignerSerializationVisibilityAttribute! You can set DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden) on a property and it won't get serialized into code!

posted on Thursday, September 07, 2006 7:53:25 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Thursday, August 31, 2006

Back in January, Gaston Milano posted a sort of wishlist for the next version of Visual Studio. One of the features he wanted was the ability to filter properties down in his Properties window. Here's a screenshot of what he had in mind (from his posting):

Well, I've got great news! Corneliu from his parallelthinking blog has created an addin to do just that! It works by using his Hawkeye application, which is a sort of superpowered Spy++ for .NET. Hawkeye allows you to attach to any running .NET application and inspect various .NET controls and their properties as well as methods, events, and all sorts of other fun things. With Hawkeye, you can even CHANGE properties and INVOKE methods! On the fly! And the other .NET application never even has to know about it!

His VS Properties Extender uses the functionality of Hawkeye to add a text box to the properties window at run time which allows you to filter to commands. It works great, too. Now I'm really curious what other sorts of functionality could be added to an application like Visual Studio by using Hawkeye. Check it out!

(found via Larkware)

posted on Thursday, August 31, 2006 10:57:37 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Tuesday, August 22, 2006
In one of my projects at work, I ran into a situation where Visual Studio 2005 didn't recognize my designer files (i.e. MainForm.Designer.vb) so all of the serialized designer code was getting stuck in a new InitializeComponent in my code file (i.e. MainForm.vb). Of course, because my Designer code was a partial class, I got an error out of it. In my experience, this behavior is sort of obscure, but here is an easy fix.

Open up the project file (which in my case was GUI.vbproj) in a text editor and do a search for your Designer file. You should see some tags that look like this:
<Compile Include="CustomControl.Designer.vb">
</Compile>
<Compile Include="CustomControl.vb">
<SubType>UserControl</SubType>
</Compile>
Now, what it SHOULD look like is this:
<Compile Include="CustomControl.Designer.vb">
<DependentUpon>CustomControl.vb</DependentUpon>
</Compile>
<Compile Include="CustomControl.vb">
<SubType>UserControl</SubType>
</Compile>
I've bolded the important part for you. Basically, my project file, for whatever reason, was missing the <DependentUpon> tag. If you add that back, Visual Studio should start behaving as expected again.
posted on Tuesday, August 22, 2006 3:23:40 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Friday, August 18, 2006
This post is just as much for me as it is to share...

I was attempting to create a automatically resizing GroupBox control that would let users drop controls on it and it would grow as the controls dropped. I also wanted to offer a FlowLayoutPanel-like ability so that it would slide controls that were lower up if higher controls were hidden. Doesn't sound too bad and we would use it enough that it made sense to encapsulate it in a custom control. I started looking into inheriting from GroupBox and adding a FlowLayoutPanel to it's control collection. Then I hooked into the ControlAdded event for the GroupBox so that I could move the control from the GroupBox to the FlowLayoutPanel. I'm just walking you through the steps in my thinking process here... this apparently isn't how it should be done, because though it worked if controls were added at run-time, it gave me a weird designer error that said "'child' is not a child control of this parent" (like these guys did).

What research I came up with looked like I would have to create my own custom designer to support code like this, that would also include code serialization into InitializeComponent. Yay. A little more research brought me this link, though. It details how to drop controls onto a UserControl at design time. It is a slightly different approach, but it provided what I needed. Basically, the solution also involves using a ControlDesigner, but the code seems much less involved than if I were handling code serialization.

Here's a code snippet to give you an idea of what I did:
<Designer(GetType(AutoResizeGroupBoxDesigner))> _
Public Class AutoResizeGroupBox
<DesignerSerializationVisibility(DesignerSerializationVisibility.Content)> _
Public ReadOnly Property FlowPanel() As FlowLayoutPanel
Get
' Where _flowPanel has already been added to the designer
Return _flowPanel
End Get
End Property

' code snipped...

End Class

Public Class AutoResizeGroupBoxDesigner
Inherits ControlDesigner
Public Overrides Sub Initialize(ByVal component As System.ComponentModel.IComponent)
MyBase.Initialize(component)
Dim autoGroupBox As AutoResizeGroupBox = DirectCast(component, AutoResizeGroupBox)
EnableDesignMode(autoGroupBox.FlowPanel, "FlowPanel")
End Sub
End Class
posted on Friday, August 18, 2006 6:58:52 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Thursday, July 20, 2006
Like many other users of Visual Studio 2005, I've occasionally received the WSoD (White Screen of Death) while using the designer. And like a typical user, I blamed it on Visual Studio. That's what users do, right? They blame the program, because the user is always right. The same behavior that frustrates me to no end when users enter invalid data into MY program and then blame MY program (of course, if my UI were better, it wouldn't be as difficult to use, but that is another story). Anyway, my frustrations with VS2005 crashing and the WSoD's were in fact a problem with the user - me.

In one of my forms, I had some background threading work that was started when the form loaded. Like a good programmer, I had wrapped this threading work in a check against Me.DesignMode to ensure that it wouldn't try to do this work while in the designer. What I didn't know at the time is that the DesignMode property isn't set until AFTER the constructor fires. I checked around with some guys at work and I discovered that I wasn't the first one to discover this. They had already put a check against Application.ExecutablePath to see if it was devenv.exe. If it is, then we're in DesignMode. Simple as that!

So, all of my VS crashes and weird WSoD's have now been tracked back to my OWN code. HOWEVER, I would like to say that it would have been nice if Visual Studio had given me a better message to inform me that my designer code was trying to run background threads or something - in much the same way that my own code should work better and give my users better messages.

Ah, the joys of user interaction.

Note: This fixed the problem suggested after sending error reports that link to this hotfix (http://support.microsoft.com/?kbid=915038). If you're running into this, check and double-check the code in your UI constructors, INCLUDING base class constructors!
posted on Thursday, July 20, 2006 10:22:10 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Thursday, June 15, 2006

We were working with partial classes recently at work and we came up with a best practice usage for naming them, at lease for our needs, and I thought I would share it with you.

Basically, do it the way Visual Studio does. For example, with GUI components such as forms, VS2005 names the main class Form1.vb, while it names the partial class Form1.designer.vb. So, if you want to make your Shipment class have a partial piece, have a file that is Shipper.vb and Shipper.stuff.vb.

This way, it is clear by the naming that the files are related. Otherwise, I would think there would be a lot of confusion on how the files are related.

Any thoughts on this?

posted on Thursday, June 15, 2006 11:44:28 AM (Central Standard Time, UTC-06:00)  #    Comments [1]
 Thursday, May 11, 2006

Prompted primarily by Karl Sequin's excellent "Understanding and Using Exceptions" post, I was recently attempting to clean up some of the generic exceptions being throw in some code and I was having trouble deciding which exception to use.

I had a BackgroundWorker that could potentially throw an exception (can't everything?) that was doing some remoting to another process. As additional information, the BackgroundWorker exposes any exceptions that might occur in the Error property off of the RunWorkerCompletedEventArgs. I didn't want to just throw e.Error because, as Karl points out, this modifies the call stack making it look my code was the source of the exception. At the same time, I couldn't just use throw, because the exception had basically already been caught and been given to me to handle.

I ended up pulling up the Object Browser in Visual Studio and filtered the list down by searching on "exception" - a nice trick to see all currently accessible exceptions. I ended up using the System.Runtime.Remoting.RemotingException, because it described exactly what I was looking at. Here's the description for it:

Public Class RemotingException

          Inherits System.SystemException

     Member of: System.Runtime.Remoting

Summary:

The exception that is thrown when something has gone wrong during remoting.

If you exclude the "during remoting" part, it basically describes any exception that can be thrown. It's almost funny in a way, because that's exactly the type of thing I was looking for. I was able to set the InnerException to my e.Error which provided me with all the information I needed.

posted on Thursday, May 11, 2006 8:27:20 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Monday, May 01, 2006
I wanted to share an experience I had last week while working with my development team. I think I've mentioned this before, but we're the first group in my company to move to .NET 2.0. As a result, we're also the first to get to really use Visual Studio 2005. We had been working on mockups and UI designs with our users for quite a while on this project.

Finally, we were getting ready to start work on the internals. The three of us met in a conference room with a projector and I pulled up the Class Designer in Visual Studio. I've done team-coding a few times before, where one person is typing while everyone else is yelling out bugs or typos. While the process can be annoying, it also tends to produce less-buggy code. Doing the same thing with the Class Designer worked out really well. It helped us visualize how everything would tie together. We were drawing out our code, but behind the scenes, the Class Designer was also spitting out workable code!

I don't think I could use the Class Designer in all cases, but it really does force you to think about design issues and it makes for a good team development product. It also helps ease developers who aren't as comfortable with OO concepts see how inheritance is working. Give it a try and let me know how it works for you.
posted on Monday, May 01, 2006 11:36:56 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Friday, April 21, 2006
Continuing in the tradition of posts on Visual Studio WSoD's, I ran into another one today that gave me this error: "Object does not match target type."

Okay... super.

Luckily, I got some warnings with line numbers. They pointed me to a line in my designer code that looked like this:

CType(Me.MyUserControlInstance, System.ComponentModel.ISupportInitialize).BeginInit()

The other error was the same line except it was the matching EndInit call.

Similar to before, I was working with code that was in the process of being updated to the .NET 2.0 Framework. I had been working with a control that was inheriting from a .NET 1.1 control. The ISupportInitialize code had been in there for the 1.1 parent. The designer didn't mind at all until I moved the parent control over to 2.0. The solution was easy enough... just take the ISupportInitialize code out. I'm not sure if this is the recommended solution or not (I didn't Google it for too long), but it works.
posted on Friday, April 21, 2006 2:34:20 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Friday, April 14, 2006

Ever seen this error in Visual Studio 2005?

I've seen it all too often and it is really annoying.

However, I did find a possible fix today. I was working in a project that had multiple assembly references. One of the references was using a 1.1 assembly, so it came along for the ride. By simply removing that reference, I was able to view my form without any problems. If I tried to add the reference back, I would get the designer error again. I reworked the assembly being referenced to not use any 1.1 components and... lo and behold... the designer errors stopped.

Is this just a really random bug or is this a subtle way to push people to migrate to .NET 2.0?

posted on Friday, April 14, 2006 2:09:51 PM (Central Standard Time, UTC-06:00)  #    Comments [3]
 Tuesday, April 11, 2006

MSBuild is a great tool. If you're not familiar with it, it is Microsoft's new build engine which was released with .NET 2.0. Visual Studio 2005 uses it behind the scenes. If you'd like to see it in action, pull up a VS2005 Command Prompt and type "msbuild YourSolution.sln" and watch the magic. It provides a much faster way of recompiling solutions and projects than reopening Visual Studio.

MSBuild runs off XML files. If you'd like to see one, just open up one of your vbproj or csproj files. Visual Studio projects default to the MSBuild format. Unfortunately, the solution files still aren't in an XML format. Because it uses XML, you can extend a build to do any number of tasks. I'll walk you through a very simple example.

My task is a Replace task that simple takes an input string (likely a file path or assembly name), an old value, and a new value and returns a value with all old values replaced with new values. It works exactly like the Replace method off of String objects.

First off, create a new Class Library project in Visual Studio. You'll need to add a reference to Microsoft.Build.Framework and to Microsoft.Build.Utilities. Next, for your class, inherit from Microsoft.Build.Utilities.Task. You'll be forced to override an Execute method. That's really all it takes to get a custom task. Everything else is driven off of public properties that are described by specific MSBuild attributes like "Required" or "Output".

Here's the source for my Replace task:

using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

using System;
using System.Collections.Generic;
using System.Text;

namespace Tasks
{
    
/// <summary>
    /// Custom MSBuild task to perform String replacement. Primarily used for
    
/// Namespace to directory replacement (DTC.NRA.App -> DTC\NRA\App).
    
/// </summary>
    public class Replace : Task
    {
        
string _input;
        [
Required]
        
public string Input
        {
            
get { return _input; }
            
set { _input = value; }
        }

        
string _oldValue;
        [
Required]
        
public string OldValue
        {
            
get { return _oldValue; }
            
set { _oldValue = value; }
        }

        
string _newValue;
        [
Required]
        
public string NewValue
        {
            
get { return _newValue; }
            
set { _newValue = value; }
        }

        
string _results;
        [
Output]
        
public string Results
        {
            
get { return _results; }
            
set { _results = value; }
        }

        
public override bool Execute()
        {
            
bool success = true;
            
try
            {
                Results = Input.Replace(OldValue, NewValue);
            }
            
catch (Exception e)
            {
                Log.LogErrorFromException(e);
            }
            
return success;
        }
    }
}

The XML below is how I'm currently using this task.

<UsingTask TaskName="Tasks.Replace" AssemblyFile="C:\Development\References\MSBuildTasks.dll" />
<
PropertyGroup>
  <
RootDirectory>C:\Development\Build\</RootDirectory>
</
PropertyGroup>
<
Target Name="AfterBuild">
  <
Replace Input="$(RootNamespace)" OldValue="." NewValue="\">
    <
Output TaskParameter="Results" PropertyName="NamespaceDirectories" />
  </
Replace>
  <
CreateItem Include="$(OutputPath)\**\*.*">
    <
Output TaskParameter="Include" ItemName="FilesToArchive" />
  </
CreateItem>
  <
Copy SourceFiles="@(FilesToArchive)" DestinationFolder="$(RootDirectory)$(NamespaceDirectories)\%(FilesToArchive.RecursiveDir)" />
</
Target>

As you can see, I've got the UsingTask which references the assembly I built. Then you can use the Replace task like any other provided task. The above exactly can be copied into a Visual Studio project and it will copy the output files from your build into the RootDirectory you specify with the root namespace making up the folders beneath it (i.e. give the namespace System.Windows.Forms, this will copy your compiled assemblies to c:\Development\Build\System\Windows\Forms\*).

posted on Tuesday, April 11, 2006 11:43:25 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Friday, March 31, 2006

Yesterday afternoon, I posted on ShellExecuteEx and executing files with unknown file extensions. I was really confused, though, because my feed just wouldn't show up in my aggregator (RSS Bandit). I knew it wasn't my reader, though, because I had navigated to my feed's address (http://feeds.feedburner.com/DavidMohundro) and it wasn't displaying my added post. I threw a few test posts out there but nothing would show up. I'll admit, I couldn't help but wonder if something had happened with FeedBurner. I shouldn't have doubted, though. It was indirectly my fault.

You see, FeedBurner has a nice report called FeedMedic (located under their Troubleshootize tab). I hadn't found that report until this afternoon. It informed me that my source feed was too large.

Wha???

Apparently, my last post on file extensions was too big. I ended up editing the last post and taking out a lot of the unnecessary HTML that came out of my code to HTML addin. I ended up using Jeff Atwood's great FormatToHtml VS2005 macro. The HTML it generates is a lot simpler, but also a lot cleaner. That solution alone dropped my post under the "large" size. Now everyone can happily see my posts again!

posted on Friday, March 31, 2006 5:04:26 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Friday, March 17, 2006
First thing - jfo's coding is a great blog. I regularly find her posts very helpful and relevant to what I'm working on.  If you're not already reading her blog, you should check it out.

Second, as she says, tracepoints ARE awesome. I had used a few of the new breakpoint features in VS2005 such as Condition and Hit Count, but I seen the "When Hit..." option yet. All I can say is, you can say goodbye to Debug.WriteLine'ing (aka "the poor man's debugger"*).

* If you're unfamiliar with "the poor man's debugger," it is basically using output statements to determine values and flow of code. If used correctly, it can actually be very useful. It just isn't fun to remove all of that code after you're done debugging (particularly the Response.Write variety in webpages... ouch).
posted on Friday, March 17, 2006 9:09:17 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Thursday, March 16, 2006

A few days ago, I was working in Visual Studio 2005 and I was getting awful performance out of it. I decided to pull up Process Explorer to see if I could determine where the problem was. I right-clicked on devenv.exe and pulled up its properties and went to the .NET tab. You can then use the combo box to select different .NET performance measures. Here's what I found:

As you can see with my hastily scribbled red circle and arrow, I'm attempting to draw your attention to the 65.94 number. It is telling me that devenv.exe was spending about 66% of its time in doing garbage collection.

WHAT?!? 66%? That explains why my process was barely responding to me, but it doesn't tell me why it was doing that. I will say that I had a code file up that was about 7000 lines long, but I would still expect it to be able to handle that. Maybe I'm wrong, though. Since then, I've significantly cut that file down in size and I haven't run into that issue again, but it was pretty weird.

posted on Thursday, March 16, 2006 7:48:50 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Wednesday, March 08, 2006

I've blogged about the FlowLayoutPanel in the past. It is a highly useful control in certain circumstances, but it doesn't behave as expected a lot of the time. In trying to better explain how it works, I created a small test program to show what it is doing. Here is what it looks like:

It primarily demonstrates how FlowDirection and WrapContents affect controls in the FlowLayoutPanel, particularly dynamically added controls. If you click one of the dynamically added buttons, it will pull up that buttons PropertyGrid, which will allow you to edit its properties. This is useful to examine the effects of sizing, anchoring, and docking.

Here's the link to the VS2005 solution if you're interested in playing around with it. It's in C#. I wanted to play around with anonymous delegates :-)

posted on Wednesday, March 08, 2006 8:33:27 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Wednesday, January 18, 2006
I was curious if anyone knew if Visual Studio 2005 had the capability to highlight or color "User Types" (i.e. classes you write yourself) while coding in Visual Basic. I know that C# has this functionality built in, but it doesn't seem like VB pays any heed to those settings. Here's a screenshot of the specific setting in Visual Studio:



If anyone knows anything about getting that working for VB, I'd appreciate it.

posted on Wednesday, January 18, 2006 1:04:46 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Thursday, January 12, 2006

After some severe frustration research, I was able to discover how to repro the crash in Visual Studio 2005 yesterday. It is actually quite simple to do. You need a new VB.NET project and two With statements, one nested within the other. That's it. Then you click on the second With object.

Here, I'll show you how!

Public Class Form1

    Public Shared Sub Main()

        Application.Run(New Form1)

    End Sub

 

    Public Sub New()

        ' This call is required by the Windows Form Designer.

        InitializeComponent()

 

        ' Add any initialization after the InitializeComponent() call.

        Dim p As New Person()

        With p

            ' CRASHHERE: If you want to crash, take your mouse and

            ' click inside .StreetAddress.... BOOM!

            With .StreetAddress

                .Street = "123 BOOM"

            End With

        End With

    End Sub

 

    Public Class Person

        Private _streetAddress As New Address

        Public ReadOnly Property StreetAddress() As Address

            Get

                Return _streetAddress

            End Get

        End Property

    End Class

 

    Public Class Address

        Private _street As String

        Public Property Street() As String

            Get

                Return _street

            End Get

            Set(ByVal value As String)

                _street = value

            End Set

        End Property

    End Class

End Class

 

There, that was easy, huh? (In case you're not seeing it, look for the CRASHHERE note.)

Kids, don't try this at home.

Chances are, it will work for you anyway. I just checked with one of my co-workers and it works just fine for him. Great.

posted on Thursday, January 12, 2006 8:07:54 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Wednesday, January 11, 2006

5+ crashes in a row is a little much.

And I wasn't even in the designer. And yes, I rebooted. It still happened.

I don't know exactly what I did to fix it, though. Let's just say heavy use of the save button and having another instance of devenv up and attached to the other process. Just in case I needed to copy and paste a call stack somewhere. Of course, that's when it began working.

Oh well.

NOTE: Don't take this the wrong way. I still love VS2005 as an IDE. However, it still has quite a few issues. The most annoying of which is the flickering while in the designer. And no, I never got that one up in the debugger either.

UPDATE: For more information on this, see my new post here.

posted on Wednesday, January 11, 2006 2:50:25 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Wednesday, January 04, 2006

I ran into that error today while attempting to install Infragistics NetAdvantage 2005. I'm not exactly sure about why the error occurred, but I was able to find a fix here (via this MSDN forum thread). Some of the other solutions appear to be reinstalling VS2005, but luckily, the registry fixes from Chetan's blog worked fine.

posted on Wednesday, January 04, 2006 4:47:57 PM (Central Standard Time, UTC-06:00)  #    Comments [0]

Has anyone noticed a new menu item under the Build menu in Visual Studio 2005? There is a Clean Solution item that will remove all of the compiled binaries that live under your bin folder. It is relatively similar to