Random thoughts about AnkhSVN, .NET, Powershell an

Lately, I’ve been receiving a number of Ankh error reports that had an AccessViolationException. This was particularly weird because you cannot get that exception from safe managed code. AccessViolationException is the exception you get when you try to access memory you’re not allowed to access, usually because you are dereferencing an invalid pointer. Since safe managed code does not expose raw pointers, it’s not an exception you usually see in .NET development.

As it turned out, the exception came from a property accessor on an object from the Visual Studio automation model, a Project object. This is a COM object exposed to .NET and is implemented by the implementor of a specific project type, such as a C# project or a C++ project. Being a COM object, it can, of course, be implemented in a non-managed language, usually C++, which I suspect is the case here.

That answered the question of why such an exception could be caught inside Ankh, but it did not answer why we were seeing it in this particular case. It took a while for me to be able to reproduce it, but one submitter of an error report finally gave me a reproducible recipe: he had clicked on a linker error message in the Visual Studio error list. Linker errors aren’t associated with a specific source file, so clicking it usually does you no good, but in this case, it was clear that Ankh was doing something in response to this clicking and in the process, triggering the exception.

All files opened in Visual Studio belong to a project. This holds true even if you open a file that’s not part of your current solution, or if you don’t have a solution open. In that case, Visual Studio has a special project called "Miscellaneous Items", into which all files not part of any other project are put. This project is usually not shown in the solution explorer, but you can enable it by checking the "Show Miscellaneous files in Solution Explorer" checkbox in Tools->Options->Environment->Documents.

This project is not always present; rather, VS will load this project when the first "miscellanous" file is opened and close it again when no such files remain. Ankh has code to detect when a project is loaded and unloaded, and when a project is unloaded, we hook up an event sink to handle the case where files are added to or removed from the project, so we can refresh the status icons in the solution explorer. However, when such an event is raised, we cannot perform the refresh right away, because for some weird reason, the object model for the items hasn’t been updated to account for the changes yet. What we chose to do here is to schedule a delayed refresh of the item in question; ie, perform a refresh after a specific amount of time after the event.

What happened in this case was this:

1. User clicked on the linker error in the error list.
2. This, for some reason, triggered Visual Studio to load the Misc. Items project.
3. Ankh then dutifully hooked itself up as an event sink for events on the Misc. Items project
4. Visual Studio would then trigger the "Item added" event for the Misc. Items project (I’m not sure what it actually added, and don’t think I’ll spend much time trying to investigate it).
5. Ankh would then schedule a delayed refresh of the project.
6. Visual Studio would then, probably because it suddenly realized there was nothing to show, unload the Misc Items project again.
7. Ankh would unhook itself as an event sink for the Misc Items project.
8. However, the delayed refresh would still fire after its given interval.
9. The refresh would then work against a Project object representing a project that was no longer loaded. Accessing its properties at this time triggers the AccessViolationException.

The above sequence is a little simplified – Visual Studio did actually fire several Item Added and Item Removed events before unloading the Misc Items project, but it illustrates the problem.

One unanswered question here is why the COM/.NET infrastructure allowed the Project object to become invalid when there was still a reference to it in the managed heap. We’ve had a similar problem with ProjectItem objects, but in that case we got a more informative exception stating "ProjectItem not available".

Oh well, now that I know what the problem is, I only have to find a solution 🙂

There was a user on our users mailing list that asked if there was a way to remove a file from an Ankh-managed project without having Ankh delete it. I was about to tell him to use "Exclude from project" when I realized I should at least test it first (it’s not a feature I use a lot). I was pretty shocked to see that we do in fact delete files when Exclude From Project is invoked (if they are versioned – we don’t touch unversioned files).

I was even more shocked to see how VS behaves in this case:  The API we work against allows handling of delete (as well as rename and add) by implementing a certain interface. This interface has two sets of methods, OnQueryRemove* and OnAfterRemove* (with * being either Files or Directories). Normally, VS will first call OnQueryRemove*, where we have the option of cancelling the delete, and if we don’t, call OnAfterRemove*.

In the case of "Exclude from project", OnQueryRemove* is not called.

However, OnAfterRemove* is called, passing in a flag of VSREMOVEFILEFLAGS_IsDirectoryBased, which is documented as "Deprecated. Do not use."

Gah.

I have now changed the Wiki software for the AnkhSVN wiki to the wiki engine everyone is blogging about, namely ScrewTurn. I was immediately impressed by just how slick ScrewTurn was; dead easy to install and configure.

I have imported all the history from the previous Flexwiki-based wiki, however, historical versions lack proper formatting.

Unlike the previous wiki, this one requires users to be signed up in order to edit pages. This should let us avoid the wiki spam that plagued the old wiki.

Of course, it’s still a bit lacking in content, but I’m sure this will pick up quickly – ScrewTurn is so much more fun to work with than FlexWiki.

Damien Guard, more known as DamienG, is a new committer on the AnkhSVN project. He’s done some very good work for us already on redesigning the command icon set, and we look forward to working with him on new features in the post-1.0 timeframe.

The new icons will be available in the upcoming RC4.