Here's just a little helper for you if you want to Remote Desktop through firewalls. There's a lot of info out there on this subject, but it's often quite hectic.

The only port the remote desktop protocol (RDP) needs is TCP port 3389 in and out. Many routers do port forwarding so if you have a machine on a LAN behind a firewall you can get to it via this protocol. For example, at home I have an Inventel Livebox from Orange. Using the config site for the router, I opened 3389 and pushed it through to my main server viathe LAN IP.

Now I can just connect to my internet IP or hostname using Remote Desktop and I get pushed straight on to my server. (here's another tip if you're using an Orange Livebox with a dynamic internet IP... the livebox supports auotmatic updating of Dynamic DNS such as dyndns, which I use... so all I need to do is connect my RDP client to danmatthews.dyndns.org and I don't care what the IP actually is!)

I don't know about you, but I've had an utter nightmare trying to debug .NET 2.0 web applications across domains. Despite literally every trick in the book (such as creating local users with same username/password) I just could not get breakpoints to be hit. Using native (no auth) debugging, I could attach to the worker processes but symbols just were not loaded, no matter what I did.

It was when I found myself in the depths of dcomcnfg mucking around that I eventually decided that there must be an easier way. Then it hit me. I'd been so busy trying to go across domains (I could not change the domain of my dev machine or the server) that I didn't think about virtualising a development box.

One quick XP Pro build later on a Virtual PC, and one rather tedious VS.NET 2005 SP1 install (allocate at least 512Mb RAM - trust me) and I could hook that onto the same domain as my dev server.

Works a treat - but here's a tip that I haven't found elsewhere. Despite the fact that the debugger runs as a service, I found that I had to run the debugger monitor in order for VS2005 to ge able to connect. No idea why - doesn't seem logical. The other issue is that the debugger monitor has to start a named server that matches the name you're connecting with. You could run a term services session to the server logged in as your domain account, but lets face it, thats a pain. Also, you could only connect a couple of people before hitting your term services session limit, which means you'd be limited as to how many people could connect at once.

Thankfully, you can name the debugging 'server' you want to start. So... you can log onto the server as, say, a domain admin, then start up multiple remote debugger monitors. In each, go to Tools -> Options and set the Server Name. I found the syntax had to be DOMAIN\user@server-machine-name, e.g. BUSINESSDECISION\danmatthews@WEBDEV01.

Remember to close your term services session by disconnecting, not logging out. That way, your monitors keep running.

Remote debugging can be a pain but using this virtualisation technique I just sidestepped all the nasty pitfalls and went the simplest route possible. If you can run a dev image on VPC maybe it can work for you too. Good luck!

Interesting to see that the authors, Tony Northrup, Shawn Wildermuth et.al., insist on referring to the 'using' statement as the 'include' statement throughout the book. Leastways, the eBook does, the print version seems to be corrected. My edition is anyway. Look at page 383 - Thread lab.

Evidently we have developers of the C rather than VB background here ;)

...and straight off I have something to share with you :)

If you're installing using EPiServer manager and using SQL Server 2005 Express, you need to be aware of the following, otherwise you get all sorts of 'SQL Server unavailable' and user authentication errors:

1) Make sure you NAME THE INSTANCE in the install, otherwise it will install on your default instance (which in my case, stupidly, was an MSDE instance!)

2) Make sure you have both Shared Memory and TCP/IP turned on in your SQL2005 Configuration. The installation uses Shared Memory, but the site itself uses TCP/IP.

3) Make sure mixed-mode authentication is turned on for your SQL Express instance

4) Make sure that your website is running as ASP.NET1.1 during the install (do the .NET2 templates and stuff afterwards)

OK, so I'm back again from my enforced travels, and being thrown straight into some EPiServer work. Business & Decision are EPiServer partners, which is good news for me because now that MCMS has been ditched, we see a gap in the market for SMEs who only want CMS and feel that MOSS would be a sledgehammer to crack a nut (and at approx 30k entry license, they'd be right!).

I think it's going to be interesting working on this project, and as usual if I find interesting tidbits I'll post them up here.