CatPaw Rumors: We Are Truly Mono Ready Part II

This is a MoMA scan report on snmpd.exe. Though there are so many issues reported, in fact this SNMP agent runs fine on both Windows/.NET and openSUSE/Mono.

Assembly	Version	Missing	Not Implemented	Todo	P/Invoke
Crad.Windows.Forms.Actions.dll	1.1.1.0	0	0	0	0
log4net.dll	1.2.10.0	0	0	6	3
Microsoft.Practices.ServiceLocation.dll	1.0.0.0	0	0	0	0
Microsoft.Practices.Unity.Configuration.dll	2.0.315.0	0	0	0	0
Microsoft.Practices.Unity.dll	2.0.315.0	0	0	21	0
Mono.Posix.dll	2.0.0.0	0	0	0	407
SharpSnmpLib.Controls.dll	5.0.10419.0	0	0	0	0
SharpSnmpLib.dll	5.0.10419.0	0	0	0	0
snmpd.exe	5.0.10419.2	0	0	0	1
Total		0	0	27	411

Along our way to be Mono ready, the following Mono issues have been found and reported,

595552
Min
P5
openSUSE 11.2
monodevelop-bugs@lists.ximi...
NEW
IDE does not handle app.config in Visual Studio/SharpDevelop way
The workaround is to manually build using xbuild. I think when MD starts to use xbuild the issue is resolved automatically.

599488
Nor
P5
openSUSE 11.2
mono-bugs@lists.ximian.com
NEW
Why SocketException with ErrorCode == 10035 means Operation timed out? It breaks .NET compatibility
The workaround is to test whether Mono is in use and then check against 10035 or 10060.

599462
Nor
P5
openSUSE 11.2
mono-bugs@lists.ximian.com
NEW
System.NotSupportedException from System.Drawing.GDIPlus.CheckStatus (Status status) for #SNMP Agent
The workaround is to ignore the icon file for snmpd.exe main form.

599449
Nor
P5
openSUSE 11.2
mono-bugs@lists.ximian.com
NEW
"cannot be inferred from the usage" when compiling #SNMP
The workaround is to convert LINQ expression back to normal lines.

599486
Nor
P5
openSUSE 11.2
jankit@novell.com
NEW
xbuild does not honor extra <Import> tag
Well, at least MD or xbuild compiles the solution without any error. I just remember to build periodically from Windows to update the version numbers.

599454
Nor
P5
openSUSE 11.2
jankit@novell.com
NEW
xbuild cannot create folders
The workaround is to manually create those folders.

CatPaw Rumors: 5.0 Beta 1 is Out.

#SNMP 5 Beta 1 is available now. Our main focus here is to make the Agent (snmpd) feature complete and Mono ready.

http://sharpsnmplib.codeplex.com/releases/view/43006

In Beta 2 phase, I am going to work on the Browser side.

Stay tuned.

One Tip on TortoiseSVN with CodePlex

I simply found that sometimes several files are missing if I use SVN Update menu item. The resolution is to use TortoiseSVN | Update to revision...

Then HEAD revision and Fully recursive both need to be chosen.

CatPaw Rumors: Repository Access, Good Mixture Or Bad?

In order to test out #SNMP on Mono/openSUSE, I start to use MonoDevelop on openSUSE and it works fine in many aspects. But well soon issues arise.

I have used the following access methods to CodePlex repository and they work fine together,

1. Visual Studio 2010 (Team Explorer is included) on Windows.

2. SharpDevelop 3.2 (with TortoiseSVN) on Windows.

You may ignore how much effort SD team pay to make this smooth. When MonoDevelop on openSUSE is involved, incompatibilities reveal. MonoDevelop makes use of MSBuild script based csproj file differently,

1. AssemblyInfo Task settings are not honored. I don't know if this is a Mono issue or AssemblyInfo Task issue.

2. Once a project is modified in MonoDevelop and checked in, Visual Studio will try to upgrade it. This indicates that MD does not generate proper MSBuild script in the project file.

Therefore, I won't check in any project files again from Mono side, until MD team resolve such incompatibilities.

Well, it is really amazing to see that MonoDevelop on Windows is much poorer than its build on openSUSE. Why? :)

CatPaw Rumors: We Are Truly Mono Ready :)

From the very beginning of this project, I tried to keep it compliant to both Microsoft .NET and Novell Mono. However, at that time I was a Ubuntu fan and Mono did not work fine on it. Therefore, I had to utilize MoMA on Windows to see which #SNMP pieces can be fully "supported". That's why I can announce the Library supports Mono at that time.

Now we are truly Mono ready. I mean we can check out the source code to openSUSE Linux and build from there. I already know the command line tools work, as they are so simple to experience any problem. But MoMA reports our major tools (the Browser, Compiler, and Agent) are not Mono compliant due to third party dependencies. So is that true? Luckily the answer is "No."

In fact now I am sure our Agent works fine on openSUSE after only a few tunings. They are,

1. We must build the project TestAgent.csproj via xbuild command line tool. Due to a MonoDevelop bug I reported (http://bugzilla.novell.com/show_bug.cgi?id=595552), MD does not copy app.config over for you.

2. We have to change MainForm.cs a little bit to work around another Mono bug. It seems that Mono does not like the Icon file format, so I will report it later once I have a smaller sample to reproduce the issue.

3. We must run snmpd.exe as administrator ("root" in Linux term). I found I could not use "sudo mono snmpd.exe". But if I executed "su" to enter root mode first, then I could execute "mono snmpd.exe" to launch our Agent. Otherwise, SocketException "access denied" will be raised as snmpd has no enough rights to monitor ports who numbers are less than 1024. (Refer to http://go-mono.com/forums/#nabble-td1497458).

This indicates the issues reported by MoMA on Microsoft Unity do not affect #SNMP Agent. I guess that's because we do not use those features.

The Browser and Compiler still fail on openSUSE, as DockPanel Suite is Windows dependent. Mono Invoke was announced a very long time ago, but now we see no news. Maybe that's because it is too huge to be implemented. Who knows.

Stay tuned.

(Updated: snmpd in the repository is now fully Mono/openSUSE compliant. We will keep updating it till release 5.0 is shipped. With a lite version of DPS, now the Browser and Compiler are also Mono ready.)

CatPaw Rumors: Now We Have Bindings And More

#SNMP Agent starts to look good after I decide to follow IIS and ASP.NET patterns. Yes, the pipeline pattern makes it so easy to do authentication, handler mappings, and so on. Our release 4.0 is a nice indication that we are on the right track, and the upcoming release 5.0 is evolving fast. A few days ago, I announce that we implemented most SNMP v3 support in snmpd. Today, we go ahead and borrow one more idea from IIS. That is, the bindings.

For IIS HTTP web sites, we can configure bindings easily. So a site can monitor both (http) 127.0.0.1:80, (http) [::1]:80, and (https) *:443. That's a very convenient way to say how many incoming requests I care of. But what about our current SnmpDemon in release 4.0? Well, it must be terrible. Even in our Browser, we had to use two Listener instances to monitor incoming requests in all unassigned scenario.

Like I explained before, this is sort of a System.Net limitation. So now, how to make life easier? We can hide all details by encapsulating multiple Listener objects in a single class,

1. Rename Listener to ListenerBinding.

2. Add a new class named Listener.

3. Start to tune Listener and ListenerBinding implementation according to how Listener is used in the whole code base.

Still ListenerBinding class is the one who performs the heavy tasks, while Listener class hides all details from consumers. You only need to make use of ClearBindings, AddBinding, Start and Stop to enjoy the ease.

There are nice additions checked into our repository recently, and why not take a look yourself? Once I finish the implementation of SecureAgentProfile, a 5.0 beta will be available. 

Stay tuned.

CatPaw Rumors: CodePlex Ways, TFS and SVN

I hate the A vs. B discussion, so I promise this post is not one of that kind.

I think CodePlex is a nice place to host open source projects, whether yours targets Windows. Yes, I know CodePlex.com has a lot of bad things,

1. This is not a "open source" place, as many projects use a license that do not match OSI open source definition.

2. It starts with TFS repository, which makes it very hard to use from other platforms (Linux, Mac and so on).

3. It is sponsored by Microsoft.

Now things change, mate. 

1. Even SF.net has fake "open source" projects.  

2. CodePlex introduced SVN repository access based on the awesome SVNBridge project. And now it even supports Mercurial repository (sad it is not Git). Even the TFS repository can be accessed via Teamprise client.

3. Well, Microsoft is not the enemy of open source. On this point, I agree with Miguel of Novell/Mono.

I started to use Teamprise Explorer for my open source projects on CodePlex (Alex and #SNMP Suite). The open source license Teamprise team granted to me can still be used today with their latest version (not sure what may happen as they are now part of Microsoft). Well, after a few days I began to miss CVS. Yes, that's why I switched to the SVN way once CodePlex team announces SVNBridge.

It was then Steve joined me on #SNMP Suite and he told me sometimes his working copy became corrupt suddenly. I don't know if that's caused by my frequent check-ins, but that makes Steve's life a little harder as he had to periodically drop the working copy and started from scratch. Now I began to try out TFS and SVN at the same time, and I kind of experience issues similar. 

I will try to use more TFS now, as it has better integration with other parts of CodePlex (the issue tracker part) and its client is now official part of Visual Studio 2010. But SVN will be used besides, as I still use SharpDevelop a lot :)

CatPaw Rumors: SNMP v3 Agent Is Ready

In #SNMP Suite release 4.0 we delivered an SNMP agent which supports v1 and v2c. How far away are we from v3 support?

The first missing piece is the discovery process. How to respond to v3 discovery message was a question raised on the discussion board before we released 4.0. At that time I was not sure how hard it is. Soon I found it is not that difficult, and adding a few lines in v3 membership provider is all it requires. In this way we resolved work item 6128 and advanced the agent a little bit.

The second piece is to support v3 modes. This is relatively easy, because our MessageFactory implementation already helps parse the messages. However, if decryption of messages is taken into consideration, the problem arises. What if we cannot get the scope part of the message? That means we lost all information such as PDU. Interesting that after we introduced malformed message, everything becomes easy. 

Currently we did not yet complete v3 support in snmpd, as there are many details to review in order to improve RFC compliance. But this can be deferred to future builds. My next focus is v3 support in the browser. In release 4 I already did some fundamental tasks, and now it is time to fill in the blanks.

Stay tuned. More will come in this beautiful spring.

CatPaw Rumor: Time To Say Farewell to Visual Studio 2005

This weekend, I started to use Visual Studio 2010 as primary IDE instead of Visual Studio 2008. This change leads to the following changes,

1. I decided to drop Visual Studio 2005 solution support. This means that I don't expect you to build from source code from within Visual Studio 2005 or with .NET 2.0 MSBuild. Visual C# 2008 Express or .NET 3.5 MSBuild is now the minimal requirement.

*The library assemblies, (SharpSnmpLib*.dll) are still compiled against .NET 2.0, so you can continue using them if you cannot afford .NET 3.5 or .NET 4.0.

2. I started to use C# 3.0 language features extensively. The drop of Visual Studio 2005 guarantees this change. Now I can feel free to use LINQ, lambda expression, and others, which makes my life easier and happier.

3. The Agent, Browser, and Compiler started to target .NET 3.5 due to Unity 2.0 dependency.

4. All build scripts are now using .NET 4 MSBuild.

Primarily speaking, we are now .NET 4 ready, and only supports two versions of Visual Studio (2008 and 2010). Thanks for MSBuild multitargeting feature, our core assemblies can still target .NET 2.0.

Stay tuned as I will blog more about our upcoming release (5.0, CatPaw).