Why does Visual Studio Intellisense stop highlighting the suggested completion?

This has happened to me quite a few times, and the answer is annoying simple, and annoyingly hard to find.

When I am typing code in Visual Studio, particularly in C#, I’m very used to the way Intellisense usually works. I type a couple of characters of a method name, for example, and Intellisense shows the completions it can find, with the most likely item highlighted. At that point, it will fill in the completion if I type Enter, or an opening parenthesis, or a dot (if it’s a property – basically whatever the next symbol after the name I want it to enter.

But sometimes, seemingly randomly, it stops highlighting the suggested completion. It’s still the selected item in the dropdown, but now it’s merely selected and not highlighted, and to use it I have to type Tab, or hit the down arrow to highlight it then type the next character after the name. It’s different, not what’s in my muscle memory for typing code. And I could never work out quite why it happened.

I think, previously, I’ve had to completely nuke my Visual Studio settings to get the old behaviour back, which obviously I don’t really want to do. I assumed this was some kind of bug.

But I think I’ve found out why it’s happening, and the VS command to revert it.

The setting is not found in Tools->Options->Intellisense where I was looking, which explains why I didn’t find it.

It’s actually in Edit -> Intellisense -> Toggle Completion Mode, a simple toggle of this behaviour. And it has a shortcut – Ctrl-Alt-Space. I think it’s the shortcut that’s been causing it, as that might possibly be a key combination that I can hit accidentally, although rarelt enough for me not to notice.

But now, I hope I can remember where to find the option. Writing this entry is an effort to make it stick in my memory.

Thanks to Machet on Stack Overflow for pointing the way.

https://stackoverflow.com/a/26788848/6483

 

Updating Angular: Why do I get the error Prerendering failed because of error: TypeError: Object prototype may only be an Object or null: undefined at setPrototypeOf (native)

Do I win an award for the longest, most boring blog title in the world?

I’ve been doing some work with Angular recently, using Steve Sanderson’s excellent templates for ASP.NET Core.

It’s been interesting, since I’m not a client-side type, so a lot of the ceremony involved is a little alien to me. That mostly means that when things go wrong, it’s a bit harder to diagnose where I’ve made a mistake, but I’ve been doing OK.

Where I’ve been really struggling, for several days now, is in trying to update the Angular package versions I’ve been using.

In my innocence, I had wondered if all I needed to do was change the version numbers in the package.json to the new version. I needed to bump up the minor version to take advantage of improvements in the animation APIs.

But this naive approach left me with an application that was just broken, but broken in a way that gave almost no clue as to the reason.

The error that I was seeing, generated by the pre-rendering being done by the javascript services that are part of the template site, was this:

Exception: Call to Node module failed with error: Prerendering failed 
because of error: TypeError: Object prototype may only be an Object 
or null: undefined at setPrototypeOf (native)

This is about the most generic, information-free error you could imagine. Even with the associated stack trace, I didn’t have a clue what it meant, nor how to track it down.

But I did, just now, discover what I think is the core reason why the build was failing.

The reason is that the template does some clever stuff under the hood, to enable hot module replacement as you’re developing, but if node modules change, that’s not enough, and the key part of the build isn’t happening – webpack isn’t packaging up the code again.

I seem to have fixed the build by invoking webpack by hand using the following two commands:

• webpack --config webpack.config.vendor.js
• and then
• webpack

This rebuilds the files that contain the code for the site, in the dist folder in ClientApp and wwwroot. They’re also not tracked by source control, so they can end up missing if you’re cloning a repo.

Important safety tip: If you’re updating version numbers in Package.json, either do it with the solution closed, or let Visual Studio run the npm install. I’ve made the mistake of editing the packages, then trying to npm install from the command line, and that means there’s two installs happening, and they end up fighting with each other.

I still don’t know why these webpack rebuilds weren’t happening with the default setup of the project. I’m assuming it’s only something that should happen when packages update, but it does have the nasty effect of leaving your project badly broken, such that even if you revert the package version changes, often your dist files are still really broken.

Expression Blend 3 and Visual Studio 2010 RC

I installed VS2010 RC several weeks ago, and I’m now using it as my principal Silverlight dev environment. However, the sacrifice I made was that I could no longer use Blend 3 on my Silverlight 3 projects because the solution version number had changed.

I was wrong.

True, when you load your solution into Blend, it does complain that it’s a newer version, and might not work, but if you continue, Blend will successfully load a Silverlight 3 project. I tried two different projects, one which had been converted from VS2008 to VS2010 – which loaded properly – and one which I had created from scratch in VS2010. This one failed to load the web project, probably because VS2010 had created a .NET 4 web project, which Blend can’t load. But since Blend doesn’t care about the web project, this wouldn’t prove a problem.

So that’s useful – I can now use Blend again without resorting to weird hackery.

Of course, in just over a week, we might well have new versions of all the Silveright tools, as Mix10 opens in Las Vegas (I’ll be there!) and, if Microsoft follow their usual pattern, they’ll announce Silverlight 4 RTW. I think a lot of people will be disappointed if the tools aren’t available as soon as the announcement happens, although it won’t coincide with the RTM of Visual Studio 2010, because that launch isn’t scheduled until April (and that’s a launch, not necessarily the RTM date).

‘Cannot register duplicate name ‘XXX’ in this scope’ in VS 2010

Here’s a gotcha that was puzzling me yesterday.

I’ve just installed Visual Studio 2010 RC, and was trying it out on my current project. It’s a Silverlight Navigation-style project, but that’s not important to the bug.

I found one page where the Xaml designer wouldn’t handle the page properly – it was throwing exceptions, and the editor was showing an error in the Xaml. The line looked like this:

<local:SimpleConverter x:Name="SimpleConverter"/>

This is a value converter, designed to convert bindings from one type to another. The error it was showing was ‘Cannot register duplicate name ‘SimpleConverter’ in this scope’. This foxed me for a while – I thought perhaps because I was throwing exceptions when I didn’t recognise the type being converted, but even removing that and simplifying didn’t remove the error.

Then I noticed the key word in the error message: ‘Name’.

In Xaml you can use x:Name if you want something in the Xaml linked up to a class variable in your code-behind. But that was clearly causing issues with whatever the designer was doing behind the scenes. However, if you don’t need code-behind access (as I don’t in this case) you can use x:Key – and that’s the usual mechanism for naming resources.

Changing the resource to:

<local:SimpleConverter x:Key="SimpleConverter"/>

then the errors from the visual designer stop happening.

Of course, I’ve no idea if the errors are a bug in the designer, or if it’s just wrong to use x:Name in resources, but since I didn’t need the autowiring up of objects, it’s no problem to change it.