Wednesday, September 17, 2008

TeamCity and Subversion with NTLM authentication

One of the subversion repositories I work with was just migrated to a brand new server. The server uses NTLM authentication. Everything works like a charm, except for TeamCity builds. It keeps throwing errors like: Cannot request dated revision from svn: svn: Authentication required for https://....Googling for the solution, it turns out the problem is with SVNKit. Apparently the workaround is to add a setting: svnkit.http.methods=Basic,Digest,NTLMGreat, so where do I put this setting? It needs to be set before the main JVM launches the server or agent. On the server that's simple enough. Adding the setting into the script that starts the TeamCity server process fixed that problem (hurray for unix scripts). On a Windows based build agent this is a lot less trivial, especially since the build agent runs as a service... I tried modifying all kinds of settings; build properties in TeamCity, agent properties, startup scrips (uhm, I mean batch files)... no dice. Some more digging leads to the wrapper that's used to launch the build agent service. Additional Java settings can be added to <BuildAgent Root>\launcher\conf\wrapper.conf : ... # Application parameters. Add parameters as needed starting from 1 wrapper.app.parameter.1=jetbrains.buildServer.agent.StandAloneLauncher wrapper.app.parameter.2=-ea wrapper.app.parameter.3=-Xmx384m wrapper.app.parameter.4=-Xrs wrapper.app.parameter.5=-Dlog4j.configuration=file:../conf/teamcity-agent-log4j.xml wrapper.app.parameter.6=-Dteamcity_logs=../logs/ wrapper.app.parameter.7=-Dsvnkit.http.methods=Basic,Digest,NTLM wrapper.app.parameter.8=jetbrains.buildServer.agent.AgentMain wrapper.app.parameter.9=-file wrapper.app.parameter.10=../conf/buildAgent.properties ...That works! Note that the extra svnkit setting needs to be inserted before the class name for this to work.

Thursday, September 4, 2008

Extending ASP.NET validation on the client side

One of the more annoying shortcomings of standard ASP.NET validation is it's lack of support for extending the the UI on the client side. For example, there is no way to set the css class of the input control when validation fails. I was working on some javascript to fix this when I came across an article that did just about the same thing. Combining my work with Scott's yields a bit more efficient javascript:
ValidatorUpdateIsValid  = function() {
 Page_IsValid =  AllValidatorsValid(Page_Validators);
 SetValidatorStyles();
}

SetValidatorStyles  = function() {
  var i;
  // clear all
  for (i = 0;  i < Page_Validators.length; i++) {
   var inputControl = document.getElementById(Page_Validators[i].controltovalidate);
   if( null != inputControl ) {
     WebForm_RemoveClassName(inputControl, 'error');
   }
 }
  // set invalid
  for (i = 0;  i < Page_Validators.length; i++) {
   inputControl =  document.getElementById(Page_Validators[i].controltovalidate);
   if( null != inputControl && !Page_Validators[i].isvalid ) {
        WebForm_AppendToClassName(inputControl, 'error');
   }
 }
}
ValidatorUpdateIsValid is part of the ASP.NET validation client script. It's invoked once whenever client side validation functions are triggered. For example after a field's value has been opdated (OnChange). This makes it the ideal place to hook into ASP.NEt client side validation. Hooking in to JavaScript is quite easy since in JavaScript any function can be redeclared. The last declaration is the one that is used. By inserting the script in the page content the function ValidatorUpdateIsValid is guaranteed to override the ASP.NET function that is loaded in the page header. I've packaged the script in a control that can be dropped into any (master) page to extend existing validation controls. I'll post the sources and a sample asap.

[11 okt 2010] Updated source code as suggested by Markus.