Use P4Merge as the Merge Tool for Mercurial Windows

Whenever I do a Mercurial merge on Windows I get a little Visual Studio Dialog popup saying File -nosplash not found. Which is annoying. Especially as I have Perforce’s excellent p4merge installed.

You can set the merge tool used by Mercurial like so:

Edit %userprofile%\Mercurial.ini

where Edit is your favourite text editor, and %userprofile% is usually C:\Users\username\.
Then add this section to your Mercurial.ini file:

[merge-tools] 
p4.priority = 100 
p4.premerge = True
p4.executable = C:\Program Files\Perforce\p4merge.exe
p4.gui = True 
p4.args = $base $local $other $output

You can change “p4” to anything, so long as you change all occurrences of p4 left of the = signs.
If p4merge.exe is in your path and if you use p4merge as your identifier, then you don’t need the executable line:

[merge-tools] 
p4merge.priority = 100 
p4merge.premerge = True
p4merge.gui = True 
p4merge.args = $base $local $other $output

MVC Html.ActionLink() fails weirdly with routeValues parameter in Asp.Net

It seems simple. In an MVC view page you have an @Html.ActionLink with parameters for action, controller & route values:

@Html.ActionLink("Some text","Action","Controller", new {id=1})

but instead of rendering the text with a link to the action, it renders a link with some weird URL that isn’t what you want at all.

If you use intellisense to look at the overloads for ActionLink, you’ll see that the overload you’ve got is interpreting new {id=1} as html attributes not as route values. You need the overload with one more parameter, which can be null:

@Html.ActionLink("Some text","Action","Controller", new {id=1}, null)

And then it works.

Lost SQL Server sa password ? How to start up and login in single user mode

The problem: Someone has lost the sa admin password for your MS Sql Server; or the one person who has SQL admin rights has left the company. Alas, you find that even having Windows admin rights does not grant you access because you have a recent version of Sql Server and you didn’t grant Sql Server admin rights to the machine or domain admins.

You can still fix this. You will need local admin right on the machine, and the ability to:

  • open a command line as an administrator
  • look through the registry with RegEdit to find the settings for the version and instance of Sql Server you are locked out of. MSDN mssqlserverloginmode-registry-key has some clues.
  • look through Program Files\Microsoft SQL Server\ and find the binn directory for your version and instance of Sql Server.

The trick is to start Sql Server in single user mode, and then login as a local admin. This will give you admin access to the SQl Server.

How to Get Admin Access to Sql Server on Your Machine

  1. Stop the sql service.
    • This is most easily done via the Windows Services Gui, but net stop MSSQLSERVER might do it. If you have a named instance use net stop MSSQL$instancename
  2. Work out the file location and registry key for the version/instance name of sql server you are trying to get into. This may be trickier than you think – you may have SqlExpress as well as more than one version and instance name of MSSQLServer. For instance:
    • C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn and
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQLServer\

    or

    • C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Binn and
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.SQLEXPRESS
  3. Change the registry entry for loginmode to 2 (not 0 or 1), which enables both Windows and SQL authentication.
  4. Open a command line window as administrator and navigate to the binn directory you found earlier under C:\Program Files\Microsoft SQL Server\. Run sql from the command line using the –f parameter, sqlservr.exe -f
    • You may need more command line parameters to get your instance running properly, although I never have so far. If so, use the Windows Services Gui to see what the rest of your command line has to be.
    • For a named instance, your command line is sqlserver.exe -f -s instancename
    • An alternative to -f is -m, but -f worked for me.
  5. Open another commandline, also as administrator, and run sqlcmd –S <servername>. Sqlcmd is usually on the path, but if not it should be in the same directory as sqlservr.exe.
    • The server name for local machine is of course ‘.‘, as in sqlcmd -S .
  6. Now you can type T-SQL commands. Try Select @@ServerName, @@Version just for fun.
  7. Note that after typing your commands you must type GO and enter before anything you’ve typed gets sent to the server.
  8. Add yourself to the sysadmin role:
    EXEC sp_addsrvrolemember 'DomainName\LoginName', 'sysadmin'
  9. Or, enable the sa login and set the password with 2 lines of T-Sql:
    Alter login sa With Password= '<enterStrongPasswordHere>'
    Alter login sa Enable
    Go
  10. Exit and close both command windows.
  11. Restart the Sql Server service from the services Gui or with net start MSSQLSERVER or net start MSSQL$instancename

Done.

Equivalent of bash / shell aliases for Windows command line

Relief comes from an unexpected quarter if you pine for your unix command line shell aliases and other such:

doskey ls=dir $*

is what you want. you can put it in an autorun setting in your registry by pasting this into notepad and saving it as something.reg

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"AutoRun"="\"C:\\Program Files\\Commands\\CmdAutoRun.cmd\""

If you prefer to do it by hand rather than by double clicking a .reg file, you don’t need the extra quotes and escapes (but keep the outermost quotes):

"C:\Program Files\Commands\CmdAutoRun.cmd"

Note you use $* instead of %*. You can otherwise use $1-$9. Further escape codes are on the technet DosKey page

.Net Assembly Binding Redirect doesn’t work – because you have an Uppercase/lowercase error in config

Thanks to Eran Stiller for spotting the fact that assembly binding redirect fails—with no appropriate error message or clue as to the reason for failure—if you used PascalCasing instead of camelCasing casing in your config.
This fails:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Moq" Culture="neutral" PublicKeyToken="69f491c39445e920" />
        <bindingRedirect oldVersion="4.0.10827.0" newVersion="4.1.1309.1617" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

because of incorrect case in the attributes Culture and PublicKeyToken. Make them camelCase like so:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Moq" culture="neutral" publicKeyToken="69f491c39445e920" />
        <bindingRedirect oldVersion="4.0.10827.0" newVersion="4.1.1309.1617" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

and now it works.