Consulting services and com adventures

  • Article

In the last month 50% of my time was dedicated to consulting services. most of it to outside customers. one of them is Cyber-Ark. they have a cool product named a Vault, it's a secure place when you can store anything you like (ever thought where to store your private keys?), recently they had a few big contracts, one of them is for a big company in the US. as many major companies this one two develops in .net. so cyber-ark exposes their api almost to any environment (com, simple api ....) but for .net. the people at cyber-ark are some of the most talented people in the industry, they are all experts in their field , real professionals. they knew nothing about .net ,they are familiar with com , c and c++.

so first we started with an introduction into what is the clr , what services provides and why is that so good for us, I explained all the .net Buzz words like GC , managed references and stuff, I tried to give them the difference between thinking in com and thinking like they are used to in c++ . some of the things we talked about:

  • we now have constructors, in com no code was allowed in the constructors - things like throwing exceptions from constructors was forbidden, so instead of writing an init function or calling some Set methods we could simply declare a CTOR - and more than one ;). while this looks simple enough - it's important to mention it to guys that swim in com for the last 2 years.
  • exception strategy. Exception in .net must derive from System.Exception where as in c++ you could throw anything from an int, string to an object. Exception weren't there in c++ from day 1 (same as templates) so sometimes for the sake of being compatible with different c++ compilers on different platforms Exceptions were abandoned. in com we used HRESULT which really is an error code. when I look back I really don't understand how we could write big projects without exceptions. so as a strategy we wrapped all the HRESULT's and com errors to .net Exceptions so clients using the .net api wouldn't t need to know that the underling implementation is in com.
  • Collections #1 - they have some collections that needs to be displayed in the gui, the first thing we did is implementing some key interfaces like:IListSource and IBindingList , the last one is not so simple. once we did this they dropped a datagrid and binded it like a dataset - simple and amazing. you can find a sample HERE
  • Collections #2 - deriving from CollectionBase (did you know there is a class named BaseCollection - for internal use). there is a guy there named nir livni, Ihad the pleasure of working with him for 2 years in my former work place, it really amazes me to see how he thinks. the first thing he did regarding .net is assuming things are there (in the framework) so when he needed new things he first looked for it. this is something I can't say about most of the new programmers to .net. most of them think in c++ where you had a poor framework and lots of libraries, the libraries are so sophisticated and complicated that most of them wrote their own utils. so concerning Collections - it's best when GetEnumerator will return and instance of newly created class because foreach calls Dispose on the class after the loop
  • IDisposable and a finalizer - since they wrapped their com objects in .net , calling dispose is a must much like it's beeing done in winforms with a second Dispose method that accpets a bool , this bool specifies wheather it is called from the finalizer or from the original dispose.
  • HttpModule - since their enviroment will be hosted under IIS and the programmers will need some kind of an environment , we took the AOP approach and implemented an http module that intercepts all the calls and put stuff on the httpcontext and setup a secured environment for the programmer.
  • NUNIT - doing unit testing for everyhthing - really helped them achieve their goal.

one tough bug we encountered was concrening an implementation of a com Singelton. the only reason I mention it is because it is very wierd. in order to implement their singleton they used this article. what was strage is when they checked the refernce count on the object it was 3 on more than what they expected. we opened a new console application and called the singleton and there were only 2 refernces, did the same from a newly created asp.net application and there were 3. so as far as I know there isn't supposed to be any diffirence between calling from asp.net or a console. at the end we implemented a singleton at the .net side and dumped the com one.

 

 

I don't remember who said it but it goes like this : "I don't like programming languages that make me feel stupid, c++ is one of them" - .net rocks