Friday, May 23, 2008

IIS debugging macro

Usually developers use a single remote server while developing custom SharePoint solution. It means the developer tools and the server are not on the same machine. You can connect to the server after starting the Visual Studio Remote Debugger. Now you can attach debugger to the remote w3wp.exe processes. This process can be very annoying after a while.
It is a macro that will automate this process:
   1:  Imports System
   2:  Imports EnvDTE80
   3:  Imports System.Diagnostics
   5:  Public Module AttachToWebServer
   7:      Public Sub AttachToWebServer()
   9:          Dim AspNetWp As String = "aspnet_wp.exe"
  10:          Dim W3WP As String = "w3wp.exe"
  12:          If Not (AttachToProcess(AspNetWp)) Then
  13:              If Not AttachToProcess(W3WP) Then
  14:                  System.Windows.Forms.MessageBox.Show(String.Format("Process {0} or {1} Cannot Be Found", AspNetWp, W3WP), "Attach To Web Server Macro")
  15:              End If
  16:          End If
  18:      End Sub
  20:      Public Function AttachToProcess(ByVal ProcessName As String) As Boolean
  22:          Dim dbg2 As EnvDTE80.Debugger2 = DTE.Debugger
  23:          Dim trans As EnvDTE80.Transport = dbg2.Transports.Item("Default")
  25:          Dim Processes As EnvDTE.Processes = dbg2.GetProcesses(trans, "DOMAIN\USER@MACHINE")
  26:          Dim Process As EnvDTE.Process
  27:          Dim ProcessFound As Boolean = False
  29:          For Each Process In Processes
  30:              If (Process.Name.Substring(Process.Name.LastIndexOf("\") + 1) = ProcessName) Then
  31:                  Process.Attach()
  32:                  ProcessFound = True
  33:              End If
  34:          Next
  36:          AttachToProcess = ProcessFound
  38:      End Function
  40:  End Module

Change the "DOMAIN\USER@MACHINE" to your own ID. The DOMAIN\USER is the debugger user, the MACHINE is the debugging target machine. You can get this ID from Visual Studio Remote Debugger first log line or from a previous connection log line.

This macro is based on Howard van Rooijen macro implementation.

Localhost debugging: change DOMAIN\USER@MACHINE to empty string ("").

Developer (Visual Studio-integrated) server debugging: add WebDev.WebServer.EXE before If Not (AttachToProcess(AspNetWp)) Then like If Not (AttachToProcess("WebDev.WebServer.EXE")) Then

Link: View and download the script on Google Code [.vb]
Link: Attach to Web Server Macro for Visual Studio

Wednesday, May 21, 2008

Change ASP.NET User Control UICulture

Illlustration: language Sometimes you have to change the culture settings of a user control in runtime. Let's say we have to change the language of a login form on user click. Let's say we do not want to and cannot change the culture of the page (e.g.  the user control is embedded in a SharePoint page).

The first step is to create a Local Resource for the user control (.resx). Now it's possible to change the language dynamically.

The next step is to put buttons on the form and create event handlers for each languages. The standard code to change the culture is something like this:

System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("hu-HU");

Unfortunately we will not be successful this way.

The solution is to override the FrameworkInitialize() method and set the Thread.CurrentThread.CurrentUICulture inside that.

You will probably have to use Session state to store the current language. If we set the Session variable in an event handler, we will have to click twice on the button to change the language of the form. The trick is  the following:

Server.Transfer(Request.Url.PathAndQuery, false);

Now the user control will appear with the selected culture settings after pressing the button.