I’m a few weeks into a side project that I blogged about in a previous post. I’m having a lot of fun (I’m such a geek) using a bunch of new stuff. Since Visual Studio 11 is at the center of all the work on the project, I thought I’d share my first impressions on it. Of course, I’m using a Beta version of it. Really this post is about my second thoughts since they are much more meaningful. Spoiler alert: First impressions aren’t always the most important.

My first thoughts

My first thoughts were pretty typical and can be summarized with one bullet:

  • Colorless

That is pretty much what most people think when they see it for the first time. People tend to ignore all of the improvements and new features and focus on the lack of color. At first I found this lack of color to be somewhat distracting which is odd because it is meant to have the opposite effect. I’ll be honest, I wasn’t thrilled with the new look but I was quick to point out to some of my peers that we should give it some time and get used to it.

My Second Thoughts

Guess what? I got used to it… quickly. After using Visual Studio 11 for a couple of hours, I quickly got used to the lack of color. It isn’t really that big a deal and I think the VS team was on the right track by moving Visual Studio overall to the background and making the code editor the focal point. Having said that, I still think some color would be helpful. My last point on the overall lack of color is that it isn’t 100% consistent. Some windows within VS11 still have color. And some plugins use color too. That makes things a bit odd. I’m including a screenshot below. That’s all for the color.

image

Some features to note (this is by no means a comprehensive list, just some highlights):

So far, I think VS11 is an awesome development environment. I’ve been doing MVC development within VS11 and the HTML, CSS, and JavaScript support is really nice. VS11 is now providing a lot of help for developers working in these areas. I’ll also point out that I am using ReSharper (v7 EAP for VS11). I love ReSharper! Between VS11 and ReSharper, the web development experience is awesome. I’ll be honest, I don’t always know which tool is providing the various features!

When developing web apps, we typically want to run/debug/test them in a variety of browsers. It seems like Microsoft has figured out the IE is not the only browser in town. So now we can use the Debug Target toolbar button. Just click the typical “play” button or hit F5 to debug in which ever browser is selected: image Or you can use the drop down to chose a different target or change the default:

image

I like the fact that the great features of the Solution Navigator (previously part of the Productivity Power Tools) were combined into the Solution Explorer. Of course, the Add Reference dialog is a huge improvement from the past, that was also a feature from the Power Tools.

I’m also a huge fan in the reduction of items in the toolbars. I think the VS team really nailed that part of the design as well. They took out all but the most commonly used buttons from the toolbar – but only in the default configuration. If there is a button or toolbar you like, just add it back in. That part is easy! More importantly, we should all get used to the Quick Launch feature. With that, we can just type the name of any command we want. No more hunting around in the menus for seldom used actions!

Another great feature is the Preview Tab. I’m surprised more people aren’t talking about this one. This is pretty cool but I don’t think you can get the full value of it until you experience it yourself. Think about all those times you are debugging and you end up stepping into file after file after file. All those files get opened up in the tab well. Eventually you get to the file you want in the debug process. But when you are done you have a ton of open files. Not everyone is like me, but I hate open files. I want my tab well to be as empty as possible. Preview Tab to the rescue! With VS11, all of those files that you step through don’t open up as normal files, they open in the Preview Tab. But Preview Tab only has one file at a time. So each new file you step into replaces the old one and your environment stays clutter free. And Preview Tab is pretty smart too. If you make a change to the file it moves it into the normal tab well. You can also click a button in the tab to “promote” the file to be a normally opened file. In this image you can see the Preview Tab on the right, circled in blue.

image


While it isn’t really new, I want to mention that the extensibility features of VS11 (and 2010 too) are really powerful and work so well and somewhat seamlessly. The Extension Manager is really cool and with it I’m always adding tools to Visual Studio. There are loads of great things to install. With VS2010 I hadn’t gotten to experience Nuget but with the work I’m doing now in VS11 I am all over it. Nuget (or is it NuGet, or nuget?) is providing all kinds of good stuff for my solution. Between VS11, the extensions and nuget packages, I really feel empowered to create great solutions.

There are lots of other great features, these are just the ones that came to mind as I was writing. Download the Beta and check it out for yourself!

A lot of new stuff has been coming out from Microsoft lately. Couple that with all the cool open source projects available for use and a developer can quickly get left behind from all the new technology. I try to stay pretty current but there is some new stuff that I’ve been wanting to use. I also wanted to brush up on some old skills and even use some of the technologies I am experienced with in new ways. I decided it was time to start a little project for myself. I’m often asked by developers about how they can gain experience with new technology (or even old tech that is new to them). My advice is that they should just write an application that uses the technology. As a hiring manager, I’ll give serious consideration to that kind of experience, provided it isn’t “hello world”. When I write an application like this, I treat it like a real world production project. And if you are creating a web application you can have it hosted and then it IS a real product. That should count as experience to a smart hiring manager. So when you write these applications, try to follow all of the best practices, use good standards, etc.

In my case, I am writing an application that I hope will actually get some use. I’m hoping to get some great blogging material out of this as well. I already have, but now I need to find time to write about it. Anyway, figure out what you want to build and then create a list of the things you want to learn. As you write the application, you can just keep adding other technologies, frameworks or patterns in along the way.

Here is my list of things I’m using or will be using in my new pet project. Obviously the beta stuff is brand new. And I’ve already got experience with MVC 2 (pre-Razor), jQuery, HTML, CSS, etc. However, this stuff gets better and better all the time and I like to stay on top of it. Working a few hours here and there for the past 2 weeks, I’ve already included all of the items in blue in my project.

  • Visual Studio 11 (beta)
  • Entity Framework 5 (beta)
  • Entity Framework Code First
  • Entity Framework Migrations
  • ASP.Net MVC 4
  • Razor
  • HTML 5
  • jQuery
  • jQuery UI
  • Git
  • Open Authentication
  • CSS3 & Media Queries
  • HTML/CSS Grid Systems
  • NuGet
  • SEO Toolkit (Microsoft)
  • C# 4.5 (including Async)
  • SignalR
  • Azure
  • ASP.Net Web API
  • BootStrap (from Twitter)
  • Facebook Integration
  • Of course, Dependency Injection, Unit Testing, and all of the other stuff I put into any app I am deploying.

I’m writing this as a web application and creating a mobile version at the same time. In addition, I plan to extend this to additional platforms. So my list continues:

  • Mobile Web
  • WP7
  • Metro (Windows 8)

I love working with other developers, whether it be formal “paired programming” or just one person helping the other with a problem.  I love it so much because I always learn something new.  Sometimes what I learn is some major, powerful technique for doing something complicated but usually it is not.  Usually it is one of those simple, cool, helpful tidbits.  You probably know what I mean.  You sit with a coworker and without any fanfare they type some keystroke and you say, “Whoa, I didn’t know you could do that… how did you do that?”  Here’s an example of something I do that I’ve noticed many developers aren’t aware of. It’s nothing fancy, but I find it helpful.

Like many developers, I like to surround my code in collapsible regions.  I don’t get too carried away with this technique, but I usually have a region for Public Properties, another for Public Methods, maybe one for Class Level variables.  Stuff like that.  Anyway, most people label the top of the region but I’ve found that many developers don’t know you can label the bottom.  That extra label on the bottom is really helpful when you are scrolled down far.  Without the label, you find an #endregion and you don’t know what region it is the end of.  This is especially tricky when working with nested tags.  How do you do it?  Just type the label :).

#endregion with label:
#region Public Methods
// put stuff here...
#endregion Public Methods

I think the reason people don’t do this more is that (I’m pretty sure) you could NOT do this with some earlier version of Visual Studio.  Those of us that have worked with VS for a long time just got used to doing #endregions without the label.  Back then I used to put a comment at the end of my region like this, but it isn’t necessary anymore:

#region Public Methods
// put stuff here...
#endregion //Public Methods

But at some point, maybe VS2008, we were allowed to just put the label at the end. 

But wait, there’s more…

Recently I had the idea to update the code snippet for “Surround with Region”.  You can use this built in Visual Studio snippet by highlighting some code and hitting “Ctrl + s”, then select #region from the dropdown.  When you do, your code is automatically surrounded by the #region and #endregion, plus you’ll be prompted for the text for the label.  I tweaked it so it puts the label at the beginning and the end. 

  • You can find your snippets by going to the Code Snippets Manager (Tools > Code Snippets Manager, or Ctrl + k, Ctrl + b).
  • Then select Visual C# (or VB I guess, I don’t use it :) )
  • When you click on the folder or the name of the snippet, the path is shown in the window.  See the screen shot below…
  • In my case, and I think it is pretty standard, I open the snippet in Notepad at the following path: C:\Program Files\Microsoft Visual Studio 10.0\VC#\Snippets\1033\Visual C#\pp_region.snippet
  • Then change the snippet and use the XML listed below.
  • The only thing I changed was the 24th line.  After “#endregion” I put in the $name$ variable.  The variable was already used in the snippet on line 22 so it was easy. 
  • Note: If you can’t save this snippet with notepad, make sure Visual Studio is closed and run notepad “as administrator”.
Snippet XML:

<?xml version="1.0" encoding="utf-8" ?>

<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">

    <CodeSnippet Format="1.0.0">

        <Header>

            <Title>#region</Title>

            <Shortcut>#region</Shortcut>

            <Description>Code snippet for #region</Description>

            <Author>Microsoft Corporation</Author>

            <SnippetTypes>

                <SnippetType>Expansion</SnippetType>

                <SnippetType>SurroundsWith</SnippetType>

            </SnippetTypes>

        </Header>

        <Snippet>

            <Declarations>

                <Literal>

                    <ID>name</ID>

                    <ToolTip>Region name</ToolTip>

                    <Default>MyRegion</Default>

                </Literal>

            </Declarations>

            <Code Language="csharp"><![CDATA[#region $name$

        $selected$ $end$

    #endregion $name$]]>

            </Code>

        </Snippet>

    </CodeSnippet>

</CodeSnippets>

Code Snippets Manager:

image

Code Snippets are really cool and easy to use.  For more information, please see this post.

There seems to be a bug in Visual Studio 2010 when adding references to Silverlight projects.  You can add “regular” .Net references just fine using the add reference dialog.  However if you use the browse feature to find a reference in an “unusual” location, Visual Studio is supposed to record that location along with the reference in the .csproj file.  It includes the location via the HintPath property.

At my company, we use build machines and we don’t like to install a lot of software on them.  So in source control we have a folder (assets\lib) that includes all of the necessary .dll files that we need to build or projects.  When we add references to our project, like for a Silverlight control library, we add it from the assets\lib\Silverlight folder, even though that library is installed on my local machine.  Anyway, when I tried doing this in Visual Studio 2010 (I’m upgrading our existing 2008 solution), VS 2010 isn’t including the HintPath.  If you aren’t careful, you may not realize this is happening.  That’s because since the library is installed on my machine, the build works just fine, except it pulls the .dll from the wrong place.  If I were to try this build from my build server, it would fail though. 

Anyway, here is the workaround.  It’s a pain but it works…

  1. Add your references as you would normally do it via Visual Studio.
  2. Right click the project file in the Solution Explorer and choose Unload Project.
  3. Once the project is unloaded, right click again and chose edit.  This will open the file, and xml document, in Visual Studio.
  4. Find the incorrect reference in the file and edit it manually.  You’ll need to make it look something like this:
    <Reference Include="System.Windows.Controls, Version=2.0.5.0, Culture=neutral, 
    PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
    " > <HintPath>..\..\..\Assets\lib\Silverlight\System.Windows.Controls.dll</HintPath> </Reference>

  5. Save the file and close it.
  6. Reload the project.

When you are done you can verify that it works.  Here’s how…

  1. In Visual Studio, choose Tools > Options.
  2. Find the Projects and Solutions section and select Build and Run.
  3. In the section “MsBuild Project build output verbosity”, select “Detailed”.
  4. Now build your project.  When you do so, you’ll see a lot of details of what goes on in the Output Window.  You’ll need to find the output that relates to the file that you specified, in my case it is System.Windows.Controls and the important output looks like this:

    Primary reference "System.Windows.Controls, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".

          Resolved file path is "C:\Projects\MC\BackOffice\UI\branches\2010Migration\Assets\lib\Silverlight\System.Windows.Controls.dll".

          Reference found at search path location "{HintPathFromItem}".

  5. You will note that it tells you specifically which path was used to resolve the reference!  And if you are so lazy that you don’t want to read the entire path used, you see that it says the reference was found at the search path location “{HintPathFromItem}”.  That means it used the path you specified.

I hope this helps!  Good luck and let’s hope they fix this bug soon.

Code snippets are a great time saver and they are pretty simple to create.  Any time you find yourself typing the same thing over and over again, you may want to consider creating your own code snippet to make life easier.

Here’s an example… I was recently working on a large refactor of some error handling code for a user interface.  Basically, I went from form to form, refactoring the way the error handling was implemented and then test it.  How did I test it?  By throwing exceptions in my code.  Doing so is pretty easy, just find the portion of code that needs to be tested and type “throw new Exception(“This is a test”);”  Plus, for good measure and safety I’d add this above it: “//TODO – Don’t forget remove this test code”

//TODO:  Don't forget to remove this test code:
throw new Exception("This is a test");

Sure, it is easy enough to type but it got old pretty quick and I decided to create a simple snippet.  Once I did, all I needed to type was “tne” (it stands for “Throw New Exception) and hit “tab” twice (hitting “Tab” twice tells Visual Studio to use the code snippet based on what you just typed).  Sounds cool huh?  Ok so here is how you create a simple code snippet…

Snippets are stored in XML files on your pc.  To create a new one, it is easiest to just start with an existing snippet and modify the xml to meet your needs.  Here is an example of the one I am using:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Throw new Exception</Title>
      <Shortcut>tne</Shortcut>
      <Description>This will generate code to throw a new Exception</Description>
      <Author>Andy Schwam</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Code Language="csharp">
        <![CDATA[    //TODO: Remove this test code:
        throw new Exception("An Exception has been thrown"); $end$]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

If you want to use your own snippet, just change the Title, Shortcut, Description and Author elements.  And of course, you need to put your snippet inside of the CDATA area of the the Code Element.

Next, you just need to save this file in a place where Visual Studio will pick it up.  To tell VS2008 where to look for it, go to Tools > Code Snippets Manager.  Make sure you select the correct language in the drop down, otherwise Visual Studio can’t connect your snippet to the language you meant it for.  You’ll also notice the existing folders for snippets.  That may give you an idea of where you should store your own snippets ;).

You can also write more complex snippets that allows you to use the snippet and then type in values that get used within the snippet.  For instance, I do a lot of work with Silverlight and for databinding my public variables must implement INotifyPropertyChanged.  Instead of manually typing a property that does so, plus a backing variable, I use a snippet with the shortcut “npc”.  In the sample below, you will see the words TYPE, PROPERTY and FIELD highlighted in Green.  Those are placeholders and when I utilize the code snippet, VS will prompt me to replace those values.  So if I want to create a public property and backing variable for a string FirstName, I just type the following:  “npc” TAB TAB “string” TAB “FirstName” TAB “_firstName” (but don’t type the quotes!).  It may seem weird at first but makes coding much easier.

private TYPE FIELD; 

image

Here is the XML for my “NotifyPropertyChanged” snippet:

<?xml version="1.0" encoding="utf-8" ?>

<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Notify Property Changed Property</Title>
      <Shortcut>npc</Shortcut>
      <Description>Code snippet for creating a property with a backing variable that calls NotifyPropertyChanged</Description>
      <Author>Andy Schwam</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>type</ID>
          <ToolTip>The Type for the Property</ToolTip>
          <Default>TYPE</Default>
        </Literal>
    <Literal>
          <ID>fieldname</ID>
          <ToolTip>The Type for the field</ToolTip>
          <Default>FIELD</Default>
        </Literal>
    <Literal>
          <ID>propertyname</ID>
          <ToolTip>Parameter name</ToolTip>
          <Default>PROPERTY</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[
    public $type$ $propertyname$ {
    get { return $fieldname$; } 
    set 
    { 
    if ($fieldname$ != value) 
    { $fieldname$ = value; 
    NotifyPropertyChanged("$propertyname$");
    }
    }
    }
    private $type$ $fieldname$; 
    $end$]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Unfortunately, there isn’t a Code Snippet Editor included in VS.  There is some kind of plug-in available for creating VB snippets but I’ve never used it.  I’m sure you can find it with your favorite search engine.  Still it is pretty easy to write these yourself.