Net Industry

Getting Subversion & Remote Debugging (SVN) Running with ASP.NET

Goals of this post:

To get a testing server (Microsoft Windows Server 2003 Web Edition) running configured with:

1. SQL Server 2000
2. ASP.NET 1.1 ( with remote debugging enabled)
3. SSL for security
4. Subversion 1.12 for Version Control

1. SQL Server 2000

Well, let's get you out of this illusion, because it's NOT going to happen. Maybe you're just like me and just looked real closely over and over again at the comparison chart of Windows 2003 editions and thought that this time you install software that is NOT the full-blown bloated ultra-large-universal-enterprise-architect-edition version that you usually need because there's this tiny-little feature that you absolutely need, even if you're not a universal-10000-employees (idiot-collegues)-that-you-need-to-collaborate-with-sized-enterprise, there was absolutely nothing that you would ever need that this edition lacks.

You should have known better. In the case of Windows Server 2003 Web Edition, you probably never watched the Overview of Windows Server 2003, Web Edition that will tell you exactly what you need to know (header "limitations") : Do not use Windows Server 2003 Web Edition.

Well, that's too late for that now, so you'll have to settle for Microsoft SQL Server: MSDE 2000 Release A

I think that Microsoft thought that whoever runs a website would probably never need a database. "For what? C'mon there's frontpage right? Everybody can work with that!". Let's put that on this list above the "640K ought to be enough for anybody"-quote.

One of the other great features of Windows Server 2003 Web Edition is that you can't set up a domain controller either! But we'll get to that fun in the next part.

2. ASP.NET 1.1 ( with remote debugging enabled)

Well, the first part (outside the parentheses) is easy! You just have to run this command (no it doesn't work out of the box, with me at least):

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322>aspnet_regiis.exe -i

The second part (debugging), I never got running, probably due to some error in the deep dark caves of COM+, 'Access Denied'. Just read and enjoy the fairytale '1001 problems that can cause the same error message while debugging ASP.NET' and try them all out, but it's NOT going to happen pal. I've been Googling for 2 days to solve this problem, but ultimately I think it's because I'm not in the same domain as the server. Actually, there is no domain, and our beloved Windows Server 2003 Web Edition does not enable us to set one up.

If you want to save time, just keep the debugging restricted to your laptop.

Some tips and best practices you can try if you don't get it running:

• Install Visual Studio 2003 on this server, and run it with remote desktop (no I'm not kidding, this is actually a Microsoft solution for remote debugging over the Internet or across domains). Alternatively you can just install the .NET FrameWork SDK
• Disable all firewalls and other useless security restrictions.
• Enable the guest account, and just put every user, including the 'everyone' and 'guest' in the 'Administrators' and 'Debugger Users' group. No one is ever going to find out your server is that unsecure. And then again, who cares, if something goes wrong, just blaim those "damn-smart-(they-must-have-put-a-lot-of-work-in-that)-hackers"
• Enable frontpage extensions for all webs, uninstall the IIS Lockdown tool, and never run any updates because it might hurt your precious configuration.
• Make sure that in your production environment every setting is the same as above, to make sure you're website keeps running.

3. Subversion 1.12 for Version Control

Download and install. This is easy. Figure it out for yourself. It's well documented.

If you're running it on a server, you don't want to be logged in all the time, so use SVN Service Wrapper for Windows.

The only problem is with Visual Studio .NET 2003, because every website that you try to open with Visual Studio will give the error "Unable to retrieve folder information from the server with my ASP.NET web project", because it doesn't like folders that start with a dot(".") like ".svn" that is used default by TortoiseSVN.

By the way, I didn't have this problem when I was still working remotely on my testing server! Interesting right...?

Lucky you, they created a special version for you! search for "TortoiseSVN for Win2k/XP ("_svn" version) " in here, and read here for more info.

If you've already checked out your repository and now stuck with ".svn" folders, just use my little Delphi tool SVNRenamer, wich will rename all .svn folders to _svn.

Conclusion

In this article we've learned some very useful worst practices and don'ts:

• Don't read all the related information of software before installing or buying it, EVEN if it will take you days. It's not worth it, believe me.
• Installing ANY other version of (especially Microsoft-) software than the most bloated, fat and expensive version available (mostly denoted by a very misleading 'Enterprise' classifier, because even a 1-man team will need this one)
• Trying to get Sql Server running on a W2K Web Edition machine
• Debugging ASP.NET on a Remote Server
• Don't think Microsoft Visual Studio introduced the .svn folder bug on purpose. There's no way they want to discourage unix-like paths in Windows. Try to create an empty .htaccess file in explorer, it works great!

posted by Wiebe Tijsma @ 2:06 PM