digitalMoto.net

(Another snippet I originally posted to CodeKeep.)

Using reflection inside a method to determine where you are in the control flow via the output window.

This is another snippet I used to have on CodeKeep.net.

I like to put a lot of debugging statements in my code and tracking the code exec is much easier if I know which methods are being called.  I don’t do this so much anymore as VS2010 has greatly improved debugging over VS2008 and VS2005.

Code:

string callingAssemblyName = System.Reflection.Assembly.GetCallingAssembly().FullName;
string methodName = System.Reflection.MethodBase.GetCurrentMethod().Name;
string className = System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.ToString();

Usage:

using System.Diagnostics;

Debug.WriteLine(System.Reflection.MethodBase.GetCurrentMethod().ReflectedType.ToString() + "." + System.Reflection.MethodBase.GetCurrentMethod().Name + "() called.");

or

string methodName = System.Reflection.MethodBase.GetCurrentMethod().ReflectedType.ToString() + "." + System.Reflection.MethodBase.GetCurrentMethod().Name;
Debug.WriteLine(methodName + "(" + <method args> + ") called.");
…
Debug.WriteLine(methodName + "() ending.");

I keep looking this up and I know it works.

Sending the LINQ To SQL log to the debugger output window

With Visual Studio Team System, the LocalTestRun.testrunconfig file controls execution parameters for running tests. The default timeout on individual tests is 30 minutes. Ouch!

Solution:

• Double click on the ‘Solution Items\LocalTestRun.testrunconfig’ file.
• Select ‘Test Timeouts’
• Set the individual test time to your preference or set a total time abort if you prefer.

You can embed items into your WinForm app. So how to do you figure out what you have and the correct path to retreive the items? Here’s a method to show you what’s an embedded resource in your application.

Code:

using System.Diagnostics;
using System.Reflection;

private void ExposeResources()
{
	Assembly assembly = Assembly.GetExecutingAssembly();
	foreach ( string resource in assembly.GetManifestResourceNames() )
		Debug.WriteLine(resource);
}

Usage:

ExposeResources();

Reference:
http://msdn.microsoft.com/en-us/library/aa287526(VS.71).aspx

I wrote about this a couple days ago. I have now confirmed my fix.

ENV:
Win7 Ent x64, VS 2008 SP1

Problem:
API restriction: The assembly ‘file:///c:\Program Files (x86)\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.

Solution:
Make sure you don’t have any extra references in your non-test projects. It happened to one guy on our team. The reference showed up during the check-in code review.

Remove “processorArchitecture=MSIL” from the UnitTestFramework reference in ALL of the test project files.

<reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />

becomes…

<reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Restart VS. Reloading the project isn’t enough to get around the issue once it has popped up. I had to restart Visual Studio.

The issue went away after I double checked all of my project files and cleaned up the references in my test projects. (There are 12 projects in my current solution including 5 test projects.) I tested the fix by:

1. Deleting the UnitTestFramework reference from one of my test projects.
2. Re-add the reference via the UI by right-clicking on the references folder
3. Add reference
4. .Net tab
5. Select Microsoft.VisualStudio.QualityTools.UnitTestFramework
6. Click ok
7. Save all. At this point the processorArchitecture reference appeared in my project file.
8. Compile. Failure.
9. Manually edit the project file with Notepad2.
10. Save.
11. Reload project when VS notices the change outside of the IDE.
12. Compile. Failed.
13. Restart Visual Studio.
14. Load solution.
15. Compile solution. No errors.

Works on my machine…

So I was getting this error:

Error while trying to run project: Unable to start debugging.

The components for the 64-bit debugger are not registered. Please repair your Visual Studio 2008 Remote Debugger installation via ‘Add or Remove Programs’ in Control Panel.

A little surfing and I found a solution. Install the debugger! The 64-bit debugger is not installed by default. The installer is on the Visual Studio install disc. “<Drive Letter>\Remote Debugger\x64\rdbgsetup.exe”

My days are usually better when I ride. Maybe it is being forced into the moment instead of the esoteric world of software development where I spend most of my time. I had a Doctor’s appointment this morning so I slept in and took my time then I was late. It didn’t matter because a previous patient had a bunch of stuff to discuss and appointments were running one hour late. I cooled my heals and read a mag I’d picked up at PADNUG last night. I had had a nice mellow ride to the Doktor’s office so I was mellow and ready for whatever chaos I encountered. Read more…

I went to an MSDN event yesterday. The topics were Azure, Debugging and Mobile Programming. Azure was interesting. I learned a lot about Azure and I learned that I shouldn’t think too much about it just yet. It won’t do what I need it to do at this time, plus it is a CTP and not ready for prime-time. That’s why they call it a community technology preview. Duh. One huge topic is storage. They don’t have rows. I can’t save a single record. This rather small issue makes it almost impossible to transition data between a local SQL server with a row-based relational model to the entitiy-based Azure data model. That could be a problem. But, as I said, it’s a CTP and lots of smart people are working on it. <shrug≶

The dugging section was the best for me. I learned a few little tidbits that should make my life a little easier. The speaker, Bruno Terkaly, had already posted his debugging tricks to his MSDN blog so I could pay attention and not scribble down notes. I skipped out a few minutes early so I missed all of the mobility discussion. (The word is I missed getting a free book as well.) Read more…