This approach to fix the issue with using external assemblies (i.e. assemblies not in the project folder structure).  In this example the project references the "Encompass" assemblies from the "C:\Program Files (x86)\Encompass" folder.  I wanted to use the program file reference so it’s easy to upgrade SDK; however, Visual Studio Project always have relative paths which doesn’t get resolved in TFS Build.  To resolve this I have add new registry key for the Encompass folder path on the TFS build server so that it looks into this location when it compiles any project.  Now I don’t need to change the project file. 

Registry key: HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > .NET Framework > AssemblyFolders

Add new key (in this case "Encompass") and then update the "(default)" string value to be the path to the assemblies (in this case "C:\Program Files (x86)\Encompass").

In some cases depending on the usage you may have a jQuery dialog open after the user clicks the Ok button; however, you may want to disable the button to prevent the user from double-clicking it.  Here are a couple of methods to achive this typ of behavior.  

Just disable the Ok button:

$(".ui-dialog-buttonpane button:contains('Ok')").attr("disabled", true).addClass("ui-state-disabled");

Remove all buttons and replace with a processing indicator:

$('#selector').dialog({
     title: 'Sample Dialog', 
     modal: true, 
     buttons: { 
       'Cancel': function() { $(this).dialog('close'); },
       'Ok': function() { $('.ui-dialog-buttonpane').html('<div style="width: 100%; text-align: center; padding: 20px; font-size: 20px; background: url(processing.gif) no-repeat;">Processing please wait...</div>'); 
     }
});

Windows event logs will typically capture user login/logout activity; however, it does not capture user unlocking/locking their computer (which quite often is the more frequent activity).  This C# code will run as a Windows service and add Information entries into the Windows Application log accessible via the system Event Viewer.  Currently the code currently has an error in implementing "System.Security.Principal.WindowsIdentity.GetCurrent().Name" as an attempt to log the user name performing the activity; however, that is actually simply logging the user name that the Windows service is running as.  In a future update I plan to fix this issue and add the actual user name to the log entry.

 UserLockUnlockProfiler.zipx (41.86 kb)