CatPaw Rumors: A Quick Way to Build Against .NET 4

Dotnet4
Originally uploaded by lextm

Starting from 5.0 release, you can build #SNMP thing against .NET simply via command line.

The trick on Windows is like this,

1. Open a Visual Studio 2010 command prompt and navigate to the folder that contains sharpsnmplib.sln.
2. Execute

msbuild sharpsnmplib.sln /p:TargetFrameworkVersion=v4.0

Then all resulting assemblies are linked against .NET 4 version of mscorlib.dll, and so on.

This is much easier than opening all csproj/vbproj files and modifying them. Right?

Of course, this trick applies to our upcoming 6.0 release, HoneyCell.

No More Comments on This Blog

I lost access to Blogger console due to the great firewall of China Mainland, so the net effect is no more comments can be approved by me.

Until a time such blocking is removed, I don't have a way to change it.

Sorry for the convenience. You can always reach me via my mailbox, lextudio@gmail.com

IIS 7 and WSUS on Windows Server x64

It is common to see people install IIS and WSUS on the same box. However, if the following conditions are met, you may come across a 500.19 that's strange and hard to diagnose on your own,

1. This server is running Windows Server 2008 or Windows Server 2008 R2 x64 build.
2. There are IIS application pools that allows 32 bit applications.

The error page can be similar to this one,

Module	DynamicCompressionModule
Notification	SendResponse
Handler	StaticFile
Error Code	0x8007007e

Requested URL	http://localhost:80/
Physical Path	C:\inetpub\wwwroot
Logon Method	Anonymous
Logon User	Anonymous

The root cause is easy. WSUS installer inserts a dynamic compress module into IIS 7 named xpress. This asks IIS 7 to load %windir%\system32\inetsrv\suscomp.dll.

All works fine for 64 bit application pools till you allow 32 bit applications. In the folder %windir%\SYSWOW64\inetsrv\ there is not a 32 bit version of suscomp.dll, so IIS 7 cannot load this dynamic module and reports 500.19 with error code 0x8007007e.

  ERROR_MOD_NOT_FOUND                                           winerror.h
# The specified module could not be found.

Well, how to resolve it? Depending on your situation, there can be several ways,

• Split your applications, so on this WSUS box, only run 64 bit applications.
• Find a copy of suscomp.dll 32 bit, and then copy it to %windir%\SYSWOW64\inetsrv\.

WSUS should ship such a 32 bit copy with it, but since it does not, you have to own a 32 bit server, and copy the dll over.

CatPaw Rumors: Post Release Summary Part 1

There are still pieces unmentioned for our 5.0 release. One of that is the future of Manager and Messenger classes.

If you dig into our latest browser implementation, you will see Manager class is no longer used there. It is kind of a sign that we will get rid of this small but useful class in real world applications.

Manager was one of the early classes present in #SNMP library as it was a nice way to encapsulate all manager side functions into it (Level 3). However, soon we noticed it does not provide enough interfaces for advanced users. Messenger was added then to provide a medium level of encapsulation (Level 2). Note that you can always make use of ISnmpMessage derived classes directly which provides the lowest level of encapsulation (Level 1).

The usage of Manager becomes less, simply because our browser goes bigger and it requires more powerful things. Similarly this applies to Listener class and the agent. Therefore, in 5.0 release we started to review the design of Manager and Listener, and accordingly actions were taken. For example, bindings were introduced into the Listener class, and listener adapters were obsolete with SNMP processing pipeline introduced. Manager will face a similar attack in our 6.0 release, and it will be refactored or redesigned.

Messenger also faces demanding requests of changes. For example, it only supports v3 WALK now, and no more v3 related interfaces are yet added. So simply speaking if you are doing SNMP v3 with #SNMP, you can only use our Level 1 interfaces. How to find a set of Level 2 interfaces who are easy to use? How to bring something new to our Level 3 interfaces?

5.0 release was a nice milestone for #SNMP, as we found new approaches to do SNMP v3 better compared to old releases. But we were not able to make v3 support easier to use from API aspects. That becomes our focus on 6.0 release and wish something wonderful is there in front of us.

Well, finally leave you a few points to pay attention to,

1. Check out our samples to see how Level 1, 2, 3 interfaces are in use. For advanced users, please master our Level 1 interfaces as you usually need them.

2. For SNMP v1/v2c centric applications, if you want to migrate them to support v3, you must heavily utilize our Level 1 interfaces for v3. This can be hard as our own samples show, but it is doable.

3. For everyone, please post questions/provide feedback via our discussion board.

Stay tuned.

HoneyCell Drops: Now Comes 6.0 Codename for #SNMP

For #SNMP, the codenames for every releases implicitly contain the release numbers. Now comes HoneyCell, our next release (6.0).

For a very long time, we have done little on the compiler side. It has been asked several times that whether we will enhance it to provide more features. And now the answer is loud and clear. Yes, we will do something in this release.

First, we will try to extract more information from MIB documents, such as object description and so on. Second, the browser will display such information to the users. Third, we will use the compiler to compile MIB documents to C# classes so that extending our agent becomes easier.

The three items above may sound not too much, but once we are able to ship it, you will see how amazing it can be.

Besides, we will review all possible areas to improve the library and other parts along the way.

Stay tuned.