Fix: Cannot import the following key file

Here’s another quick fix for a small issue you may encounter when upgrading your project to Visual Studio 2010.  You may find that the import works okay, but when you go to compile, you get the following error message:

Cannot import the following key file: keyfile.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_0123456701234567

The cause of the error is exactly as Visual Studio described: it can’t open the key file it needs to access because the key file is password protected.  The suggested fix, however, is not likely to set you on the right path.  In fact, Visual Studio should really just fix this itself.  In previous versions, it would.  Remember you’d occasionally get a password prompt when opening a project for the first time?

Well, all we need to do to fix this is trigger Visual Studio to ask you for the password.  Then, it will do its thing and you’ll be set.  Try this:

1. Open Project Properties.
   
2. Click on the Signing section.
   
3. Where it says ‘Choose a strong name key file:’, reselect the current value from the drop-down box:
   
   
   
4. Visual Studio will now prompt you for the password.  Enter it.
   
   
   
5. You might get another error message:
   
   ”An attempt was made to reference a token that does not exist”
   
   If so, just ignore it.
   
6. Click the ‘Change Password” button:
   
   
   
7. Enter the original password in all three boxes and click OK. If you’d like to change your password (or if your old password doesn’t meet complexity requirements), you can do so now.
   
8. Repeat for each key file in your project.
   
9. Save your project and do a rebuild.

Of course, there are less empirical ways of solving this, but they involve using the signtool.exe application and messing around with the certificate store.  This might not be the most impressive way of solving this problem, but it seems to work.

Fix IE9 Address Bar Search

So the IE9 beta is out.  The rest of the Internet is busy reviewing it today, so I won’t bother.  I will, however, show you how to fix one little problem.  It has to do with a little-used feature that I happen to use from time to time: searching.

IE8 had separate text boxes for entering an URL and entering a search query.  This made it simple for developers, but it kind of sucked for users.  Really, by 2010 I kind of thought my web browser would know how to figure out the difference between www.microsoft.com/msdn and “Microsoft MSDN” and choose whether to navigate directly or search accordingly.  Google Chrome really upped the game here: there’s one box, and it always seems to know exactly what you want to do.  It’s still the best implementation of an address bar out there, in my opinion, but IE9 is certainly catching up.

Under IE9, if you type an address, it works.  Wonderful.  But if you type something that’s not clearly an address, one of two things happens.  Either you’re brought to a search results page (from Bing, Google, or whoever else you’ve chosen to use) or – if there’s a really obvious ‘best’ search result – you’re taken right to the site you obviously wanted to go to.  This sounds nice, but when I type something that’s not an address, I want search results.  If I wanted to go to www.linux.org, that’s what I would have typed, so why doesn’t “linux” take me to my search results page where I can click on the Wikipedia article?

Luckily, this behavior can easily be changed.  When I first started looking into this, I expected something ugly… maybe even as bad as writing my own search provider.  But the solution is really simple.  Obscure, perhaps.  But simple.  Here’s how:

Click the “Tools” button (the gear at the top right of the window), and then click “Manage add-ons”:

Now click on “Search Providers”, and then select Google (or Bing, or whatever else you use):

See the “Disable top result in address bar” link I highlighted?  Click it.  Then click Close.  That’s it!  Now, you’ll always get search results (unless you typed an address, in which case it will go where you told it to).

When I first ran into this, I started to rant a bit.  But after figuring this one out, I have to admit that Microsoft got it right.  They set up the default setting the way the unwashed masses will like it, they made it nicely configurable for those who want it to work a specific way, and they kept the details out of the way until needed.

Choosing a .NET Framework Version

Whether you’re starting a new project or just releasing a new version of a tried-and-true application that’s been around forever, one major decision you need to make – and make right – is the framework version you choose to target.  This is more complicated a question today than ever before, but since the release of .NET 4, there are good choices available regardless of your scenario.  Here’s a quick guide:

.NET 1.0

This is now completely obsolete.  Don’t use this for new projects.  Ever.  If you’re supporting an application that uses this, at LEAST upgrade to 1.1, and ideally, 2.0.  It’s generally that not hard, and the 1.0 release of .NET has some ugly little surprises hidden away, just waiting for the opportunity to ruin your week.  Microsoft no longer supports this version, and yes, there are serious bugs.

When to use:

• Never.

When to upgrade:

• Long, long ago.

.NET 1.1

This is pretty old.  Don’t use this for anything new, and avoid active development on this platform. It’s still safe to use, though, so feel free to maintain code running on this for another few years.  In fact, this was the first version of .NET to be included with an OS (Windows Server 2003), so Microsoft will continue to support this until 2015 at least.

When to use:

• Your application must support Windows NT 4.0.
• Maintaining applications for which active development has ceased.

When to upgrade:

• Immediately, if active development continues.
• In the next few years, if long-term support is required.

.NET 2.0

I love this release.  This is when .NET came of age, and it’s still used all over the place.  As I’ll describe below, there are even reasons why you might want to base new development on this release.  Sure, it might not have all the fancy new features the newer releases include, but the core functionality is rock solid, and everything you need for a simple, timeless, reliable application is there.  It’s the last .NET release to run on Windows 2000, and if will even work under Windows 98 (do people still use that?).  The installer is just over 20 MB, and installation is pretty painless, but most modern computers out there will have this installed already.  Upgrading from .NET 1.x to 2.0 is usually pretty smooth.

This is also a great version of the framework to choose if you’ll be supporting Mono (which allows your code to run on a variety of devices and operating systems, including Linux and MacOS).

When to use:

• Your application must support Windows 98, Windows ME, or Windows 2000.
• You want to avoid requiring .NET Framework updates as part of your deployment process as much as reasonably possible.
• Maintaining applications built on .NET 2.0 or earlier.
• Your application must run under Mono.

When to upgrade:

• Active development continues, and you want access to features available only in newer versions of .NET.

.NET 3.0

This is where things start to get ugly.  .NET 3.0 is actually not a full release of the .NET Framework.  It’s really just .NET 2.0 plus some new technologies thrown in (WPF, WCF, WF and a few other oddities).  This version was included with Windows Vista, but was never really popular with developers.  Unless you know exactly why this is the version you need, you should avoid this one.  It’s just… weird.

When to use:

• You require features not available in .NET 2.0, AND your application must not require Framework updates, AND your application will only run on Windows Vista or newer.
• Maintaining applications built on .NET 3.0.

When to upgrade:

• Now, if active development continues (unless you really know why you’re using 3.0)

.NET 3.5

The Beast.  I really hate this release.  This version continues the weird existence of 3.0.  It’s really just good old .NET 2.0, plus a bunch of changes and additions.  As a developer, there’s a lot of new stuff here since 2.0 (LINQ is introduced, WCF and WPF are a bit more usable, ASP.NET includes AJAX support, and there are a bunch of other new toys and language improvements to play with).  But administrators have learned to hate this release.  The installer is over 230MB, can take HOURS to run, and often requires several reboots.  Automated deployment is an absolute joke; it’s probably easier to upgrade the entire OS than get this release out over group policy (see http://msdn.microsoft.com/en-us/library/cc160717(VS.90).aspx, and check out the bitching in the comments).  I was involved in an upgrade project where updating one single server turned into an overnight ordeal, and pushing updates through group policy, WSUS, or any other modern management software was abandoned in favour of walking around to each and every machine.

This was the latest version of .NET for several years, and it presented a real dilemma for developers: a) stick with the tried and true .NET 2.0 and make do without any enhancements introduced since 2007, b) move to 3.5 and deal with the endless problems associated with the upgrade, deployment, and support processes, hoping the next version wouldn’t be even worse, or c) abandon all hope, give up on .NET, and move to a different development platform.  I struggled with this dilemma for a couple years myself – and don’t forget, this was the Windows Vista era.  Microsoft seemed to be losing ground on all fronts, alternatives looked better than ever, and the future was really tough to call.  I spend serious time playing around with alternatives to .NET, and decided I’d give Microsoft one more release to make things right.  If they didn’t, I would have to start moving away from Microsoft technologies.

As I said: this one is The Beast.

When to use:

• You require features not available in .NET 2.0, AND your application must not require Framework updates, AND your application will only run on Windows 7.
• Maintaining applications built on .NET 3.5.

When to upgrade:

• Now, if active development continues (unless you really know what you’re doing and you don’t care about the pain you cause your users and administrators).

.NET 3.5 Client Profile

This was an attempt to deal with the horrific 3.5 framework size and updating process.  The Client Profile is a subset of .NET that includes just the functionality typically required for client applications, and does not include any server functionality.  Unfortunately, it doesn’t do much to solve the original problems, and brings a new range of pesky little quirks.  Also, there’s a good chance you’ll run into a situation in the middle of development that requires a feature not available under the Client Profile.  I generally advise ignoring this one.

When to use:

• You must use .NET 3.5, and are certain you require only the reduced functionality included in this release.

When to upgrade:

• Now, if active development continues.
• Upgrading to the full version of .NET 3.5 is usually about three clicks, so feel free to do this if you run into a Client Profile-specific problem.

.NET 4.0

The latest, the greatest, and a long-overdue upgrade everybody should get behind.  This is the first true update to the CLR since .NET 2.0 was released.  It includes all the developer magic released in 3.5, adds more toys and polish, brings some very welcome language improvements, improves performance and security, makes WCF usable, makes WPF almost bearable, and generally makes life much happier for everyone.  Use it.  Love it.  Preach it.

The full installer for .NET 4.0 is less than 50 MB, and there’s also a web installer that will download just the required components.  Installation is generally pretty painless, but can occasionally require a reboot.  You can also get this update through Windows Update or WSUS.  Side-by-side installation with previous versions works, and works well.

When to use:

• You don’t need to support pre-WinXP machines.
• You don’t mind requiring your users to install a (simple and easy) framework update.

When to upgrade:

• Not for close to a decade at least, I’m guessing.  This is the one to go with if you hear people start to talk about ‘Future Proofing’.

It’s not always a good idea to change tools in the middle of a project, so depending on your restraints, you might not be able to make the leap right away.  But upgrading between .NET Framework versions is usually easy, and .NET 4.0 is well worth it.  Do note that your clients will need to have Server 2003 or Windows XP available (with certain service pack requirements).

.NET 4.0 Client Profile

The Client Profile is also available under .NET 4.0, although the installation package is only about 10MB smaller.  I don’t really see the point to this, but it’s there if you want it.  It might be wise to start development under the Client Profile so you have the option to go both ways, and then move to the full version of .NET 4.0 if the need arises.  Or, you could just ignore it.

When to use:

• Hell if I know.

When to upgrade:

• You need something not available in the Client Profile.  Luckily, this is still a three-click task.

Of course, if you have a specific scenario that you think calls for a different version than this guide might suggest, go nuts.  Just be sure you know what you’re getting yourself into, and don’t forget: you might finish developing your application, but you’ll never finish supporting it, so be sure you consider deployment and security as part of your selection.

Quick Fix: “Find in Files” Button is Disabled

Okay, so this is a pretty simple one.  Perhaps I should have figured it out way, way faster than I did, and perhaps nobody else will ever have trouble with this, but I never promised to be helpful.  Or did I?

Anyway, here’s a pretty common scenario (around here, at least):

1. Fire up Visual Studio 2010.
2. Hit CTRL + SHIFT + F to bring up the Find and Replace dialog in “Find In Files” mode.
3. Type a keyword that will bring up the area in your project you want to work with.
4. Hit Enter.
5. Wait.
6. Finally notice that nothing is happening.
7. Hit Enter again.
8. And again.
9. Mumble “What the hell…?”
10. Reach for your mouse.
11. Notice the “Final All” button is disabled.
12. Say “What the hell?” a bit louder.
13. Click the button anyway.  (Nothing happens.)
14. Stare at monitor with angry / confused expression.

Here’s the problem: in Visual Studio 2010, the “Find All” button isn’t enabled until you’ve opened a text file of some description.  Once this happens, it will stay enabled until you close Visual Studio, even if you don’t have any documents open.  Yeah, it’s a bug.

Here’s a workaround:

1. Open any text document (code file, XML file, whatever).
2. Hit CTRL + SHIFT + F to re-open the Find and Replace dialog.

If you’re looking for a quick keyboard fix, try CTRL + N, ENTER, CTRL + SHIFT + F, CTRL + F4.

And please, if this helps you, leave a comment and let me know.  I’d really like to hear that I’m not the only person this bothers.

Visual Studio is Getting Expensive

Microsoft has made a lot of mistakes in its day, but one thing it’s always done right is to treat developers like royalty.  Giving developers really compelling reasons to choose Microsoft ensures that enterprises and consumers keep choosing Microsoft too, because that’s where all the programs are.

One of the best ways Microsoft does this is with Visual Studio.  It is the best development suite on the planet, bar none.  It lets developers make better products in less time, and it makes them not hate their jobs.  It keeps programming ‘fun’.  And traditionally, Microsoft has practically given this away.  Sure, if you walk into a store and look for a shrink-wrapped copy of Visual Studio, it’s pricy.  But nobody does that.  Through the Empower program, MSDN subscriptions, and more, Microsoft has kept Visual Studio very affordable, and takes off all the restrictions placed on mere mortals.  Which is good: developers are probably the least likely bunch of people to pirate software, and they don’t have time to worry about things like licenses and product activation.  They’re not using these products.  They’re building on them so other people can use them.

But this is changing.

Now, developers have to choose to either live with an ‘inferior’ version of Visual Studio, or pick which ‘Team’ edition to go with.  I’m sure the marketing department was really proud of the work they did identifying their market segments, but you know what?  That doesn’t work with developers.  Am I a Software Architect?  A Database Developer?  A Test Engineer?  It really depends on which day it is, but most often, I’m all of these.  And I really don’t like having to choose which features I want to live without, because this is exactly what is happening here.

Sure, I could go for the uber-premium ‘Team Suite’ edition, which does have it all.  But that costs many, many thousands, which is well beyond what any mere mortal can afford.  In fact, it’s a pretty good part of an annual salary most places in the world.  Visual Studio is great, but it ain’t that great.

And worse: the usual channels that developers used to avoid paying retail are slowly being closed, or at least weakened: most of these offerings no longer come with the top-tier edition.  More and more software is unavailable to developers through MSDN subscriptions (such as the Expression products), and often, developers can’t even get into beta programs.  I develop solutions that use Microsoft Office every day, and I didn’t see the web-enabled versions of these until public release.

All of this is happening at a time when the alternatives are getting harder and harder to ignore.  Macs are becoming a significant market segment again, much of the Linux world has rallied behind the fantastic Ubuntu distribution, and the development tools for non-Microsoft platforms are getting pretty damn good.  Sure, I’d rather use Visual Studio.  But by the time I’m paying more on Visual Studio than my rent, I think I can probably learn to live with Eclipse.  And if I do that, my products probably won’t require Windows anymore.  And if they don’t, neither will my customers.

I really hope Microsoft wakes up here.  These higher prices probably look good on a balance sheet; I’m sure the developer tools division at Microsoft is pulling in huge amounts of cash.  But this is a strategically damaging way of increasing revenue: you get a relatively small, yet concrete and immediate, gain in one corner, but you’re slowly, surely, weakening your entire foundation.

Microsoft: give us developers a break.  Try going in the other direction: give us more for less.  We’ll respond in kind.