VMWare VMDebugger “unable to detect current startup project”

 

I spent many small packets of time trying to find a solution to this problem over about two months.  Luckily, I stumbled across an answer that actually worked for me.

Problem: Visual Studio 2008 with VMWare VMDebugger integration does not work.  When I try to launch debugging in a VM, I get a message that says “Unable to detect current startup project”.

Solution:  Remove any installer projects that are in the solution.

Source: Read MartinMoesby comment here.

Advertisement

SnippetCompiler is great, but…

…we don’t have to use it for quick compilable chunks of .NET goodness.  As detailed on marlongrech.wordpress.com, we can use TestDriven.Net to run small parts of code in the Visual Studio.NET debugger.

The code is not required to be a test case for use in a unit testing framework.  It can be an arbitrary method that just does some processing.  The key to using this technique, is to make sure you set a breakpoint.  That way you can manipulate parameters and actually get feedback about what the method is doing when it executes.

This is yet another reason we should buy TestDriven.Net.  It can pay for itself within a day or two.

In addition to SnippetCompiler and TestDriven.Net, Powershell is very useful for this kind of snippet testing as well.  But I’ll have to defer that post for another time.

BDD in .NET the way the big kids are doing it

This is an introductory article about using test/unit and test/spec for behavior driven development (BDD) in .NET.

Target audience:

This article is for you if:
1. You are a programmer/developer that uses Microsoft’s .NET Framework
2. You are interested in doing behavior driven development
3. You realize that while .NET has some nice up and coming BDD Frameworks, they still lag behind test/spec and rspec in features and usability.

Assumptions:

This article assumes that the target platform is Windows XP or greater (or lesser, depending on your experiences with Vista). These steps were not tested on Mono (by me), nor did I test on any OS not previously mentioned. I also assume that you are familiar with Ruby and gems. Also, I assume that you are comfortable with changing environment variables within Windows, which may require elevated privileges.

Required software/tools:

1. Ruby programming language
2. DiffUtils
3. RubyCLR (gem)
4. test/spec (gem)
5. zentest (gem)

Installation:

Download the One-Click Installer for Ruby from here. Double-click the executable and follow the wizard. Installation is a breeze with the One-Click Installer.

Second, download the DiffUtils from here. I suggest you download the installer instead of the zipped binaries. I tried the binaries initially, but found a missing dependency (try figuring that out). After downloading the installer, run it and remember the installation path for later use.

To complete the installation, we need to add the installation path to the PATH environment variable. We can do this by hitting the Left Windows key + Page Break. Select the “Advance” tab and click on the “Environment Variables” button. Select the variable named Path in the System Variables list. Click the “Edit” button under the list to bring up the edit dialog. Append a semi-colon and the installation path to the end of the “Variable Value” text box. BEFORE you exit out of the dialogs, click the “New…” button under the User Variables list. Create a variable named “HOME” and set its value to your user directory that has your “My Documents” folder e.g. “C:\Documents And Settings\Curtis”. Press the “Ok” buttons to exit all of the dialogs, and reboot your computer. The last step is very important, so try not to skip it.

Now that we have Ruby and DiffUtils installed, we can install the requisite ruby gems. Installation of the gems is straight-forward. At the command prompt, use a variation of the following command to install each gem:

gem install [gem name] --include-dependencies

I suggest you add the –include-dependencies flag to the gem commands in order to save a few prompts. Once the gems are installed, you’re all set. You don’t need me.

Usage:

I’ll add a few notes about how to use your new setup. This is where all your hard work pays off.

First, create a new C# Class Library solution in Visual Studio. I suggest you change the output directory to “../bin” in order to have MSBuild output your assembly to a “bin” directory in the root path of the solution.

Open your text editor and create a new file called “.autotest” in the root path of your solution. Note: This may be difficult to accomplish in Notepad since the filename is essentially an extension in Windows. I suggest using Notepad++ or Scite (installed with the one-click Ruby installer) instead.

This file is really just a Ruby source file used by the ZenTest gem. Copy the following code into the file and save it:

class Autotest
  #This method tells autotest to run all of the Ruby source files in the 'test'
  #directory whenever a file changes; namely a test file.
  def tests_for_file(filename)
    return Dir["/test/**/*.rb"]
  end
end

#This block tells autotest to run any file in the 'test' folder that starts with
#'test_' and ends with 'rb' whenever a 'dll' file changes in the 'bin' directory
Autotest.add_hook :initialize do |at|
  at.add_mapping(/^bin.*\/.*dll$/) do |filename, _|
    puts "This file changed: " + filename
    at.files_matching(/^test.*\/test_.*rb$/)
  end
end

This assumes the only .rb files in the solution’s path will be files intended to test the .NET assembly that is being created.

Next, create a new file in your text editor. Call it “test_mydotnetlib.rb” or something cheesier. But, be sure to prefix it with “test_” and save it into a folder called “test” under your solution’s path. The following steps will detail how to actually create a file to test your code.

All test files will require a few standard declarations in order to work properly:

require 'rubyclr'
require 'test/unit'
require 'test/spec'

include Test::Unit

#includes the .NET assembly intended for testing
reference_file 'C:\Dotnet\src\MySolution\bin\MyCustomLibrary.dll'

There are two points to note about the above line: First, the whole path to the output of your class library project should be specified. Secondly, this line points to a ‘bin’ directory located under the Solution’s path. This isn’t the default path of output for Visual Studio, so if you skipped the step above where I suggested you change the output path of your class library project, now is the time to correct that.

Now, we can begin writing our actual tests. Add the following to your test file and save it:

describe "MyCustomLibrary" do
  before(:each) do
    @speaker = MyCustomLibrary::Speaker.new
  end

  it "should say hello" do
    @speaker.sayHello.should.equal 'hello'
  end
end

At this point, we can start up Autotest. Open a command window and change directories to the root of your Visual Studio solution. Type “.autotest” and hit enter. Autotest will run the test that you just saved. It should show that you have 1 failed test. That’s great!

Create a Speaker class in your .NET project. Implement the sayHello method so that it returns the string “hello”. Build your project, and watch Autotest re-test your code again. This time the test should pass.

Sweet! This is just the tip of the iceberg of what can be done with RubyCLR.

This solution works because of the creativity and hard work of some great developers. I’m going to run the credits before the end, just to make sure you stick around to acknowledge their efforts:

Credits:
John Lam (RubyCLR) and the person or people continuing to develop it
Christian Neukirchen (test/spec)
Nathaniel Talbott (test/unit) and the person or people that continue to develop it
ZenSpider (ZenTest)
Paul Eggert (DiffUtils)
Venkat Subramaniam (for his inspiring presentation on DNRTV.com)
And, of course, Matz and the rest of the Ruby team

I also appreciate the efforts of all others involved whether directly or indirectly.

Now, back to the code…