Friday, July 1, 2011

SNMP on Windows Phone 7.1 (Mango) Update.

NetToolWorks is almost ready to take requests for the BETA version of their SNMP library for Windows Phone 7.1 (Mango). Here is a taste of what it’s going to be like to use the library.
Requesting a variable using SNMPv1:
ManagerBase manager = ManagerFactory.CreateVersion1Manager("public");

manager.GetAsync(_Address, 161, "1.3.6.1.2.1.1.1.0", (variables, remoteEndpoint) =>
{
    if (variables.Count > 0)
    {
        MessageBox.Show("Response: " + variables[0].ToString());
    }

    manager.Close();
});
with SNMPv3:
SnmpUser user = new SnmpUser()
{
    Username = "test",
    SecurityLevel = SnmpUserSecurityLevel.AuthenticationAndPrivacy,
    AuthenticationAlgorithm = SnmpAuthenticationAlgorithm.SHA,
    AuthenticationPassword = "SHAPassword",
    PrivacyAlgorithm = SnmpPrivacyAlgorithm.AES,
    PrivacyPassword = "AESPassword"
};

ManagerBase manager = ManagerFactory.CreateVersion1Manager("public");

manager.GetAsync(_Address, 161, "1.3.6.1.2.1.1.1.0", (variables, remoteEndpoint) =>
{
    if (variables.Count > 0)
    {
        MessageBox.Show("Response: " + variables[0].ToString());
    }

    manager.Close();
});


Stay tuned for information on how you can get your hands on the BETA. Mmmmmmm juicy mangos.

Sunday, May 29, 2011

SNMP and Mangos?

So what do these two things have in common? Not much if you are talking about the fruit. However for those living under a rock mango is the code name for Windows Phone 7.1 (WP7.1) and I’m proud to announce today that NetToolWorks will be bringing their high quality SNMP library to it. NetToolWorks was the first to bring SNMPv3 support to the .NET Framework back in 2002 and now they are the first to bring it to the Windows Phone! (or just SNMP for that matter). Supported authentication and privacy algorithms include SHA1, MD5, AES, and DES for SNMPv3. A BETA version will be out soon, so stay tuned. For now here is a screen shot of a demo working:

image

Thursday, January 13, 2011

The case of the missing blog posts.

So the two of you that read my blog might have noticed that a lot of my posts are missing. I moved my blog once again to a new location. I just couldn’t get the last place to work right and they nickel and dime you over every feature. Hey good for them if they can get people to pay, but it just wasn’t worth it to me. While moving my posts over I noticed a lot of them just aren’t relevant anymore. Rather than spending hours and hours moving irrelevant posts I just decided to dump them and start fresh. I kept two technical ones and one that gives context to my recent post. If one of you two readers (if I even have that many anymore) wants one of my older posts I can send it to you.

Sunday, January 9, 2011

Indiana Jones and the Temple of am I doomed?

Yeah I know  it’s been a long time since I last wrote anything here. I made a joke in my last post about my next one being in 2011. Seriously I really meant that as a joke. I had no idea that would ring true. Actually in December I kept telling myself “I have to post something this month!” and I never got to it (obviously). Well 2010 was a strange year. I was so busy fretting about what to do next that I just kind of spun my wheels and got nowhere (lost year). In November a domino fell that lit a fire under my butt. Since then I wrote a C# like parser that compiles down to the DLR (I hope to have a post about that soon), quit my job of 9 years and decided to strike out on my own (this is where the Indiana and doomed part comes from…get it? .. no? I know dumb humor), started a contract, and started a few other projects.

So what’s the purpose of this post? Nothing really. I hope to start making some useful ones soon again (if I ever made any). I would like to show off the pre-Alpha version of that parser maybe in the next post. Here’s to a hopefully more productive (and a little scary) 2011.

Tuesday, December 29, 2009

Finally…

Yeah it’s that time of the year again. Well end of the year I should say. The time where everyone gets all energetic about their future. “It’s a new year and this time I am going to really do it…no really I am…c’mon! Seriously I am!”. OK I’m finally getting around to moving my old posts over here so stay tuned. See my next post in 2011 (Just kidding…hopefully).

Saturday, December 6, 2008

C++/CLI equivalent of C# using statement for automatic disposing.

A common practice, and a good one, in C# is to wrap a class that implements the IDisposable interface in a using block like so:

using (FileStream filestream = new FileStream("MyFile.txt", FileMode.Open, FileAccess.Read))
{
// Perform some file operations
}

The code will automatically call Dispose one the filestream instance even if an exception is throw inside the code block. Dispose is typically used to free resources immediately instead of waiting for the garbage collector to make it’s pass and clean up the class. In situations where you are creating and deleting a lot of objects that may contain handles or unmanaged buffers internally this can keep system resource use down. So how is this accomplished in C++/CLI? There is no using statement in C++/CLI. It turns out that it’s supported in what I think is a more elegant way than C#. For starters to define a class in C++/CLI that implements the IDisposable interface you don’t have to actually inherit IDisposable explicitly you simply define a destructor for the class like so:

public ref class MyClass
{
public:
MyClass(void)
{
}

virtual ~MyClass(void)
{
//Free resources here. This is the IDisposable.Dispose(); equivalent
}
};

The above C++/CLI code would emit the IDisposable interface automatically. To call the Dispose method in C++/CLI you delete the object just like you naturally would in C++:

int main(array<System::String ^> ^args) 
{
MyClass ^ myclass = gcnew MyClass();

//Do some stuff with myclass

delete myclass; //Dispose gets called

return 0;
}

So far we have seen how to implement IDisposable and how to explicitly call Dispose in C++/CLI. Now I will show you the C++/CLI equivalent of C#’s using statement block. This too is very elegant in C++/CLI. To do this we allocate the class on the stack instead of the heap like so:

int main(array<System::String ^> ^args) 
{
MyClass myclass;

//Do some stuff with myclass

//When myclass goes out of scope Dispose will be called.

return 0;
}

The above is the same as the using statement block in C#. The Dispose method is automatically called once myclass goes out of scope. Notice the ^ is missing from the declaration. This puts the class on the stack instead of the heap. When the class is popped off the stack at the end of the function the Dispose method is called for the class. OK all finished right? Wrong. What if MyClass has no public constructor and the only way to create it is by calling a static method that returns a handle to MyClass (i.e. MyClass ^)? A good example of this is the Graphics class. In C# we can do something like this:

using (Graphics graphics = Graphics.FromImage(img)) 
{
//Do stuff
//Dispose is called on graphics when we exit this code block
}

It’s not possible to allocate the Graphics object on the stack in C++/CLI because there is no public constructor for it and the “From” methods return a Graphics ^ which puts the instance on the heap instead of the stack. So how do we accomplish the same result as above then? In my first C++/CLI example where I called delete ont the myclass instance I didn’t exactly present the best practice for C++/CLI code when dealing with disposable objects actually. I did that on purpose so I could show it here:

Graphics ^ graphics = Graphics::FromImage(img); 

try
{
//Do stuff
//Dispose is called on graphics when we exit this code block
}
finally
{
delete graphics;
}

By using the try..finally code block we accomplish the same thing as the C# code. So that’s it. I think C++/CLI does IDisposable in a elegant way. What do you think?


Monday, October 20, 2008

Using ActiveScript in Managed Code

I recently was involved in porting a legacy COM application to a .NET version of the application. The application made heavy use of VBScript through the ActiveScript interfaces for customization. The customers current user base was large enough that one of the requirements was to continue to support existing scripts in the field. So interfacing with ActiveScript via .NET was a must. I set out to find a library that already did this, but all I really found were pieces here and there on how to kind of implement it. I played around for a while and finally came up with a good implementation. It even supports adding your own .NET objects to the script. I was able to get rid of all the COM objects and port the entire object model to .NET. The only COM in the new application is the ActiveScript stuff. There are some advantages to using ActiveScript still. For one it doesn’t compile an in memory assembly that you can’t get rid of. If you want to get rid of your compiled in memory assemblies in .NET you have to put them in a separate application domain and unload it, which can be tricky depending on the complexity of your application.


I’m posting the entire ActiveScript libaray including source code on CodePlex for anyone to use free of charge. There is a basic sample included with it that demonstrates how to use the library. It’s actually pretty simple. In future blog entries I will write more on how to use it. For now I wanted to get it out there for others to use. Hopefully it will save some of you some time and hassle. If you find the code useful and decide to use it drop me a line.


The source code (written in C#) can be found here on CodePlex.