The title of this post comes from a staff member at a client of mine. We were discussing a possible project and the staffer was showing me how they did a particular task. They were using a web app that was going to a lot of trouble not to look like a web app: the users all had a shorctut on their desktop to launch a browser pointed at the site, most of IEs toolbars were suppressed so you didn't think you were even in a browser, and so on.

She performed a search, but before clicking the button she copied her search terms from the textbox, opened a blank Notepad, and pasted them in. "I'll explain that in a minute", she said. Then she clicked the button, and followed the link to the first search hit of twelve or so. On that page she made a small change, or noted down something she saw, something minor anyway. Then she said "Here's the frustrating part." There was no link back to the search results and the IE toolbars were all suppressed. So she used the nav bar links to go back to the home page, from there clicked a link to the search page, pasted in the search terms she had saved, did the search again, followed the second link this time (and the designer didn't like visited and non-visited links being different colours so she had to remember which one she was on) and round and round again.

So I asked "why don't you just use the Back key?" "What Back key?" She was on the second result, and I reached over and pressed Backspace to take her back to the search results. That's when she said "You just saved me an hour a day!" She didn't hug me, but she did something just as good -- ran around the office telling everyone else what she had learned. That particular project didn't fly, but I still do lots of work for that client. And those five people all have an extra hour a day for the rest of time.

What do you know that you're not telling users? Keyboard shortcuts, context menus, alternate ways to do simple tasks... share it!

I have a mentoring client who is doing a fair bit of Sharepoint work. Some of it I just do for them and install on their servers, but I'm working closely with a team of developers who are building up their skills on both development and administration, and putting sites into production for real people to use to do their jobs.

This client is a pretty large firm - a Canadian household name - and so in addition to a large team of developers they have an infrastructure team, the "downstairs guys" who configure and support all their servers. As the number of Sharepoint sites grows, we're having strategy meetings with developers and infrastructure people about how to handle the growth of Sharepoint within the firm.

So at one point in this meeting the infrastructure person says to me "I need some sort of reports, some way to know how big a site is getting. I can look at the size of the SQL database but it's not very accurate. Or when we do the backups I can look at the size of the backup file. But then how can I tell what the issue is -- maybe someone has turned on versioning or something else that eats up disk space." Various people in the room start talking about the Sharepoint object model, about pointing SQL Reporting Services at a Sharepoint data source, and other developer approaches to the problem.

Now earlier in the meeting several of the developers had been telling the infrastructure person that he has to come to grips with Front Page. There are some things that are really hard to do any other way, and really easy to do with Front Page. And as a result I had Front Page open on my laptop and had opened a site (our own Gregcons internal site as a matter of fact) but hadn't done anything in it. So during this conversation about how to know the size of the site, I clicked the Reports button on the bottom Front Page toolbar that shows when you've opened a web:

And what do I see when I click that?

I grinned and spun the laptop around so that the infrastructure person (and his grandboss, who was at the meeting with us) could see it. "You're going to have to learn to love Front Page," I told him. And to the grandboss I said "aren't you glad you have a consultant?"

A lot of times I work really hard and long to bring my clients value. But there are so many times when I can do something in 30 seconds that the client would have spent days doing another way. I love those times.

Say you have an application that uses P/Invoke (the DllImport attribute on an external method defined in a native DLL) to access some particular functionality. A lot of the use for this feature is to get to something in the Windows API that isn't exposed by the .NET Framework. But there are also folks using P/Invoke to call their own code from their own DLLs. The question then arises: where should you keep that DLL you're using (oh, please, not System32, anywhere but System32 -- years ago a buddy said "the registry is a giant and complicated database that tells you all your COM objects and DLLs are in System32") and how is it going to get deployed from your computer to wherever you install it?

If you try to add a random file to your manifest on the Publish tab of a Visual Studio 2005 Winforms project, you will discover there really isn't a way to do it. The file has to be in the project. You can add things to your manifest with MaGeUI (Manifest Generator with a User Interface, so named because MaGe is entirely command-line) which you can run from a Visual Studio command prompt, but most of us want to manage our manifests with Visual Studio. Heck, you could edit your manifest with Notepad -- it's only XML -- but that's not what I'd call the popular choice.

You could add the DLL to your project, but if it's under development, you're going to have to hand-update your copy when it changes, or your tests won't be accurate. And for a lot of folks, adding it to the project is going to mean adding it to source control, and binaries in source control does not sit well with me. Here's a better way.

Start as though you were going to add the DLL to the project. Right-click the project in solution explorer, Add, Add Existing Item, browse to where the DLL is, change the file type to All Files or Executables, click the file name - but don't click the Add button. It's a compound button, so click the little Arrow next to Add and choose Add As Link.

You should see your file added to Solution Explorer with a sort of shortcut symbol:

Click once on the DLL then bring up the properties for the file. Make sure Build Action is set to Content and Copy To Output Directory is set to Copy If Newer. (If the DLL is on the network, and you're working offline, on a plane or something, and you've built once so you have a copy already, you can flip this setting back to Do Not Copy so your builds don't fail.)

A word about "where the DLL is". If you develop alone, this can be some sort of c:\working\clientname\projectname idea, but for a team, that's not going to work. This path is going into your project file and you'll check it in to source control and the rest of the team will be using it. Unless you all have the same folder structure, you're going to want to use a UNC name. It's probably best to point it at a share where you publish the DLL after you build it.

Having added the file to the project, you can now make it part of what you publish. Click Application Files on the Publish tab and you should see it there. You might need to check the Show All Files box, but I didn't:

This isn't available in every kind of project -- I can't do it in a C++ WinForms app, for example -- and it doesn't really work for an ASP.NET app where there is no project file, just the folder. I think for those a pre- or post build step to copy the DLL from where you build it or from the share where it is published for all developers to use would be the way to go.

I installed Vista build 5365 last week. This was just a short time after putting 5308 on bare metal instead of a VPC. And now instead of just "checking it out" and "looking around" I was actually using the OS to do work, specifically writing code. (I was doing Word and Powerpoint work on my other laptop which is still on XP.) There's an interesting emotional thing that happens when you get out of the VPC and onto the metal, and especially when you stop demoing and start doing.

There are some things here I am just loving, somewhat to my surprise.

How long have I been annoyed by having to retype the extension when i rename a file? A decade at least. This is a tiny thing but ooo-weee I like it.

The easiest way to tell what I love is when I try to do it on my other machine and feel a momentary irritation when I can't:

This is a Windows Explorer and the address bar is all buttony and live. So I don't have to click up three times, wait while lists of things I don't care about update, and then drill back to where I want. I keep trying to do this on XP, I have it completely internalized already.

Like Scott Hanselman, I have a LOT in my Start menu. I like this in-place effect a WHOLE lot better than the cascading-off-to-the-side-forever approach.

One thing I was hating: where is Start, Run? I can't live without Start, Run! Turns out Windows-R still works. So does right-clicking on Computer and choosing Manage to get all the MMC stuff you need to admin your box.

Speaking of adminning your box, the User Account Control takes a bit of getting used to. More than once I have had to close Visual Studio and re-open it as admin so the COM component can get registered as part of the build process. But I am developing some habits there and expect to internalize those quickly too. I have a feeling we will all be on Vista sooner rather than later.

Kate

ps: don't draw conclusions about visuals from these shots, I don't have Glass on the laptop (it's an old one) and I don't have anything for screenshots other than Shift-PrtScr then paste into Word. It's nicer in person, really.

Martyn Lovell, who heads the libraries team, has an interview on Channel 9 that was posted Friday. Normally when you think "libraries" in the context of C++ you think ATL and MFC. But most of what Martyn is talking about here is the C RunTime library -- strcopy, printf and so on. He gives a coherent explanation of what the safer CRT work is about. I've written about this before, and have been helping mentoring clients fix their warnings for over a year, and still I learned a few things from this video about how to explain this initiative. Martyn's devotion to the language and the community is inspiring.

And yes, Martyn is hiring again. You can use the description and instructions from my previous post if you'd like to work on MFC. Over 7000 new APIs in Vista means there's lots of MFC work to be done!

Last night we had a community get together on the last day of VSLive. Billy Hollis, Steve Lasker, and Josh Holmes were there from out of town, and the Toronto .NET Glitterati (Rob Windsor, Graham Marko, Chris Dufour, Jean Luc David, Dave Totzke, Barry Gervin, Eli Robillard, and many others) as well. It seems that no-one had a camera along, so you'll have to take my word for it .

I got a chance to talk to Jerome Carron, who like me is speaking as part of the realDEVELOPMENT_06 tour in late May and early June. We will be seeing a lot of each other since we are also both going to be at DevTeach. If you haven't registered for either of these events, you really should.

I've been quiet lately because I've been preparing my slides for DevTeach and TechEd, and working on some material for a Vista Ascend that premieres in May. I also put a new Sharepoint site into production at a client -- and if you've ever had the delight of promoting a gaggle of web parts, aspx pages, and special versions of selected magical XML files all up to a production server from a staging server, then you know why I haven't had time to blog. But it works now, and the clients are all happy. Me? It's a good thing I know how to sleep on a plane.

The other day, my car overheated -- pegged the temperature gauge -- after about 5 minutes of driving. I limped it home and discovered it was out of engine coolant. After I added more I could drive for a few minutes but again it violently overheated and all the coolant was gone. With visions of expensive repairs dancing in my head I took it to my neighbourhood mechanic.

It turned out to be a cheaper repair than I expected, but a more frustrating one. You see, the minivan I was driving has a separate heating system for the back seats. Their own controls, vents, everything. We actually use this perhaps once a year, it's a low-value frill. But here's how it works: they pipe the engine coolant halfway back the car so it can go through a heat exchanger and warm up the air in the back. And of course it makes cars easier to build if all the pipes and wires are underneath the car. Over the years, kicked up stones and gravel weakened this coolant pipe until it finally broke, spewing precious engine coolant all over the road. I could have easily lost the engine or been stranded hundreds of miles from home. And for what? A separate heating system in the back? Who cares?

What could they have done instead? They could have piped the hot air instead of the hot coolant, so a leak would only make the back seat cold instead of ruining the car. (I know, from my former life as a chemical engineer, how much easier and cheaper it is to move liquid than air.) They could have installed a sensor that would detect low coolant levels directly, instead of indirectly when the car overheats. They could have run the piping in some protective shroud. (Ha! This is the company that blames me when the wiper motor breaks because the car gets snow and ice on the windshield! Three times so far on this van.) They could have skipped the whole feature on the grounds it made the car way too vulnerable for the benefit it offered.

I see a moral in this story for software developers. What features are you writing that turn out to be a heating system for the back of the van?

I've just updated the mentoring and consulting pages on our website. The mentoring offering is where I get most of my fun, so we've decided to emphasize it a little more. I even found out how to put flare on my blog. Tell your friends