Where do the unit test code files go?

Recently I came into some very old post about handling unit test code name space and locations. It really looked a lot of effort for very simple tasks.

I don't put my unit test code into a separate project/assembly. The reason is simple, the unit test codes is not secondary citizen and shall be treated as seriously as "production" codes, if not more seriously. You may argue that shipping unit test codes to end user is meaningless. While, I kind of agree. So if you do want stripping the unit tests off your production assembly, a little trick will help, wrap all your unit test codes with a macro check:

#if DEBUG
using NUnit.Framework;
namespace your.name.space
{
}
#endif

and the final release build will not contain any unit test codes. Still your assembly will depend on NUnit assembly and by default the NUnit DLL will appear in your release folder. Removing it won't do any harm.

I came from Java camp and had the habit to put source code and test code side by side, that is, source code is under "project_root\src\" and test code under "project_root\Test\" folder. I know it's not a common practice in .NET world to have a "src" folder, but it does no harm and give me the feasibility to put more resource under the project root folder, besides the benefit of separate the unit test codes into different folders, so I'm going to stick with it. If you happen to have some convention to make folder structure appear in namespace structure, then another trick to overcome it  is, in project browser, select the "src" folder and press F4 to bring up the property windows, then set the "contribute to namespace" option to false.

Recover Windows 7's Explorer from "No such interface supported" error

Yesterday I experienced a disaster. After I installed and removed Google Drive client, Windows 7 seemed gone crazy: if I click on a document, some times it was opened, sometimes it was not; if I click on an application, nothing happens; if I input the application name, e.g. cmd.exe, in the Run dialog, it always complains "No such interface supported".

I tried almost all the ways I could think / googled of:

• using Windows restore to restore to the point before Google Drive was removed, it did not work. I could only find 1 restore point, which was wired.
• try to use some registry cleaner as suggested by some internet posts, it did not work too. (though the way I start the application is a little trick that I'll talk about)
• re-register all the DLLs on my hard drive, as some posts suggested, which also did not work

Here is the trick to execute an application, when Explorer and Run dialog does not work: it seemed in my case the shell extension to open some of the linked file extensions was still partially working, so I created a file with a non-registered extension and dbl click to open it, then select the application you want to execute. This way, I managed to still execute applications. But applications started from this way could not elevate to administrator mode. Luckily I already made cmd.exe by default run under administrator, so it was not a problem to me.

Back to the problem, I was lucky to have a backup local user account with administrator rights, and I decided to try it out and it was not poisoned as my domain account. So I guess that the problem was the registry database of my domain account. So after I have backup my files, I went to the "advanced system settings" dialog (type the quoted string in the search box on start menu), pressed the "settings" button in the "User profiles" group box, and deleted my domain's profile. All the files under my "C:\Users\MyUser" folder was gone. So do remember backup your files!

This worked for me, use at your own risk.

Push back to Gitblit over https, without a valid certificate

Now I have a Gitblit server running, waiting to be connected. The good thing about Gitblit is, you do not even need Git on the server, its package contains a Java implementation of Git. In the long run, you still need it, since the document says git-gc is not properly implemented.

If you already have a Git repository on your local PC, and you want to push it to Gitblit, it's quite simple:

1. Using Gitblit's web GUI to create a new repository, assign share mode. If you want to block anonymous access, make sure you select "authenticated view, clone & push".
2. Open the repository you just created, and you'll see a link started with https://, click the copy to clipboard icon to copy the link to clipboard
3. Start Git console and navigate to your local Git folder
4. Run below command: ( you shall be able to paste the link from clipboard )
  git remote add origin https://yourpcname:yourport/git/yourrepo
  git push origin master

and bang! you'll hit below error:
  "SSL certificate problem, verify that the CA cert is OK."

This is because Git will verify if the server's certificate is a valid certificate. If you are a poor man as I am, you probably don't have a valid certificate. Set an environment variable will make Git skip the verification step (I put this line in the ~/.bashrc file to avoid type it each time)
  $ export GIT_SSL_NO_VERIFY=true 

  $ git push origin master

This will push you master branch to Gitblit. Then you can go to web UI to verify it.

Another way to overcome this certificate issue is to create your own root certificate, import it as trusted root certificate, then create a certificate and sign it with the root certificate. 

Setup Gitblit on windows server 2003

Git is by its nature friendly to *nix systems. So setting up a Git repository on Windows has been really painful: quite several tools need to be integrated, sophisticated steps need to be performed. In short, it's time consuming, error prone, and hard. I tried it once, and do not want to try it again.

Recently I read about (forgot the article, sorry) this new OS project, Gitblit, which really make hosting Git repository on Windows a easy task. It's a Java application, which means it runs on not only *nix, but also Windows! They provide several packages for different usage scenarios, and also good document.

The setup process is very easy:

• Download the "Gitblit Go" package, unzipped to the folder you plan to hold the software
• Go to the folder, edit the installService.cmd file and change the "SET ARCH= " line. My server is x86 based, while the default setting is amd86
• Edit the gitblit.properties, point git.repositoriesFolder to the folder where you hold your Git repositories. Note you should use forward slash even on Windows, e.g C:/GitRepo/. Change server.httpsBindInterface to empty to bind https to all ip addresses. By default it only binds to localhost, which will not allow other computers accessing it
• Run makekeystore.cmd to create a self-certified key for https
• Run installService.cmd to install it as a Windows service
• Start the service and launch browser to navigate to https://yourpcname:8443, and login with admin/admin
• Change the password of admin immediately.

And you are done!

You will want to examine the gitblit.properties for possible configurations. Most of the items are documented very well so for most items you can just read through the config file and config properly without searching through documents.

Some Bash tips from others

I'm mostly a Windows guy. All my computers are loaded with Windows. I know how to use *nix, though not very efficiently. Since I started using Git, I have to deal with Bash more and more, through MinGW. Thus it's better to pickup some tricks of Bash to work more efficiently.

1. !$: will be replaced with the last parameter to the last command. For example, if you just executed a command like this:
      ls /a/very/long/path
   and then you want to know the detail of what's in the path, a simple way of doing it is:
     ls -l !$
   If !$ is modified with :h, then the last part of the path is removed.
2. ^: leading ^ will start replacing last command line with something new. Coming from last example, if part of the path is wrong, then you can try this:
       ^wrong^correct

More info can be found in this link: http://samrowe.com/wordpress/advancing-in-the-bash-shell/

1st try on VS2012

After several hours download and installation, I finally can start trying the RC. From first sight, I really can not say I like the UI. Too much change and all black-white icon really make it hard to find the correct icon. Luckily I'm mainly a keyboard guy and does not use toolbars often. With R# EAP version installed, I don't really need to even drop down the stupid all capital case MENU. BTW, install the removeCAPS extension can help you easily turn it back to normal.

There are things I like about it. Even it's not released version, it's really stable, and the responsiveness is much better than VS2010. Also I can work with VS2010 solution file and project files without any problem. This is a must have feature for try out on projects you share with team.

MSysGit mergetool broken after 1.7.7

I've been using Git on Windows (MSysGit) happily with BeyondCompare 3 for quite a while. Mostly I use BC3 to view changes. Occasionally I use it to merge conflicts. I don't merge very often, thanks to Git's powerful merging capability. It has worked fine. Recently I upgraded to version 1.7.10-preview20120409, and suddenly the git's merge command always fail with below error messages:

Merging:
my/path/filename.cs

Normal merge conflict for 'my/path/filename.cs':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (BC3):
git_path/libexec/git-core/mergetools/BC3: line 9: bcompare: command not found
my/path/filename.cs seems unchanged.
Was the merge successful? [y/n] n

Where is this line 9? It turns out that it seems MSysGit (or Git?) has put all merge tools to a folder named "git_path/libexec/git-core/mergetools/". In my installation, I can already find quite a bunch of tools:

araxis
bc3
defaults
deltawalker
diffuse
ecmerge
emerge
kdiff3
kompare
meld
opendiff
p4merge
tkdiff
tortoisemerge
vim
xxdiff

and they are actually bash scripts. For example, the bc3 file is like below:

diff_cmd () {
 "$merge_tool_path" "$LOCAL" "$REMOTE"
}

merge_cmd () {
 touch "$BACKUP"
 if $base_present
 then
  "$merge_tool_path" "$LOCAL" "$REMOTE" "$BASE" \
   -mergeoutput="$MERGED"
 else
  "$merge_tool_path" "$LOCAL" "$REMOTE" \
   -mergeoutput="$MERGED"
 fi
 check_unchanged
}

translate_merge_tool_path() {
 if type bcomp >/dev/null 2>/dev/null
 then
  echo bcomp
 else
  echo bcompare
 fi
}

and there is really is a line 9! Of course directly modify the file will do the trick. But I guess there are better ways. After testing around, trying to override the merge_tool_path environment variable, I found it's easier if I just put BC3's folder to path, and nothing else need to be changed!