Joacim's view on stuff : c#, visual basic

Creating an IE plug-in

Joacim Andersson — Tue, 15 Nov 2011 15:59:22 GMT

I was recently approached by a customer about an intriguing project, unfortunately I can’t tell you too much about it since I’m under an NDA, but it involved creating an add-in for Internet Explorer and a custom Windows Service which would act as the backend. I’ve never created any add-ins for IE before but as a long time Windows developer I know that the Microsoft web browser is heavily dependent on COM. Since I’ve been doing mainly .NET development for the last 10 years or so, and sort of left the COM world behind me, I first started looking for some form of framework that would allow me to develop the add-in using managed code.

I found two different frameworks that I started evaluating. The first is an open source project originally created by Microsoft called SpicIE and the second is a commercial product called Add-In-Express for Internet Explorer. The latter is from the company Add-In Express Ltd who has specialized themselves on creating add-in frameworks and has a wide range of products to create add-ins for Office and IE in both .NET and in VCL for Delphi.

Both of these frameworks takes care of all the COM communication and implements all the necessary COM interfaces so you can concentrate on the more important things, namely what your add-in is supposed to accomplish.

In my case I needed to be able to create a toolbar button and an IE bar, which are those side panes similar to how Favorites and History are displayed within IE. There was no problem creating these in either framework but the Add-In-Express also had an Advanced IE Bar control with some additional features which I liked a lot. They also have visual designers which simplified everything and I was able to create a stub application, that demonstrated the final design, within a few minutes. It took me a bit longer to do the same using SpicIE, mainly because the documentation is a bit sparse (as the case often is with open source projects), but it comes with several demo projects that you can learn from. Add-In Express on the other hand have several video tutorials available on their website, which of course is a lot faster way to learn the basics without digging through a bunch of source code.

SpicIE also comes with this reservation:

Important: SpicIE is released independently of Internet Explorer and related products. It is not an officially supported product by the Internet Explorer team. While SpicIE is a valuable tool for prototyping and testing Internet Explorer extensions, it is not recommended for use with released software.

For me there was no question about which framework we would use for this particular project and if you would ever need to create a commercial product that requires an add-in for Internet Explorer I highly recommend Add-In Express, you’ll get a very stable product and excellent support from the team at Add-In Express Ltd, but this of course comes with a price tag so if you’re just a hobby programmer then go ahead and give SpicIE a try.

The next thing we needed to do was put a team together to start developing this particular system. Since the customers budget was rather tight my manager decided that we should use our offshore company in India for the development of the actual add-in while I should concentrate on the architecture and create the backend system.

I think I have to write a blog post about the experience I’ve had with this and other projects when the development team sits in different continents, with different cultures and in different time zones. It’s both exciting, fun, and very frustrating at the same time, but that have to wait for some other day.

Have fun!

When OOP stinks and when you instead should leave a smell behind…

Joacim Andersson — Fri, 06 Aug 2010 14:45:00 GMT

I just saw an interesting video blog post by the CTO of Devexpress entitled Pac-Man and Object-Oriented Programming, in which Julian talks about how we’ve been doing object-oriented programming for 20 years now (or even more than that if you come from the SmallTalk world) and how we, as OOP/OOD programmers and designers think about programming. He then quickly moves on to comparing that to a game of Pac-Man.

Now Pac-Man was a great video game developed by Namco in Japan back in 1979 and it was released in Europe and the US the year after. The game was an instant success, maybe because it was different from most of the other video games of the time, such as Space Invaders, Galaxy, and Asteroids, which was mainly shoot ‘em up games in which you should kill and/or destroy everything you saw (much unlike video games of today where we have 3D FPS games in which you walk around and kill/destroy everything you see… Oh, wait there isn’t that much of a difference, is there?). In Pac-Man you play this pie-chart looking character that walks around in a maze eating dots at the same time as you’re trying to avoid getting caught by one of the four colorful ghosts that are, for some reason, hunting you.

Whoops… Sorry! I got a bit nostalgic there for a moment and sort of strayed away from the topic. This blog post was supposed to be about object oriented programming and design and not about gaming. So let’s get back on track, shall we?

If you, as an OOP developer, would design the Pac-Man game today, how would you go about it? You should probably create a class for Pac-Man and another for the ghosts that hunts him. Well, they might actually be subclasses of a common character class since they do share some very basic logic such as they can’t walk through walls and other basic elements that you can think of. But they would still be 2 different classes. You might also have a Maze class that draws the actual maze and have some other logic like knowing which level you’re playing and such. The dots and power ups might also be different classes.

But the logic of the ghosts aren’t that easy. How will they go about to chase Pac-Man? They obviously need to know about his position but how do you calculate the closest path to get to him? The ghosts can’t go through a wall so you must calculate the nearest path around the maze. Doing that in every game cycle on a modern day computer is not such a big deal, but Pac-Man came out back in 1979 and the CPUs used at the time couldn’t do that and still produce a fast pacing game.

The solution Julian suggested was that maybe the ghosts in the game are like blood-hounds and Pac-Man is given away a scent as he moves around in the maze. The square in the maze Pac-Man just left gets a value that as Pac-Man moves on decreases in value until the scent has evaporated. This way the ghosts has no real knowledge about Pac-Man at all since they are just following a scent. The scent itself is now a property of the maze object and not of the ghost object. Julian called this anti-object oriented programming since the logic is not in the “real-world” object of the ghost (is that really a real-world object?). So by changing the logic of the ghost not to actually hunt Pac-Man but to follow a scent when they find it and also added some logic to the maze class, the anti-object, which you probably only used for drawing before.

I love this example since it’s an example of thinking-out-of-the-box when it comes to OOP and OOD. Instead of always trying very hard to make the classes as close to real-world objects as possible make a few changes and simplify the whole idea.

To be completely fair here, this is actually not how the AI of the ghosts in the original game was designed. If you’re interested I invite you to read the Pac-Man Dossier especially chapter 3 and chapter 4 that explains how the actual AI for the ghosts was created. But the fact that the actual design was different is beside the point. Julian showed a simple solution to a hard problem you might face when you’re doing object oriented design.

Have fun!

Microsoft is switching the light but will it turn on or off?

Joacim Andersson — Wed, 04 Aug 2010 15:04:12 GMT

During the VSLive! keynote in Redmond, Microsoft yesterday announced a new Visual Studio product called LightSwitch.

LightSwitch is a new SKU for Visual Studio that will allow people to create line of business (LOB) applications for the desktop and the cloud without writing a single line of code. It will also be shipped with future version of Visual Studio Pro and above. In a way it reminds me of Access but with the difference that it can use different data sources, including Sharepoint and Azure SQL. Since the announcement there have been a wild discussion within the MVP programmers community, especially among VB and C# MVPs if this is a good or a bad thing.

We have seen tools like this before that are aimed to power users who aren’t full-fledged programmers and when a professional programmer have to take over the project it’s a mess with business logic code mixed up with UI code and data access code. I have not yet made up my mind if this is good or bad, but I do see some great opportunities with LightSwitch. Since it generates .Net code, in either C# or VB, and that it does seem to use an n-tier design I feel that this tool might become very successful. Of course we have to wait until the public beta is released later this month before we can actually see if the generated code lives up to the high standard professional developers demand.

Some of the discussion has questioned if this should have been released as an Office tool rather than as a Visual Studio SKU and even though that is a valid point I truly feel that the fact this tool is made by the Visual Studio team rather than the Office team the code generation will be better since the Office team isn’t really interested in creating development tools but also that more professionals might use this for prototyping or getting a quick start application that they continue to build on. If this will be the actual usage of the tool I don’t care if a power user instead of a programmer does the initial prototyping.

In either case I’m looking forward to giving LightSwitch a try as soon as the beta have been released. Several videos will be released showcasing LightSwitch during the next few days/weeks on the LightSwitch home page. Have a look and make up your own mind. Jason Zander, who held the presentation at VSLive, also wrote an excellent blog post about LightSwitch that demonstrates what it does and what it can be used for.

So what do you think? Are tools that hides the complexity of programming a good or a bad thing? Feel free to leave a comment.

Have fun.

At your service (part II) – ASMX Web Service vs WCF

Joacim Andersson — Wed, 16 Sep 2009 15:55:00 GMT

Introduction

Last time I demonstrated how to develop a Windows Communication Foundation (WCF) service. This time we’re going to look at the differences between a ASP.Net WebService and a WCF service. The biggest difference between them is probably that a WebService only can be activated via HTTP and they are tightly coupled with ASP.Net HTTP pipeline. A WCF service on the other hand can be bound to a large variety of network protocols. It also doesn’t require that it is hosted on a web server, it can be hosted in a console application, in a Windows Forms app, or in a WPF application. However WCF does have an ASP.Net compatibility mode setting to enable WCF services to be configured like a web service and also mimic their behavior.

Data representation

A WebService relies on the XmlSerializer to serialize types into XML and back to a .Net type. The following is a list of the things XmlSerializer can serialize to and from XML.

Only the public properties (or fields) of an object.
Collections can be serialized only if the implement the IEnumerable or ICollection interfaces.
Classes that implements the IDictionary interface, such as Hashtable, cannot be serialized into XML.
You can use attributes from the System.Xml.Serialization namespace on your own classes and members to control how instances of that class will be serialized.
You can also generate classes that can be serialized into XML from definitions of the types in XML Schema using the xsd.exe command line tool.

Point 4 and 5 describes how you can define complex types (classes) that can be serialized to and from XML.

In WCF you would also usually begin with the definition of complex types which is done adding the DataContractAttribute and the DataMemberAttribute to the class and its members, as described in my earlier post. The DataContractAttribute can be used on classes or structures and the DataMemberAttribute on properties and/or fields, which can be either private or public.

A few important differences between the DataContractSerializer and the XmlSerializer are:

The XmlSerializer serialize all public fields and properties, while you have better control using the DataContractSerializer.
The DataContractSerializer has better performance over XmlSerializer.
The DataContractSerializer can serialize Hashtables.

Service Development

To develop a WebService you would normally decorate a class with the WebServiceAttribute and each method with the WebMethodAttribute. This is however not an optimal solution since it does not constitute a contract for the operations performed by the service. ASP.Net 2.0 tried to rectify that by allowing you to use those attributes on an interface as well. That is the preferred method of doing it since the service contract can be reused with various classes that can implement that interface.

A WCF service requires you to create a contract, since the ServiceContractAttribute only can be used on an interface. So a WebService allows you to constitute a contract but doesn’t enforce it while a WCF service do.

A WebService only incorpartes BasicHttpBinding while a WCF service can use a wide range of bindings, such as WSHttpBinding, NetTcpBinding, NetNamedPipeBinding, amongst others.

Hosting the service

ASP.Net web services are hosted on a Web Server. A WCF service can be hosted on a Web Server but can just as well be hosted by a Console- or Windows Forms application.

Conclusion

I don’t want to make any conclusions about which technique is the best to use, because that depends on the specification. A WebService is usually easier to develop but are somewhat limited. A WCF service is more versatile but can be harder to develop. To make a true comparison you should really compare the two techniques if you want to host the service on a Web Server, such as IIS, since if you want to use another host you can’t use an ASP.Net WebService. I just leave the judgment up to you.

Have fun!

GetType and TypeOf confusion

Joacim Andersson — Mon, 31 Aug 2009 05:18:46 GMT

Both VB and C# have an operator called TypeOf (or typeof in C#) but they perform two completely different things.

In VB there are also two kind of GetType() calls, the object.GetType() method which is part of the .Net framework and the VB language specific GetType() operator.

Are you confused yet? Don’t worry, in this article I will try to explain the difference between these operators and the object.GetType() method.

The TypeOf, typeof, GetType operators

The VB TypeOf operator is used together with the Is keyword and is used for checking if an object is of a particular type.

result = TypeOf x Is String

If “x” above is a string then “result” would be True otherwise it is set to False. This operator have existed in VB since long before .Net was born. The equivalent for the TypeOf operator in C# is simply called the is operator.

result = x is string;

The typeof operator in C# on the other hand returns an instance of the System.Type class containing type declarations of the type you pass to it.

Type t = typeof(string);

The VB equivalent of the C# typeof operator is the GetType operator.

Dim t As Type = GetType(String)

The reason for the different names are simply because of the fact that TypeOf was already a reserved keyword in VB and I guess the C# team didn’t have VB in their mind when they designed C#. :)

The difference between Object.GetType and the GetType operator

On a trivial level, the Object.GetType() method operates on an object instance while the GetType (and C#’s typeof) operator operates on a type.

Dim s As String
Dim t As Type = s.GetType()
Dim t2 As Type = GetType(String)

There are no differences between “t” and “t2” in the above code. So why do we have to have both of them? Well, you might not know what type a certain reference is made of in which case you obviously can’t use the GetType operator since that requires that you pass the type. Have a look at the following example:

Public Class MyBaseClass
End Class

Public Class MyDerivedClass
  Inherits MyBaseClass
End Class

Module Test
  Public Sub ShowType(ByVal obj As MyBaseClass)
    Dim t As Type = obj.GetType()
    Dim t2 As Type = GetType(MyBaseClass)
    Console.WriteLine(t)
    Console.WriteLine(t2)
  End Sub

  Public Sub Main()
    Dim myObject As New MyDerivedClass
    ShowType(myObject)
    Console.ReadLine()
  End Sub
End Module

In this example the ShowType method takes a MyBaseClass parameter and t2 uses the GetType operator to get the System.Type representation of MyBaseClass. So when you write out t2 to the console it will write MyBaseClass. However when you use the GetType method on the obj parameter it will write MyDerivedClass to the console. It is legal to pass a reference to MyDerivedClass to the ShowType method since it inherits from MyBaseClass so that will be a widening conversion. So inside the ShowType method we will never know if the parameter contains the type we have declared it as or if it contains any subclass of it, to find out we need to use the Object.GetType method.

Another difference between the method and the operator is when you’re dealing with value types.

Dim i As Integer
Dim t As Type = i.GetType()
Dim t2 As Type = GetType(Integer)

In order to call i.GetType() above i must first be converted to an Object which means a boxing conversion has to be done. Using the operator no boxing conversions are made which in this case makes that call faster.

I hope this removes some of the confusion about this subject, if not please feel free to leave a comment.

Have fun!

Boxing and Unboxing in .Net

Joacim Andersson — Mon, 31 Aug 2009 01:41:32 GMT

In this article I will try to explain the concepts of Boxing and Unboxing. There are two types of objects within the .Net framework, value types and reference types. Value types are stored on the stack while reference types are always stored on the heap. Converting a value type into a reference type is called Boxing while converting it back from a reference type to a value type is called Unboxing.

Value Types

Value types are primitive types like System.Int32 (Integer in VB, int in C#) or System.Double. These types are mapped directly to the Framework Class Library (FCL) and are all derived from System.ValueType. Apart from the regular primitive types (integer, long, single, double, char, and so on) Enumerations and Structures also inherits from System.ValueTypes so they are also stored on the stack.

Reference Types

All classes are reference types and they are stored on the heap. So when you create a new instance of a class using the new keyword, memory are allocated on the heap for the object and the memory address is returned. Strings are a special case since they are also reference types, even though they are often treated as if they where value types, but that’s not the case. The difference is that you don’t have to create an instance of a string in the same manner as you would with another class.

Reference types are also Nullable, meaning that you can set the reference to Null (Nothing in VB).

Widening and Narrowing conversions

Before we go into the Boxing and Unboxing I would like to take a moment to explain the difference between a widening and a narrowing conversion. A widening conversion is always safe since there is never any risk of any data loss. For example converting an Integer into a Long (System.Int64) is a widening conversion. There is no integer value that doesn’t fit into a Long so you can always do that. However doing the opposite, converting a Long into an Integer is more risky since there are a chance that you will lose some data, since a Long can contain a number that is too high (or too low) to fit into an integer.

You can always use an implicit conversion when you do a widening conversion.

Dim i As Integer = 3
Dim l As Long
l = i 'Implicit conversion

However to do the opposite, a narrowing conversion, you need to do an explicit conversion.

i = CType(l, Integer) 'Explicit conversion
'or
i = CInt(l) 'Explicit conversion

If you don’t do an explicit conversion when you’re doing a narrowing conversion you will get a compilation error so your project will not compile (Note, VB can allow you to do an implicit conversion if you have Option Strict set to Off, something I strongly advice you not to have, C# however will never allow it). If the Long value does not fit into the Integer you will however still get a runtime error since the system will then throw a System.OverflowExeption. So when you do a narrowing conversion you must be sure that it can be done.

Doing Boxing/Unboxing

As mentioned earlier Boxing refers to the conversion of a value type to a reference type.

Dim i As Integer = 3
Dim o As Object
o = i 'Boxing the Integer into an object (reference type)

Above I do an implicit conversion of an integer to an object. This is possible since it’s a widening conversion so there is no risk of any data loss. However doing the opposite, converting the object to an integer is a narrowing conversion, where there is a risk that data will be lost.

i = o 'Implicitly doing a narrowing conversion (not allowed)
i = CInt(o) 'Explicitly doing a narrowing conversion (allowed)

In C# if you have boxed a particular type you must unbox it to the same type. You can not box an integer to an object and then unbox it to a long.

int i = 3;
long l;
object o;
o = i;
l = (long)o; //will throw a System.InvalidCastException

For the above to work, you must first unbox it to an integer and then cast it to a long.

int i = 3;
long l;
object o;
o = i;
l = (long)(int)o;

However the VB’s type conversion functions (CType and the more specific CInt, CLng, CDbl and so on) does allow this.

Dim i As Integer = 3
Dim l As Long
Dim o As Object
o = i
l = CLng(o) 'allowed

End words

I hope that you by now have a better understanding of Boxing and Unboxing. So let me end this article by saying that you should avoid doing this if possible. Doing type conversion is time consuming, and that is especially true when it comes to Boxing and Unboxing since data have to be transferred back and forth between the stack and the heap. Using Generics, which has existed in .Net since version 2.0, is a much better approach than having to deal with value type to reference type conversion.

I will cover Generics in a later article.

Have fun.