LeXtudio Fund: Initial Thoughts

I run a few open source projects under the title of LeXtudio. In the first few years all of them did not bring me any money. But my job at Fortune 500 companies (Cisco Systems/Microsoft in the past, and Morgan Stanley now) gives me enough to afford living in the most expensive (Shanghai) city in China, and now I even want to buy a small apartment this year.

But recently CodePlex (http://codeplex.com) collaborates with the Lounge (http://www.theloungenet.com/) and I can publish ADs on the project pages. As a result, a small amount of money can be received every year (40 USD approximately). So the projects start to make money.

I do have received two donations, one from Michael Giagnocavo (€3*.**) back in Aug 2008, and the other from Andrea Bertolotto ($1**.**) in this month. I have to say they sent me a lot compared to what I imagined. I really appreciate their generous offer.

Then how can I make good use of all the money received from the open source projects? I am still trying to figure out what can be the best way(s). So today, this post simply announces that I put the money into a fund (LeXtudio Fund). I will provide more details when I start to make use of it.

Stay tuned.

CatPaw Rumors: Release Notes for 5.0 Release

Note: We did analysis on #SNMP 4.0 here. This post is the latest one for 5.0.

A view of the work achieved

SELECT METHODS WHERE CodeWasChanged OR WasAdded

The codebase keeps evolves fast, and the picture shows a lot,

You can see a lot of highlighted areas, because

1. We migrated to Visual Studio 2010, so many generated code has been changed.
2. We changed a lot of GUI code in order to support Mono/openSUSE.
3. Agent side SNMP v3 support introduces many underlying changes in the Library.
4. Browser side SNMP v3 support introduces a few changes in itself.

New Core Public Types

SELECT TYPES FROM ASSEMBLIES "SharpSnmpLib","SharpSnmpLib.Controls", "SharpSnmpLib.Mib"

WHERE IsPublic AND WasAdded

Only three new types are introduced in 5.0,

• MalformedMessage: It is used to represent an SNMP v3 message received by the listener, which cannot be decrypted successfully due to several reasons.
• DecryptionException: An exception raised when an SNMP v3 message cannot be decrypted successfully.
• ListenerBinding: We introduce this class, so you can ask a Listener class to monitor on several IP address:port number bindings.

New Assemblies

SELECT ASSEMBLIES WHERE WasAdded 

Only one assembly is added to our binary release package. That is snmptranslate, a utility to show how to use compiled MIB documents to do OID translation.

New Public Types

SELECT TYPES WHERE WasAdded AND IsPublic

We have a few new types here except for the three mentioned above,

• OutputPanelAppender: This is a custom log4net appender used in the Browser and the Compiler. It logs all necessary information into the output panel.
• RollingFileAppender: This is a custom log4net rolling file appender that outputs log file names in IIS similar pattern.

Rambling

Our biggest changes are,

1. The Agent and the Browser now support SNMP v3.
2. The Agent, the Browser and the Compiler supports both .NET/Windows and Mono/openSUSE now.
3. VB.NET samples are added.

Breaking Changes

Removed types are,

• BitString
• Bool
• GeneralString
• Real

Moved types are,

• ISnmpMessage
• IEntity
• IDefinition
• IModule
• IObjectRegistry
• IObjectTree
• SearchResult
• DefinitionType
• IConstruct

New Project: MSBuild Launch Pad (mPad)

I used MSBuildShellExtension years ago. It was a nice helper when there was only .NET 2.0. But once .NET 3.5 came, it did not adapt to it as I wished.

It was a few days ago I joined a StackOverflow thread, http://stackoverflow.com/questions/2833327/build-item-in-windows-explorers-context-menu-of-a-vs-solution-file/2834092#2834092 and suggested MSBuildShellExtension again. However, when myself checked out its homepage I noticed the project has been idle for a very long time.

It still has the following disadvantages,

1. It does not choose MSBuild version smartly by stepping into the script files. Manually selecting MSBuild version is not easy for beginners.
2. It does not parse the script files to see what targets are supported. If the files can be at least analyzed, end users can select which target to be called easily.
3. .NET 4 is now released, and MSBuildShellExtension does not yet support it.
4. Windows Vista and Windows 7 introduce UAC. But the Configurator does not work well with UAC.

I was planning to join this project and bring in some update, but why not start from a new perspective and write something new from scratch?

Here comes MSBuild Launch Pad, http://msbuildlaunchpad.codeplex.com/, my fourth CodePlex project (my fifth open source project).

Itself contains a launch pad application who parses sln/csproj/vbproj/vcxproj files to determine which MSBuild version should be used.

It will support proj files and other famous MSBuild based solutions (Delphi Prism, Sandcastle Help File Builder, WiX) in the future releases.

Still MSBuildShellExtension is being used to display MSBuild logs.

If you are interested in the new project, please drop me your comments.

The Not-So-Cool CodeRush Express 10.1 Installer (Resolved)

install
Originally uploaded by lextm

I have been expecting CodeRush Express 10.1 for a few weeks, but when I touched it and tried to install, it disappointed me with such a page.

Yes, everything is ready but I cannot click the Install button. Why? No hint from the installer, or its installation log.

I have fired a bug report, and let's see what the guys will say, http://www.devexpress.com/Support/Center/p/B147309.aspx

Updated: DevExpress team has resolved this issue.

CatPaw Rumors: Beta 2 and Afterwards

#SNMP 5 goes on smoothly. I just had two items to work on when I started,

1. SNMP v3 support in the Agent.

2. SNMP v3 support in the Browser.

However, many hard things jump in the way, especially Mono support, so though we are now at Beta 2, a lot of interesting items are now in the list.

On April 10, I finally found some courage to boot openSUSE and tested #SNMP against Mono. The journey started with Mono issues, and I hardly believed more and more issues were waiting ahead. Well, I posted about them in an earlier post, but even that was not complete since I reported two more later. It is happy to see that Mono team actively involved and fixed many of them. Besides, almost all issues I found can be worked around. So before Mono 2.8 hits the road, #SNMP will use those workarounds.

The Agent was ported to Mono/openSUSE first, and that's because it has only one form. And I gained a lot of experience from this migration, such as platform dependent code separation, workaround identification. Then when suddenly I decided to port the Browser and the Compiler, I have some confidence on what I should pay much attention to.

Porting DockPanel Suite must be the hardest thing I ever thought of, but my plan worked out very smooth. It's so lucky that we simply commented out what cannot be ported easily and such changes only affect drag and drop, a feature #SNMP does not really rely on. As things sped up so soon, we are able to see a full port to Mono/openSUSE in 5.0 Beta 2.

Today I finished a lot of project file cleaning. The project files were initially created in SharpDevelop and Visual C# 2005 Express, and then upgraded to Visual C# 2008 Express. It was recently that we migrated again to Visual C# 2010 and MonoDevelop. Though MSBuild script is used for csproj files, we must confess that different IDE vendors choose to make use of it differently (even VS generates terrible csproj structure if I dig the files further). So price was paid when I had to avoid csproj file changes from MonoDevelop. Soon I gave up SharpDevelop. Now I recreated all the project files in VS2010 and will only check in csproj file changes from Visual Studio or Notepad. Note that I did not mean I don't use MonoDevelop or SharpDevelop. I just never accept their changes to the projects.

Upgrading old projects also show me how .NET evolves. In the past, resource files are embedded into resx files in BASE64 formatted bytes. But now resx files are much smaller, as we only define in them which files will be fetched and embedded. So I have to delete all old resx files and recreated them cleanly.

Besides, the project structure is heavily changed and useless projects are finally removed. As now we have official VB.NET and C# samples, VB.NET developers can learn how to use #SNMP easier. Personally I would like to also add Delphi Prism samples as I love this language, but I just don't have a license of it yet.

SNMP v3 support in the Agent is almost finished. We will see if authorization can be added beautifully in 5.0 release. If not, it will be delayed to 6.0. 

SNMP v3 support in the Browser is 80% complete. I still need to check how to implement v3 WALK. Luckily I have some ideas now and I just need time to put them down to C# code. :)

Stay tuned.

CatPaw Rumors: Visual Studio 2005 and .NET Framework 2.0 Mainstream Support Ends in April 2011

http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=.NET+Framework

http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+Studio\

http://blogs.technet.com/lifecycle/archive/2010/04/30/net-framework-3-5-sp1-and-later-now-supported-as-part-of-microsoft-windows.aspx

We dropped Visual Studio 2005 support a few weeks here in #SNMP. However, we will continue to target .NET 2.0 users till .NET 2 mainstream support expires. 

Simply speaking, this means #SNMP Library (SharpSnmpLib.*.dll) can still be used for .NET 2.0 applications (but you must be running .NET 2.0 SP2). We no longer support .NET 2.0 without SP, or .NET 2.0 SP1 before April 12, 2011. After that day, I will start to target .NET 3.5 SP1 and .NET 4.0 only. 

Retiring .NET 2.0 helps bring features such as extension methods and so on to (SharpSnmpLib.*.dll).

Flickr Blog this

Flickr Blog this - Google Chrome
Originally uploaded by lextm

I have been using mail to blogger for a while as blogger.com has been blocked for the reason you know. However, I found it hard to embed images.

Now I found Flickr Blog this feature, and blog posts can now be authored easily via flickr.com. I still search for a way to blog about several images in one post. Is it possible?

Environment Preparation for Sandcastle and Microsoft Help 2

Program Manager
Originally uploaded by lextm

I found it very hard to prepare the environment for building Microsoft Help 2 in Sandcastle, so below are the steps for your reference,

1. Download and Install a Microsoft product that contains Microsoft Help 2 runtime, such as Visual C# 2008 Express.
2. Download and install VS2005 SDK following to this article,
http://helpware.net/mshelp2/h2faq.htm#novsnet2. I choose to install FEB 2007 v4 RTM.

If you experience this issue,

Error HXC4001: File file://.../Help2x.hxc, Line 2, Char 77: XML syntax error: No data is available for the requested resource.
Error processing resource 'MS-Help://Hx/Resources/HelpCollection.dtd'.
Fatal Error HXC2056: Parse of the .HxC file failed.
BUILD FAILED: Unexpected error in last build step. See output above for details.

http://shfb.codeplex.com/Thread/View.aspx?ThreadId=2475,
please follow suggestion of this article,
http://helpware.net/mshelp2/h2faq.htm#FixMissingDTD

On my computer, Resources.HxC is here, C:\Program Files (x86)\Visual Studio 2005 SDK\2007.02\VisualStudioIntegration\Archive\HelpIntegration\Resources.HxS

If you use Sandcastle Help File Builder then it may report Sandcastle is too old. That's because VS2005 SDK ships a very old version of Sandcastle. Please download the suggested version and then manually configure SHFB to use the new version.

References:
http://sandcastle.codeplex.com/
http://shfb.codeplex.com/
http://helpware.net/mshelp2/h20.htm#Getting_Started
http://helpware.net/mshelp2/h2faq.htm

DockPanel Suite Tip #5: We Could Go Mono

DockPanel Suite Lite on Mono/openSUSE
Originally uploaded by lextm

DockPanel Suite was designed for Windows. Its original author and later contributors do not yet port it to Mono. However, so many people including me would like to have a Mono friendly DPS, then how can we achieve that?

A full port to Mono requires us to get rid of all Win32 PInvoke, but unless someone who masters Windows/Linux/DPS comes I bet it is not likely that we see a full port.

I chose the easy way to sacrifice certain features. For example, if we disable end user drag and drop, all such PInvoke parts can be safely commented out. Is that all I need? Yes, my applications at this moment do not need any drag and drop, so why not use this lite version?

I now happily see the applications run fine on Mono (well, one infinite loop issue needs to be worked around though). So do you plan to use such a lite version?

The lite version of source code is available here, http://code.google.com/p/sharpsnmplib/source/browse/#hg%2FWinFormsUI. You can check out the entire WinFormsUI folder and analyze it to see what changes I've made.

(Updated: Now I become a maintainer of DockPanel Suite. The latest DPS can be found at https://github.com/dockpanelsuite/dockpanelsuite, which contains this patch and many other useful patches.)

CatPaw Rumors: More Mono Support Coming

Do you want to use our browser and compiler on Mono too? Yes, I believe most of you want a modern UI MIB browser and compiler on Mono/openSUSE. So is it possible that we ship something like that?

I thought it was impossible as I chose to depend on DockPanel Suite. However, the fact is if we give up certain features, it is technically feasible to build a lite version of DPS to port our browser and compiler to Mono/openSUSE, so in 5.0 Beta 2 we will for the first time ship them as Mono compliant.

That was what I achieved last night. I removed nearly all Win32 PInvoke from DPS and now included this lite version in our source code package. The limitation now is that all panels in the browser and compiler cannot be dragged or moved.

This can be an interesting way to go Mono. But more Mono issues/bugs arise and I fought hard to find workarounds. Well, I must say the final result is promising that we bring as many features to Mono as possible now, but both the tools look poor.

More bug reports are now fired to Mono team, and hope they can provide fixes soon (before we ship 5.0 final is preferred, but I know that's hard).

Why complaining that Mono is not mature enough as a deployment platform? If you don't report issues, how can Mono guys fix them? Go! Mono.

Stay tuned.