Daniel introduced an exception bug in revision 1636 - and we didn't find it in time for release (though it was all too obvious to reproduce). 1649 is now released, and he checked in the change again - the new file dialog is now smart about subdirectories and namespaces (1650 if you are curious).

Also, the 1.0.1 installer is using a Windows Scripting Host (WSH) script to install three assemblies into the GAC and generate the help index. If your initial start tells you about a missing file, it might be that (a) scripting is disabled on your box or (b) your antivirus scanner has script blocking enabled. Sorry for the inconvenience, but simple batch files don't cut the mustard any more.

We are proud to have released the first maintenance release of the 1.0.x series (almost on schedule). It is available on our download page, the changes are documented as usual. One thing that wasn't possible due to time constraints (read: necessary testing) is to fix the resource import issues for VS.NET projects. You can count on us tackling this next.

#Assembly has a problem when loading unmanaged .NET DLLs - this affects the DirectX 9 code completion for example. #Assembly will be removed when we do the #D 2.0 port, thus you will have to live with missing code completion for unmanaged .NET DLLs for the 1.x branch. The .NET Reflection API in .NET 2.0 in contrast has everything I can dream of, which is why there will be no further work on #Assembly.

A longstanding issue has been resolved: consistent assembly versioning is now in the source tree. With this change, all assemblies reflect a central scheme - a three digit version number followed by the Subversion revision number of the tree it lives in. With this build process change, we also fixed all assemblies that had missing assembly infos (mostly backend bindings).

In other news: we also checked in NProf 0.9alpha.

• SD-209 "Folding inconsistency"
• SD-241 "Code generation doesn't work for own classes"
• SD-218 "Undo form designer operations in code"
• SD-244 "Code completion is not working inside ELSE clause"

In other change news: Daniel improved the VS.NET project exporter (more properties are exported, project references and assembly references are exported) as well as the importer (treat warnings as errors is now imported correctly, .csproj & .vbproj types are now shown in the import dialog)

• SD-243 "Code completion overload insight window scroll arrows not working"
• SD-229 "Horizontal scroll bar too sensitive"
• SD-186 "Permission problem in VS.NET importer"
• SD-239 "Auto code generation exception"
• SD-242 "Switching File Mode to VS-C# from C#, quotes will "vanish""

Quite some lively discussion of this question is going on at Theserverside.net. Contributions cover the entire range from pro to contra, and astonishingly, very few posts are flame bait. Worth reading, whatever your attitude towards the topic may be.

And another topic related to Open Source is the change of licensing recently undergone by SpamAssassin. This was a long and painful process - more than 100 developers and contributors needed to be contacted and convinced to assign copyright to the project before the licensing change was made. We here at #develop ask for a Joint Copyright Assignment from all contributors since inception of the project. This episode now shows that our doing so provides other benefits besides those outlined in our wiki. Note to all out there who consider an Open Source project: think of copyright and attribution issues even before you start your project. Later modifications *are painful*.

• SD-224 "Destructors can't be folded"
• SD-232 "Toolbox Scrollbars"
• SD-236 "Code generation list has duplicate entries"

• SD-238 "WinForms template namespace issue"
• SD-231 "Save / Save All commands context sensitive"
• SD-225 "Endless loop: folding invalid nested classed"
• SD-184 "Update Tracker to Gemini 1.7"

Currently I'm working with Andrea on NRefactory (name may change) which is a merge of #Refactory and VBRefactory. No longer do we need to maintain two different abstract syntax trees or different parser related code. In the past maintenance was an error prone process because each bugfix or enhancement needed to be ported to the other parser layer. Now we're merging VB and C# parsing and have only one representation for the source code. That will prevent many bugs. NRefactory will have a good unit test suite which will ensure that we're not going to break much during code refactoring and future maintenance.