Gotcha running Subversion server on Windows Server 2008

I recently set up a new server in our office which should among other things act as a Subversion server.

I made a typical Windows 2008 Standard x64 installation and added only the Application Server role since we may run some ASP.NET applications on it.

I then started the Subversion installation by donwloading the SlikSvn command line package and installed it. I then added svnserve as a service using the excellent instructions on http://www.evanclosson.com/devlog/subversiononservercore. I found out that sc is VERY picky about casing and that there should be ONE whitespace after each equals sign.

When I started the service, I found out that I could not connect to it using TortoiseSVN from any other machine (I did not want to install TortoiseSVN on the server since I want the server to be as clean as possible). I then checked all firewall settings and so on since I thought that it might be a blocked port that was causing the problem, but I could not find any problems.

I then tried using svn from the command-line, and that did work if I specified the host as hostname, but not with IP 127.0.0.1. After som googling (is that a verb?), I found that by default, svnserver only listen to default protocol, which seems to be IPv6 och Windows Server 2008. I I the added the svnserve option --listen-port 0.0.0.0, Subversion started listening to IPv4 requests.

So currently I have the following binPath argument to sc create:

"C:\Program Files\SlikSvn\bin\svnserve.exe" --service --listen-host 0.0.0.0 -r d:\proj

I guess this problem/issue/quirk is the same on Vista as well.

Autocomplete in ASP.NET TextBox Gotchas

When creating a textBox that uses Automplete behaviour with e.g. ASP.NET Ajax AutoCompleteExtender, you probably want to disable the browser's autocomplete feature to avoid that you get double autocompleters; one from the browser and one from the AutoCompleteExtender.

To do this in HTML, you add a autocomplete="off" attribute to your input box. But how to do this when we are working with ASP.NET:s TextBox control?

The ASP.NET TextBox control has a AutoCompleteType property that can control the autocomplete behaviour:

<asp:TextBox AutoCompleteType="AutoCompleteType" />

The problem with this is that it does not work in FireFox. It generates a autocomplete="off" attribute to the input element in IE, but when using FireFox, there is no autocomplete behaviour at all.

The solution to the problem is surprisingly simple (but not very well documented at MSDN):

<asp:TextBox autocomplete="off" />

Just put the autocomplete attribute in the asp:Textbox element. This will work since according to MSDN: "Any attribute you add to a control that does not map to a property of that control is passed through to the browser."

Listing process IDs for IIS application pools

When working with ASP.NET applications on a server that runs several ASP.NET applications, You once in a while end up troubleshooting which of the applications that are using up all the CPU or memory.

The problem is that in Windows Task Manager, You only see a bunch of w3wp.exe processes. You cannot see which application pool each process is.

To our help, we find the iisapp.vbs script that lists all applications pools and their process ids. A simple bat file that You can put on You desktop contains he following commands:

cd \WINDOWS\system32
cscript iisapp.vbs
pause

Since You can see the process id in Windows Task Manager, we can now identify which application to blame (since You run each application in it’s own application pool, don’t You?).

Wrong URL:s in WSDL for Web Service implemented with WCF

If You expose a WCF web service in the following way:

• The external name (on the public Internet) is webserver1.mycompany.com
• The internal machine name (in my company’s internal network) is www_1.mycompany.local
• The service path on the server is  /MyService/MyService.svc
• The web site that the service resides in does not have any host headers defined.

If You browse (using a web browser) to the URL

http://webserver1.mycompany.com/MyService/MyService.svc,

You will see that the suggested URL to the WSDL is

http://www_1.mycompany.local/MyService/MyService.svc?wsdl .

If You ignore the incorrect URL and browse to

http://webserver1.mycompany.com/MyService/MyService.svc?wsdl (the correct URL for the WSDL), You will see that also the WSDL says that the web service is located at http://www_1.mycompany.local/MyService/MyService.svc.

The problem is that WCF does not realize that the URL of the web service is the external address.

The solution is pretty simple: set correct host header for the web site:

webserver1.mycompany.com for port 80 (and port 443 if You are about to expose the web service using SSL, which You should).

Restart the application pool and reload the service page in Your browser and everything should be fine.

Cannot debug with VS.NET 2003?

Suddenly, I could not debug anything at all in VS.NET 2003. Not Web Projects, not simple C# applications, not anything.

The error was Unable to start debugging. Access is denied. And then a rambling of "make sure that You are a member of Debugger Users group or Administrator". But I was member of both groups.

Lots of googling later, I found the answer: it appeared that the Machine Debug Manager service (a process that helps he debugger to locate and attach to other processes and runs as a service) for some reason had stopped working. The service seemed to be running OK when I looked in Services, but I had an entry in the Event log that made me think otherwise:

Event 10023, Source COM:
The application-specific access security descriptor for the COM Server application C:\Program Files\Common Files\Microsoft Shared\VS7Debug\mdm.exe is invalid. It contains Access Control Entries with permissions that are invalid. The requested action was therefore not performed. The application set this security permission programmatically; to modify this security permission contact the application vendor.

A bit more googling and I found a solution:

1. Stop the Machine Debug Manager Service.
2. reregister the mdm.exe COM server by entering mdm.exe /regserver at the command line
3. Start the Machine Debug Manager Service again.
4. Voila! Debugging works.
   

The only thing that bugs me right now is that I do not know what caused it to stop working since I suspect that it will happen again at the worst possible time.