Always Run as Administrator

There are lots of reasons why you might need to run an application as administrator. Visual Studio, for example, needs admin privileges to do things like run a project using IIS or launch the Azure Compute Emulator. If you use these tools daily, manually running as Administrator gets tiresome. The straightforward way to automate this is to check the “Run as Administrator” checkbox on a shortcut, but that checkbox doesn’t get used if you’re opening files directly.

Luckily, there’s a not-so-obvious way to perma-enable running as administrator for an executable.

  1. Navigate to the file in Explorer
  2. Right-click the program and choose Troubleshoot Compatibility
    1 troubleshoot-compatibility
  3. A dialog will display that says it’s detecting issues
    2 detecting-issues
  4. When prompted, select the option to Troubleshoot program

    3 troubleshoot-program
  5. Check the box next to The program requires additional permissions
    4 requires-additional-permissions
  6. The next screen tells you that the UAC setting “Run as administrator” has been applied; click Test the program… to launch the application to verify
    5 test-the-program
  7. You can verify that the application is running as administrator because “(Administrator)” will be added to the title bar
    6 running-as-administrator
  8. The troubleshooter will ask you to verify that the problem was fixed; select Yes, save these settings for this program
    7 is-the-problem-fixed
  9. Finally, you’ll be displayed a summary indicating that the “problem” has been fixed, and you can close the troubleshooter
    8 troubleshooting-completed

And–voila!–your application will now launch as administrator regardless of how its started, whether it be through a shortcut to the .exe or by double-clicking a file for which it’s the default program.


Where my squiggles at?

Somehow, I lost my warning & error squiggles in Visual Studio. These are controlled in Options > Text Editor > C# > Advanced. Enable/disable them by using the Underline errors in the editor and Show live semantic errors checkboxes.


Solution via visual studio – How to get rid of warning squiggles for WPP TraceEvent macro? – Stack Overflow.

Go To Implementation with View Call Hierarchy

Hands down, my favorite thing about ReSharper is that it adds Go To Implementation to the context menu for easy navigation to a function in a class that implements an interface. That’s kind of a wordy statement, so let me rephrase. Consider the example below. If I have a variable foo of type IFoo, ReSharper lets me right-click a call to foo.Bar() and jump directly to the implementation in either BasicFoo or ExtremeFoo.

interface IFoo
    public void Bar();

class BasicFoo : IFoo
    public void Bar()

class ExtremeFoo : IFoo
    public void Bar()

But what if you don’t have ReSharper? I used to think the next best option was Find All References, which does a good job of finding all the right places where you might want to look for an implementation. However, the implementations are mixed with the method itself and calls to the method, and the results returned by Find All References can become rather unruly.


Note that I said “used to think,” though. See that option under Find All References in the context menu, View Call Hierarchy? Use that. If you look at the Call Hierarchy for an interface method, you’ll get a group of implementations–exactly what I love about ReSharper’s Go To Implementation! You’ll also have a group of callers to the method which is what you get from another ReSharper nicety, Find Usages. Awesome.


Call Hierarchy is pretty amazing, and it’s kind of a bummer that I didn’t know about it until just now. Find All References still has its uses, but it’s taking a backseat to View Call Hierarchy in my toolkit. If you haven’t used it before, give it a shot–I bet you’ll love it, too.

Visual Studio Fix: Intellisense Not Popping Up or Not Working « OmegaMan’s Musings

I was monkeying around with Resharper optimization and lost Intellisense altogether! Here’s how I got it back.

In quick launch type “Statement Completion” and choose the first one  “Text Editor -> All Languages -> General” to be taken to the options page for all languages.

On the general options page in the “Statement Completion” section override whatever is in the boxes “Auto list members” and “Parameter Information” and makes those checked. Such as shown here:

via Visual Studio Fix: Intellisense Not Popping Up or Not Working « OmegaMan’s Musings.

Ultimate Guide to Speeding Up ReSharper (and Visual Studio) – JetBrains .NET Tools Library – Confluence

After a few months off, I’ve re-added ReSharper to my toolkit. It’s a little pokey with my current solutions, though. I found some good info from JetBrains on speeding it. up. Enjoy!

Ultimate Guide to Speeding Up ReSharper (and Visual Studio) – JetBrains .NET Tools Library – Confluence.

Create Permanent Custom Styles in Outlook

One of my peeves in Outlook is the formatting of code snippets that I send in email. Nine times out of ten, I’m copying and pasting from Visual Studio. That works pretty well; you get keyword highlights and all that fun stuff. Life is good–unless you happen to have a dark background. I like the dark theme for Visual Studio 2012, but I can’t stand that pasted text comes with a black highlight! It’s not that I mind the black background, but the highlighted text looks like a disaster.


At this point, you’ve got three options: go back to a light-background theme in Visual Studio, deal with it, or adjust the formatting in Outlook. It looks too ugly for me to ignore, so option #2 is out. Until know, I’ve been exercising option #1, living in a default-themed world. I decided to go in a different direction today, though. I created a style that I can use to quickly format my pasted code. (An easy solution that I considered using for a while was to use LINQPad as a formatting buffer. I’d copy/paste code from Visual Studio to LINQPad and then re-copy/paste from LINQPad to Outlook. It works.)

The key to making this as painless as possible is getting the style configured correctly. Here are the steps I used to create my new style in Outlook 2013:

  • Choose “Create a Style” from the Styles gallery (FORMAT TEXT > Styles)
  • Change paragraph spacing options
    • After: 0 pt
    • Line Spacing: Single
  • Modify borders and shading
    • Border Setting: Box
    • Border Color: White
    • Border > Options > From text (all sides): 12 pt
    • Shading Fill: Custom Color (RGB: 30, 30, 30)

To ensure the style sticks around for future emails, do the following:

  1. Change Styles > Style Set > Save as a New Style Set…
  2. Change Styles > Style Set > Set as Default
  3. Restart Outlook for the new default style set to take effect

When I paste code from my dark themed Visual Studio, it still looks ugly. I can make it prettier by simply selecting the text and applying my new style. As a final beautification, I select the text and remove the black highlight from the text. (The removal of highlighting wouldn’t be necessary if I were content to use a black background, but I think 30/30/30 gray looks nicer, and so I will remove the highlight.)


It’s definitely a few extra clicks anytime I’m sending code, but the end product looks good!

Change Code Analysis Rule Sets in Visual Studio 2012

Code Analysis is a great way to identify problems with your code and enforce standards. By default, Code Analysis in Visual Studio 2012 uses a rule set called Microsoft Managed Recommended Rules. It’s a set of rules that Microsoft has deemed most important, and they suggest following these rules in all projects. Here’s their description of the rule set:

You can use the Microsoft Managed Recommended Rules rule set to focus on the most critical problems in your managed code, including potential security holes, application crashes, and other important logic and design errors. You should include this rule set in any custom rule set that you create for your projects.

I like this rule set, but it’s not enough for me. I suggest using Microsoft’s Basic Design Guideline Rules rule set. The MSDN description suggests, “You should include this rule set if your project includes library code or if you want to enforce best practices for code that is easy to maintain.” Best practices for code that is easy to maintain? Who doesn’t want that!?

I can tell I’ve sold you on this rule set, and now you’re wondering how to actually use it. Don’t worry, it’s easy!

  • Open the Code Analysis window in Visual Studio (View > Other Windows > Code Analysis)
  • Click the ‘Settings’ button
  • Click the rule set value next to the project(s) that you want to change

That’s it! Now, when you run Code Analysis, it will use the selected rule set.

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.

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.


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.

Performance Profiling for Unit Tests

When I first got my hands on Visual Studio 2012, I was trying out every feature I could, new and old alike. I love the new Test Explorer. Code coverage is SO much better than it was before. Code analysis for code clones is a terrific, too. The only thing I wasn’t happy about was performance analysis.

The reason I wasn’t happy with performance analysis is that I couldn’t use it on unit tests. Luckily, Microsoft fixed that with the release of Visual Studio 2012 Update 1. Now you can right-click a test and choose Profile Test to run performance analysis on a single unit test, and it is awesome!


When you choose to profile a test, the test runs as usual followed by the analysis. When analysis completes, you’re presented with a summary view that shows you CPU usage over time, the “hot path” call tree—a tree of the most active function calls where most of the work was performed—and a list of functions responsible for doing the most individual work.


You can find out more and investigate resource spikes by selecting a time range on the graph and filtering. That’s all good and well, but what really blew me away was that you can click on the functions with the most individual work to drill into them. Drill into them? Yea—you’re taken to a view that shows you the selected function, its callers, and the methods it calls. There are percentages that show how much time was taken in each of the three areas (callers, current method, and callees), and you can click into any of the methods displayed to navigate up or down the call stack. The actual code for the current method is also displayed. The only thing that seemed sub-optimal is that I couldn’t edit the code directly; there’s a link to the actual file, though, so you’re only a click away from the editable code file.


There are other, sortable views you can look at, too. You can view a call tree or breakdown by module, and you can get to the same function details view described above from each of those views. It’s a really useful, powerful experience.

Here’s where it gets really nuts, though: add SpecFlow to the mix. SpecFlow lets you write feature-based scenarios that are capable of serving as automated integration tests. The scenarios run like normal unit tests. You can right-click them in the Test Explorer to run performance analysis on them. This means that you can do targeted performance analysis on specific features of your application! To test this out, I sorted my unit tests by execution duration and analyzed the slowest. I was able to find a bottleneck with a caching algorithm used by nearly all of the other modules in the application. Execution time of the 350 unit tests in the project went from 50 seconds to 20. That’s a HUGE improvement from fixing one flaw found from running analysis on one function picked only because it was the most time-consuming in the slowest test.

Good tests are supposed to run quickly, and performance analysis is an invaluable tool to help you triage valuable-but-poor-performing tests. Also, since you’ve got automated tests, you can refactor and optimize the performance of your application with high confidence. If you haven’t used performance analysis before—more specifically, performance analysis for unit tests—give it a shot; I’d be blown away if you didn’t find incredible value.

%d bloggers like this: