It was once again time for new barkdust, so, just as we did a couple of years back, we called Grimm’s Advanced Bark Blowing and got our one unit of medium fresh fir. It was still $295, just as it was two years ago, so it was nice to see the prices didn’t go up. Flowerbeds are looking nice again. Now we just have to go out and dig out the sprinkler heads since they’re buried in… barkdust.
Generally speaking, it’s good practice to develop as a non-administrative user so you can make sure your applications will run for non-admin users and so you won’t do any damage to your environment as you develop. Unfortunately, some things end up forcing you to develop as an admin because they require rights that most non-administrative users don’t have.
Typemock Isolatorno longer has to be one of those things that forces you to run as an administrator.
The Isolator install guide has a “Security” section that outlines the various registry keys and files that Isolator needs read/write access to. If you give your non-admin user the rights to these keys and files, that non-admin user can start, stop, and link Typemock Isolator with other profilers.
In a recent round of troubleshooting, I ended up writing a program to modify the ACL on the requisite keys and files as found on the target machine. The result is EnableTypemockForNonAdmin - a command-line program that automates this permissions setup process.
This program will make permissions changes to files and your registry. Read the enclosed readme file and make sure you fully understand what’s going to happen before you run it.
Usage is simple. Open a command prompt as an administrator and run the program, passing in the name of the non-admin user you want to have access to Typemock Isolator.
EnableTypemockForNonAdmin.exe YOURDOMAIN\yourusername
Standard disclaimers apply - I’m not responsible for any damage done by the program; YMMV; use at your own risk; etc.
UPDATE 5/4/2010: Typemock Isolator 6.0.3 (not yet released at the time of this writing) may fix these issues if you are using Typemock Isolator with TestDriven.NET to make this program unnecessary. Jamie Cansdale from TestDriven.NET has commented below and left a link to a registry file you can install to make things work without changing permissions. I will leave this program available as it is still helpful for earlier versions of Typemock Isolator and/or TD.NET, and may still be required for command-line builds. (We’ll have to see once Isolator 6.0.3 comes out.)
UPDATE 5/5/2010: I verified that with Typemock Isolator 6.0.3 and NCover 3.4.3 the registry additions provided by Jamie Cansdale will allow you to run as a non-admin user (both using the Typemock Config Tool and TestDriven.NET), though I can’t speak to earlier versions of Isolator or linking with profilers other than NCover. These keys are also custom additions to your registry, so it’s a little “non-standard.” YMMV. I think the permissions change is probably the route I’ll continue to go until the profiler companies and/or Typemock start shipping these tweaks as supported items out of the box.
UPDATE 1/20/2011: Typemock Isolator 6.0.6 now requests read/write permissions on the registry key where the license info is kept right when the config tool starts up, regardless of whether you’re going to modify the value. I updated the EnableTypemockForNonAdmin tool to version 1.0.1.0 and added that registry key to the list of keys to give your non-admin user permissions to. Download now - free!
I had a problem this morning where my D-Link DAP-1522 access point had to be reset to factory defaults. After clicking the reset button on the back and having it reboot, I was unable to go to the configuration page following the instructions (visit 192.168.0.50 and log in). Totally inaccessible.
I ended up calling D-Link support and they explained how to do a more manual connection to the access point. Basically the DHCP server wasn’t enabled so I wasn’t able to get an IP address when connecting directly to the access point so I had to mangle my network settings a bit long enough to connect and set things up.
Connect your computer to the access point with an Ethernet cable.
Go into the adapter settings for the network adapter you’ve connected to the access point.
Update the TCP/IPv4 settings on the adapter so it’s not DHCP anymore. Use these settings:
Now open up a browser and go to 192.168.0.50 as you normally would to get to the configuration page. It should come up.
I kinda wish that had been in the instruction manual, but since it’s not, there you go.
If you are running Typemock Isolator along with another profiler like NCover and a crash occurs (e.g., the parent build process gets killed), it has the potential to corrupt the registry. What that means is that subsequent operations when you link/unlink with your coverage profiler may not work properly.
For NCover, you may see the build fail with exit code #20000 and the message “NCover.Console is returning exit code #20000. NCover couldn’t create a coverage report.” The reason it couldn’t create a coverage report is that Isolator and NCover weren’t linked correctly so NCover wasn’t actually running.
To fix it, repair your NCover installation. This will fix the corrupt registry keys and subsequent Typemock Isolator/NCover linkages will work correctly.
Thanks to Ohad at Typemock, Alan at NCover, and Jamie Cansdale from TestDriven.NET for helping me track this one down.
Here’s the setup:
You have a project that uses NUnit 2.5.5. You don’t actually have NUnit installed - you have it checked in along with your project’s source as a third-party dependency. (You did it that way so you can have different projects using different NUnit versions without having to install/uninstall things.) You’re using TestDriven.NET to run tests inside Visual Studio but you noticed that it ships with NUnit 2.5.3 - an earlier version of NUnit - and you want to use the version your project references.
How do you tell TestDriven.NET to use your project’s version of NUnit?
First, make sure your checked-in version of NUnit keeps the same directory structure it’s distributed with. That means you have a folder that contains the appropriate version of NUnit-Console.exe, etc., and a subfolder called “framework” that has the nunit.framework.dll in it, like this:
YourProject
|
+-lib
|
+-NUnit // Has NUnit-Console.exe in it
|
+- framework // Has nunit.framework.dll in it
|
+- lib
|
+- tests
Ensure you’re referencing nunit-framework.dll from the NUnit “framework” folder. There’s an nunit.framework.dll in the NUnit folder, probably, too, but don’t reference that one - reference the one in the “framework” folder.
Open the TestDriven.NET install folder. This will be something like
C:\Program Files\TestDriven.NET 3. On a 64-bit system it might be in
C:\Program Files (x86)\TestDriven.NET 3 or the like.
Go into the TestDriven NUnit folder for the version you’re
referencing. You should see a folder called “NUnit” in the
TestDriven.NET install folder. Open that. Inside there you’ll see
different folders for each version of NUnit. Right now there’s “2.2,”
“2.4,” and “2.5.” In this example, we’re looking at using NUnit 2.5.5
instead of 2.5.3, so we’ll open up the “2.5” folder. You should now be
in a folder like C:\Program Files\TestDriven.NET 3\NUnit\2.5.
Copy the nunit.tdnet.dll file into your lib\NUnit folder. Look in the TestDriven.NET NUnit version folder you should be in right now. You’ll see a file called “nunit.tdnet.dll.” Copy that into your checked-in lib\NUnit folder - the same folder that has NUnit-Console.exe in it. You will need to check this in along with your NUnit dependency.
Go into the TestDriven.NET “framework” folder. Still in that
C:\Program Files\TestDriven.NET 3\NUnit\2.5 folder - open the
“framework” folder under that. You should be in
C:\Program Files\TestDriven.NET 3\NUnit\2.5\framework.
Copy the nunit.framework.dll.tdnet file into your
lib\NUnit\framework folder. In that
C:\Program Files\TestDriven.NET 3\NUnit\2.5\framework folder you
should see a file called “nunit.framework.dll.tdnet”. Copy that into
your lib\NUnit\framework folder - the same folder that has
nunit.framework.dll in it. You will need to check this in along with
your NUnit dependency.
Run TestDriven.NET. Now when you run your tests with TestDriven.NET you should see it report that it’s using the version of NUnit you have checked in along with your project. That wasn’t too hard, now, was it?
What if I need to customize the locations? What if you don’t have the whole NUnit/framework folder structure and such? The basic principle here is that nunit.tdnet.dll needs to be in the same folder as NUnit-Console.exe and nunit.framework.dll.tdnet needs to be in the same folder as nunit.framework.dll. You may need to open the nunit.framework.dll.tdnet file in a text editor (it’s an XML file) and modify the “AssemblyPath” node in there. I haven’t actually tried this myself, so YMMV, but it should work.