Tag Archives: vs2012

VS2012 Achievements Failure

I’m not sure exactly how long I’ve had this problem, but Visual Studio 2012 would crash every time I tried to build a solution that contained a Wix project. My workaround was simple: unload the Wix project or use Visual Studio 2010. It was more of an annoyance than a work-preventer, so I didn’t really worry about it. Yesterday, I thought I’d try to figure it out.

At first, I didn’t really have much to go on. I had some exceptions that showed up in the Event Viewer, but the internet didn’t seem to pick up on any correlation between Wix, VS2012, and the exceptions. I also asked our resident install guy/Wix expert if he’d run into this or heard about it from other developers. He hadn’t. He did some googling and gave me a few results related to the .NET Reflector plug-in, but I didn’t have that installed.

Eventually, I ended up on this forum post. The first comment made me feel pretty dumb:

Did more debugging using the vs2012 log: the WiX installer project triggers an exception in the vs extension “Visual Studio Achievements For VS 2012” published by Microsoft.

Ugh, really? The Visual Studio Achievements extension? It’s so irritating to discover that this gimmicky plug-in causes Visual Studio to completely crash and die when building a Wix project! I disabled the extension, restarted Visual Studio, and I was able to build Wix projects. I liked getting random achievements from time to time, but after this, I’m out. Have a good life, Visual Studio Achievements.

Advertisements

VS2012 Debugger Jumping Around For VS2010 Unit Tests

One of the big selling points for Visual Studio 2012 to early adopters is that you can work seamlessly with Visual Studio 2010 projects and 2010 users. I’ve found this to be largely true and have only run into one significant problem. It’s related to debugging unit tests, and it’s a real head-scratcher. The symptom is that everything is hunky-dory in VS2010: you hit breakpoints, step through code, and everything works just like you’d expect. However, you get consistent weirdness in VS2012. You’ll stop on a breakpoint and try to step over a single line of code, but it’ll jump two lines ahead. The contents of variables will be inconsistent between the code and the next line to be executed. It’s really confusing.

From what I can gather from this forum post (you might want to skip to the bottom for solutions), the problem is due to how VS2010 instruments assemblies to measure code coverage. The solution that I found to work was to manually edit and remove the AgentRule section from the local.testsettings file.

I suspect the problem could also be solved by disabling code coverage from within VS2010 and then re-enabling it in VS2012. One of my favorite things about VS2012 is that you don’t need to manually instrument an assembly to analyze code coverage. Since VS2010 does need this, there is a special setting in vs2012 that can be enabled to maintain backward compatibility.

VS2012_CodeCoverageFor2010

So, just to recap, I suggest the following two solutions if you’re getting debugger jump-arounds while debugging VS2010 unit tests in VS2012:

  1. In Visual Studio 2010, disable code coverage. Then, in Visual Studio 2012, enable the Code Coverage (Visual Studio 2010) setting and select the assemblies to instrument.
  2. If solution #1 fails, edit your .testsettings file manually and remove the AgentRule section.

For either of the solutions above, be sure to clean your output directory. Make sure to get rid of all DLLs and PDBs.

Unit Test Debug Wonkiness in Visual Studio 2012

Our team has started rolling out Visual Studio 2012, and it’s been largely issue-free. In fact, the only issue that we’ve run into is a weird one: the debugger gets screwed up while debugging unit tests. What I mean by “messed up” is that you step over a line, and it jumps down several lines, variables don’t get set; you know, wonkiness!

Luckily, we were able to find this MSDN forum post, which describes our problem and how to solve it.

The problem seems to be related to the solution test settings file. The solutions presented in the forum are to remove the old test settings file or to remove the AgentRule section from the file. We tried these, and it worked for us, too.

Looking a little deeper, we found that the issue occurred when debugging unit tests–running them worked fine–in VS2012 for a solution created in VS2010 with code coverage enabled. Even with all that, the issue did not occur regularly. It worked fine on my machine, but not on my colleague’s. We removed the old test settings file but re-enabled code coverage 2010-style from within 2012 to maintain backward compatibility.

From the same forum post, there is a link to the issue on Microsoft Connect, but the issue has been “deferred” by Microsoft’s development team.

Xsd2Code in Visual Studio 2012

At the time of writing this, Xsd2Code does not install nicely in VS2012. It’s easy enough to “copy” your install from VS2010, though. Here’s a summarized version of adrianot75’s solution.

  1. Copy Xsd2Code.Addin.Addin from the VS2010 Addins directory to the VS2012 Addins
    • From: %UserProfile%\My Documents\Visual Studio 2010\Addins
    • To: %UserProfile%\My Documents\Visual Studio 2012\Addins
  2. Edit the Addin file to include an extra element for version 11.0
    <HostApplication>
      <Name>Microsoft Visual Studio</Name>
      <Version>11.0</Version>
    </HostApplication>
    

Regular Expression Searching in Visual Studio 2012

One of the recurring themes throughout the enhancements made in Visual Studio 2012 is improved searching. There are search boxes everywhere: in the title bar, in Solution Explorer, in Test Explorer… Everywhere!

In addition to making searches more accessible, they’ve also improved and simplified support for regular expressions. Regular expression searching is something that seemed like it existed in earlier version of Visual Studio, but they used their own, custom syntax which made it difficult and unintuitive to use.

In Visual Studio 2012, regular expression searching is extremely easy–relatively speaking–to use and very intuitive. When you press CTRL+F to bring up the search window, there’s a regular expression toggle button. Click the button, and your search criteria will be interpreted as a regular expression.

That’s all good and well, but what’s really cool is that you can use capture groups for finding and replacing. How many times have you had to go through a file making the same change based on a pattern over and over again?

Here’s an example of finding/replacing with regular expressions and capture groups:

Find:    var(?<x>dog|cat)
Replace: varSuper${x}

Will replace "vardog", "varcat", "varDOG"
With "varSuperdog", "varSupercat", "varSuperDOG"
But not replace "var dog" or "dog"

How cool is that!?

Read more about using regular expressions in Visual Studio here.

 

A “Shim-ple” Tutorial With Microsoft Fakes

I’ve written previously about using Rhino Mocks to write unit tests for hard-to-test code, but with the release of Visual Studio 2012 comes a new way to work around those not-so-test-friendly areas: Microsoft Fakes. For those of you familiar with Microsoft Research’s Moles project, Microsoft Fakes is simply the next version. Fortunately, Microsoft decided this offering was valuable enough to be included in the latest version of Visual Studio.

What is Fakes, you might be grammatically-awkwardly asking yourself. If I had to describe Microsoft Fakes in a sentence, I’d say this: Microsoft Fakes allows you to intercept any method call and provide a substitute implementation, including calls to static and non-virtual methods. Sounds powerful, right? Well, it is.

Getting started with MS Fakes is refreshingly easy, too. The integration with Visual Studio allows you to skip the hard parts and get right to the meat: hooking up the fakes to work with the code you’re testing. This post will show you how to write a unit test for a simple FileReader class that has a single Read method that–you guessed it–reads a file. I’ll walk you through the entire process from scratch to hopefully avoid any confusion. So let’s do it!

  1. Open Visual Studio 2012
  2. Create a new Visual C# Class Library project
  3. Create the FileReader class:
    namespace adamprescott.net.FakesTutorial
    {
        using System.IO;
    
        public class FileReader
        {
            private readonly string _path;
            public FileReader (string path)
    	    {
                _path = path;
    	    }
    
            public string Read()
            {
                using (var fs = new FileStream(_path, FileMode.Open))
                {
                    var sr = new StreamReader(fs);
                    return sr.ReadToEnd();
                }
            }
        }
    }
    
  4. Add a new Unit Test Project to the solution
  5. Add a reference to the Class Library project from the Unit Test Project
  6. Create the fakes assembly by right-clicking System in the Unit Test Project’s References and selecting “Add Fakes Assembly”
  7. Create the FileReaderTest class:
    namespace adamprescott.net.FakesTutorial.Tests
    {
        using Microsoft.VisualStudio.TestTools.UnitTesting;
    
        [TestClass]
        public class FileReaderTest
        {
            [TestMethod]
            public void TestMethod1()
            {
                using (Microsoft.QualityTools.Testing.Fakes.ShimsContext.Create())
                {
                    // Arrange
                    const string path = "irrelevant";
                    const string expected = "contents";
                    var target = new FileReader(path);
    
                    // shim the FileStream constructor
                    System.IO.Fakes.ShimFileStream.ConstructorStringFileMode =
                        (@this, p, f) => {
                            var shim = new System.IO.Fakes.ShimFileStream(@this);
                        };
    
                    // shim the StreamReader constructor
                    System.IO.Fakes.ShimStreamReader.ConstructorStream =
                        (@this, s) => {
                            var shim = new System.IO.Fakes.ShimStreamReader(@this) {
                                // shim the ReadToEnd method
                                ReadToEnd = () => expected
                            };
                        };
    
                    // Act
                    var actual = target.Read();
    
                    // Assert
                    Assert.AreEqual(expected, actual);
                }
            }
        }
    }
    
  8. Run the test, and feel great about yourself!

There are a few important things to note about the use of Fakes in the test above. First, the fakes are wrapped in a ShimsContext. This makes sense since you’re intercepting system calls; you don’t want to accidentally affect other areas being tested outside of your test. Next, note that I’m using fakes to override two different constructors. I needed to override FileStream‘s constructor to open the file and StreamReader‘s constructor to read the file. In the StreamReader shim, I also provide a shim for the ReadToEnd method and configure it to return the fake text for my test. I probably could have opted to shim just FileStream, but the faking might be less straightforward since success would rely on knowing exactly which methods StreamReader will use when ReadToEnd is called.

For more information about getting started with Microsoft Fakes, check out this article at MSDN.

5 New Features I’m Looking Forward to in Visual Studio 2012

Last week, I attended a GANG meeting where Randy Pagels gave a presentation about what’s new in Visual Studio 2012. Prior to this, I had skimmed through the product guide, and I was expecting to see some nice new features. I didn’t expect to be blown away, but I left the meeting feeling completely geeked about the new version. And, since the RTM version was made available to MSDN subscribers last week, I wasted no time in getting it installed.

So what has me so stoked? Here’s a breakdown of the top 5 features that have me drooling:

  1. Code reviews
  2. Simplified code coverage (no more instrumenting DLLs!)
  3. Suspend/resume work
  4. Quick Launch
  5. Object Browser integration into Solution Explorer

I’ve only used VS2012 for a day or two now, and I haven’t had enough exposure to give an in-depth overview of these new features, yet. Unfortunately, the two that I’m most excited about–the new code review workflow and suspend/resume work–require a TFS upgrade, so I won’t be able to really test them until our IT department does that. I’m looking forward to using the other three right away, though!

Read more about What’s New in Visual Studio 2012 on MSDN.