LP on .NET

February 12, 2012

Deleting a Line in the Visual Studio Text Editor

Filed under: .NET,C#,Visual Studio — Larry Parker @ 6:07 pm

After programming in Visual Studio for almost a decade, I recently found out (by accident) an easier way to delete a line.

Instead of first selecting the line with Shift-Down-Arrow and then pressing the Delete key, you can just press Shift-Delete.

Simple!

Advertisements

December 14, 2011

Ignoring Unit Tests

Filed under: .NET,C#,Visual Studio — Larry Parker @ 11:19 pm

Have you ever had a unit test that you didn’t want executed as part of your team’s test runs?  For example, if it requires external data but you haven’t yet set up the test database.  Or you’ve been using a unit test as a workbench for developing some code that you’re interacting with in the debugger and don’t really want it to be run by others.

Up until recently, I would either comment out the [TestMethod] attribute or comment out the entire test method’s code.

But there’s a better way, as a colleague of mine recently advised – the [Ignore] attribute.

Decorating your test method with this attribute will prevent it from being run.

The nice thing about this is your test code will still be compiled and refactored with the rest of your codebase.

When you do want the test to run while you’re working with it, just uncomment the [Ignore] attribute.  Then when you’re ready to check in your test, comment it back and you’re all set to go.

Hope this helps.

July 25, 2011

Useful Visual Studio Shortcut Keys

Filed under: .NET,Visual Studio — Larry Parker @ 3:26 pm

Here’s a link to some useful Visual Studio shortcut keys:

http://blogs.msdn.com/b/piyush/archive/2007/03/16/useful-visual-studio-shortcut-keys.aspx

October 11, 2010

Renaming Namespaces

Filed under: .NET,C#,Software Development,Visual Studio — Larry Parker @ 4:04 pm

Did you know that you can use Visual Studio’s refactoring feature to rename namespaces?  Just position the cursor over the portion of the namespace that you want renamed and press F2 (or right-click and select Refactor | Rename), and Visual Studio will rename all occurrences of the namespace in your solution.

For example, from this (place the cursor somewhere over “Server”):

namespace MyApp.Server
{
    // ...
}

to this (after renaming to “Client” in the Rename dialog box):

namespace MyApp.Client
{
    // ...
}

Pretty handy feature!

August 31, 2010

VS 2008 to VS 2010 Solution Conversion Bumps

Filed under: .NET,C#,Software Development,Visual Studio — Larry Parker @ 1:22 pm

My team just branched our codebase’s trunk into a sandbox for some .NET 4.0 prototyping.  The previous solution was in VS 2008, so when I opened it up in VS 2010 it brought up the conversion wizard and proceeded to convert the projects.

But after running through our 100 projects it gave me an error message (unfortunately hidden behind the foreground windows) that the solution file was read-only and could not be converted.

I’m surprised that Visual Studio didn’t ask me to check out the file, because our trunk was branched under TFS and my VSTS client was attached to the TFS server.

So I opened up the solution again from VS 2010 and this time the wizard did ask me to check out the files as it converted them.

But then another bump in the road.  This time it could not convert my unit test projects because the .vsmdi and .testrunconfig files were read-only.  Why didn’t VS ask me to check out those files?

The solution to this problem was to locate the unit test projects in Solution Explorer and just reload them.  If you run into this, just right-click on the project, select Reload Project, and then click through the conversion wizard prompts.

This did the trick, so for the most part the conversion was fairly painless, although not without a few bumps.  When is software development truly ever a smooth trip?  🙂

The next step will be to target .NET 4.0 in the projects and rebuild.  Next hill to climb…

Hope this helps.

November 28, 2009

Unit Testing Exceptions

Filed under: .NET,C#,Microsoft,Software Development,Visual Studio — Larry Parker @ 10:23 pm

Up until recently,  I had been following a pattern in my unit tests of catching expected exceptions that is similar to the following:

[TestMethod()]
public void AddTaskTest()
{
    Schedule target = new Schedule("* * * * *", "Every minute");
    ScheduledTask scheduledTask = null;

    Boolean isCaught = false;
    try
    {
        target.AddTask(scheduledTask);
    }
    catch (ArgumentNullException) { isCaught = true; }
    Assert.IsTrue(isCaught);
}

This works, but is a bit of a pain to write every time you want to check that an exception gets thrown by the method being tested.

I found a better approach at this blog post by Pedro Silva of Microsoft.

I modified it slightly to take a generic type parameter instead of passing in the type as a formal parameter (a little easier in my opinion).

Now the unit test looks like this:

[TestMethod()]
public void AddTaskTest()
{
    Schedule target = new Schedule("* * * * *", "Every minute");
    ScheduledTask scheduledTask = null;

    UnitTestHelper.TestException<ArgumentNullException>(() =>
        target.AddTask(scheduledTask));
}

Much simpler – especially when you’re testing for lots of exceptions!

I’m using a lambda expression in this example, but you can also use an anonymous delegate as in the blog.  I just think lambdas are more succint, but either will do.

Here’s the code with my tweaks (comments removed for brevity – please check the original blog post for more info).

public static class UnitTestHelper
{
    static public void TestException<T>(Action action)
    {
        try
        {
            action();
            Assert.Fail("Test should have thrown exception " +
                typeof(T).Name + ".");
        }
        catch (AssertFailedException) { throw; }
        catch (Exception e)
        {
            Assert.IsInstanceOfType(e, typeof(T),
                "Exception is not of the expected type.", typeof(T).Name);
        }
    }
}

August 1, 2009

Let’s Hear it for Blogging

Filed under: .NET,Blogroll,C#,Visual Studio — Larry Parker @ 11:06 am

I recently ran into that darn Visual Studio bug that I got a few weeks ago:

API restriction: The assembly ‘file:///C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll’ has already loaded from a different location. It cannot be loaded from a new location within the same appdomain

Of course I couldn’t remember what the fix was.  Fortunately I blogged about it and found the answer here (the fix once again was to delete my solution’s user options file).

I guess that’s what technical blogging is all about – keeping a running record of what you encounter in your programming travels.  Let’s hear it for blogging!  🙂

July 7, 2009

Visual Studio 2008 Unit Testing Bug

Filed under: .NET,C#,Visual Studio,VSTS — Larry Parker @ 11:47 am

I just ran into a bit of a nasty bug in Visual Studio 2008 while doing some unit testing.  At some point after a bunch of edit / compile / unit test iterations, I got the following error trying to compile my solution:

API restriction: The assembly ‘file:///C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll’ has already loaded from a different location. It cannot be loaded from a new location within the same appdomain

Restarting Visual Studio did not help.  Neither did cleaning and rebuilding my solution.

I found this thread on the MSDN VSTS forum which discusses the problem.  Microsoft apparently could not reproduce the problem, and closed out a bug report submitted to Microsoft Connect as “Closed (Not Reproducible)”.

If you’re running into this problem, I recommend reading through the entire forum thread, because the solution does not seem to be so cut and dry.

But for me, deleting my solution’s user options file (e.g. MySolution.suo) did the trick.

Hope this helps.

July 2, 2009

System.Threading.Thread Constructors Tip

Filed under: .NET,C#,Software Development,Visual Studio — Larry Parker @ 11:48 am

Just a quick tip when calling any of the constructors for System.Threading.Thread.  Many examples (including the MSDN documentation) explicitly create a ThreadStart (or ParameterizedThreadStart) instance and pass that into the constructor:

void DoIt()
{
    Thread thread = new Thread(new ThreadStart(DoWork));
    thread.Start();
}

void DoWork()
{
}

This is of course totally fine, but you can save a couple of keystrokes by just passing in the method name itself:

void DoIt()
{
    Thread thread = new Thread(DoWork);
    thread.Start();
}

This compiles to the exact same IL code (you can see this for yourself using Reflector or some other utility).

I just find it a bit easier than instantiating an object, and the code is easier to read as well.

Hope this helps!

June 30, 2009

Now that’s a Property Name!

Filed under: .NET,C#,Humor,Visual Studio,WCF — Larry Parker @ 4:07 pm

Wow, I just came across a property in .NET that is over 100 characters long!  Check this out:

private void Application_Startup(object sender, StartupEventArgs e)
{
    var x = MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

In fact, it looks like System.ServiceModel.MessageSecurityVersion has all kinds of lovely property names:

untitled

Good thing for IntelliSense!  🙂

Next Page »

Blog at WordPress.com.