« Home | AOP and .NET » | Microsoft Developer Target Profiles » | dotnet.tv » | DiffDebugging » | Whidbey Class Designer » | Monad/MSH » | The API War and Microsoft » | Carpal Tunnel » | Agile UML » | Disrespecting UML »

VS.NET Addin Weirdness

Recently I experienced some weirdness in the Visual Studio.NET 2003 source code editor. The problem only occurred when editing C/C++ files and consisted of symptoms like being unable to select a large block of text with the mouse and popup dialogs appearing but not being able to retain keyboard focus. Fortunately, this resulted in a strong sense of deja vu and the VS.NET add-in list was checked for recent changes. The recently installed Xheo licensing package had also installed a VS.NET add-in. Disabling the add-in made the C/C++ editing weirdness disappear immediately.

The add-in was quickly identified as the cause of the problem, because I had similar problems with the Active Reports.NET integration into Visual Studio.NET 2003 a number of months back. Unfortunately at that time, I spent around a month with weird editing hassles in C# code. It was a frustrating time and cost me in terms of productivity (C# Intellisense and syntax color coding kept going screwy). It made me realize how important intellisense was to my programming approach these days when it was suddenly "taken away" (like Chris Sells said it's like crack for programmers - or was it Don Box?). Eventually I figured out that Active Reports.NET was the culprit and not VS.NET as originally thought.

Changing the .licx file entry to just:

DataDynamics.ActiveReports.ActiveReport, ActiveReports

resolved the problem. You can search Data Dynamics knowledge base and forums for licx and license for details.

Note that both the ActiveReports.NET and Xheo licensing products are very useful software components, so don't let this post deter you from investigating their use. The purpose of the post, is that if you are you experiencing instability in VS.NET that isn't a known VS.NET problem then check your add-ins.

This brings up the question of add-ins and how they should be implemented. The more apps that support add-ins developed in managed .NET code the better. It's just easier than dealing with the COM crap and can provide a level of protection from the add-in screwing up the app proper. Apologies to any COM afficionados, I just never got into COM because of all the hoops you had to jump through to get things done. It also seems that .NET APIs tend to make more sense (a generalization of course) - maybe because the programmers have to worry less about the plumbing which makes it easier to think through the higher level API concepts.

Links to this post

Create a Link