Going C# & ASP.NET 4.5 – oh my

8 Years Ago
Disclaimer: If you're not a developer using our products this post may not interest you. From a business / end users perspective our products will not change. Of course we are adding some great new features & improvements within the next releases to hopefully keep our business and end users excited.   

We've been working on some significant changes quietly over the previous couple of months. It's Sunday so I thought I would take some time out to let you all finally know the big news.  

A little context first…

For many years our products have been written in VB.NET. This was the natural choice for me when I developed the first versions of InstantForum & InstantKB coming from a VB6 / Classic ASP background – I'm showing my age here. Over the years things have evolved we've always tried to keep our products current but I've known for a little while now we need to take a step back and make some significant decisions to ensure we can continue to thrive far into the future. 

The time has come. 

Whilst VB.NET has served us well I think it's fair to say its popularity is in decline amongst the .NET community. There are many reasons for this which I won't go into here (it would take me a very long time) but ultimately we took the decision in late 2012 to start migrating our core common libraries and all product specific source code over to C#.
So going forward we will continue to support our existing VB.NET customers however InstantForum , InstantKB & Influx will be provided in ONLY C# from the next major release of each product.  

Phew- I'm nervous telling you all this – it's a bold decision but we feel the right move.

I'm both sad and excited about this news. I loved VB for many years it's what got me started in the VB6 days but nowadays it's a little verbose compared too many other languages.  For me personally C# is much more productive and naturally lends itself towards cleaner, easier to read code. I think this view is shared by many developers which is why C# has become the predominant .NET language over the years. This is of course just my personal opinion. I've been know n to be wrong :P

Whilst migrating our code to C# we've also took the opportunity to do some major refactoring and some fairly significant architectural changes.  Some areas of our code were becoming dated. These areas were often difficult to maintain or extend slowing us and our customers down during development.
We really wanted to address this and take advantage of newer features available in the .NET framework (generics, extension methods, C# dynamics) to have less boiler plate code throughout our framework and ultimately provide a more productive experience for developers working with or extending our products. 

So what's changed?

There are really only two major architectural changes at this point globally throughout the code as we didn't want to introduce to many bugs. We've also made lots of little changes to improve and clean our existing code. To help I've detailed the changes you can expect to see soon below…

New Data Access Layer

We've rewritten our data access layer to introduce the unit of work and repository patterns. These design patterns are popular in many modern ORM tools and MVC apps. We've opted to stay clear of using any type of full blown ORM – ef, linq-to-sql for performance reasons. We are still working very close to the metal with the native SqlClient classes however we have now implemented IQueryable of T methods within our generic repository base class which will allow you to easily return strongly typed collections and filter further using linq queries. The new DAL also requires significantly less code to wire up basic CRUD operations which will make it easier to use going forward.  


One of the problems that bothered me with our existing code base was its lack to extensibility. We really didn't follow the open closed principal very well. We would often have a customer ask if they can change how a specific piece of functionality works without having to modify the core code and most of the time we would need to say you'll need to modify the code. Whilst we offer a plug-in model this only really interacts with the UI and provides little access to underlying functionality. 

We've now introduced the concept of interchangeable providers for core services. Think of these similar to the membership providers you can swap in ASP.NET. For example if you wanted to change how our data caching or scheduling worked or swap out how and where user data was stored (in your own persistence layer) this should now be possible with our new provider model.  

As a developer you can optionally define your own provider classes within the web.config. You simply add your class type that will be instantiated for the specific provider. This class will inherit from our relevant provider's abstract base class leaving you free to add your own concrete implementation for the provider. We are taking this approach throughout our updated code base where it makes sense to abstract the implementations and generally make our code more flexible going forward. 

Readability Improvements

We've removed all fully qualified namespace references within classes (replacing these with using statements at the top) to make for better readability.  

We've removed all unnecessary comments from the code. All those comments that state the obvious I.e. (open database connection, iterate through collection etc). We have left some comments to help explain the code when it's not immediately obvious. 

Namespace, class & organizational changes

We've restructured our namespaces & some class names to bring these more inline with modern MVC naming conventions. Whilst we are not quite MVC yet we wanted to update our core libraries first to make this transition easier when the time comes. 

Security Improvements

This one has been requested by quite a few customers and it's something I've been eager to get ready for a little while. We are now moving to salted SHA256 (with optional SHA512 support) for password hashing with our next major release. Existing customers won't be able to take advantage of this feature unless you perform a global password reset. We are hoping to provide migration steps towards release to help each the transition. Stay tuned. 

Moving to ASP.NET 4.5

We are now leveraging the ASP.NET WebAPI controllers introduced in in MVC 4 to provide a rest based services layer. Going forward our products will require ASP.NET 4.5. 

General FAQ

Will the next update include a MVC web project?

No sorry. We would love to offer a MVC version of our software. Unfortunately with the next release we won't be quite ready however the changes we've made so far will help for the future. This is very much on the road map and we hope to have news soon. We've been doing lots of work with MVC 4 recently to sharpen our skills for when the time comes.

Will these changes break the current API?

No. We've deprecated all methods and marked these as obsolete with comments within the existing API pointing you towards the new methods. You can still use the deprecated methods and they will return the expected results. 
Will I be able to upgrade from the current VB.NET products to the new C# versions?
Yes absolutely. We'll have documentation to assist with this once released. Infect our C# update will be a free update once released to any customers that purchase our products from today. 

I love VB and still use it as my primary language in projects. What about me?

It's been a tough decision to move towards C# and not something we have taken lightly. We will continue to support our VB.NET versions and will offer hotfixes for any significant issues far into the future.  I'm sincerely sorry if you are a VB.NET developer and don't like this news. We feel the time is right now to make the transition. We are only a small team so I'm afraid we really have to choose between C# or VB.NET we can't maintain two separate versions of each product going forward. 

To help we'll be ensuring we provide any published code samples in both C# & VB.NET going forward. Of course you can still reference our C# assemblies from your VB.NET projects or add our C# projects to your VB.NET solution and add project references however if you wanted to modify our code directly this would require some C# knowledge. I think it's fair to say if you can write VB.NET you can write C# code also with very little work. There are many free tools available to help you convert code. 

Final Thoughts

I hope the majority of you welcome this move towards C# as positive news. If you have any questions or comments as always please don't hesitate to email me directly, post your comments below or pop your thoughts in our community forums. I would love to hear from you. 

We are close now to having a release we would be confident to call a beta. I look forward to posting further updates as quickly as we can and as always thank you all for your continued support, 

On a scale of 1-5, please rate the helpfulness of this blog entry

Not Helpful
Very Helpful
Optionally provide your comments to help us improve this blog entry...

Thank you for your feedback!


No Photo

Ryan Healey posted 8 Years Ago
Support Guru with 103 recognition pointsSupport Guru with 103 recognition pointsSupport Guru with 103 recognition pointsSupport Guru with 103 recognition pointsSupport Guru with 103 recognition pointsSupport Guru with 103 recognition pointsSupport Guru with 103 recognition pointsSupport Guru with 103 recognition points
Many thanks. We've just posted further news on our 2013 update expected soon...

Member Photo

PeriVitton posted 8 Years Ago
New Member with 3 recognition pointsNew Member with 3 recognition pointsNew Member with 3 recognition pointsNew Member with 3 recognition pointsNew Member with 3 recognition pointsNew Member with 3 recognition pointsNew Member with 3 recognition pointsNew Member with 3 recognition points
I have never used your products but your post has succeeded in convincing me to try them once. So waiting for your next release.

Add Your Comments

Comments require login or registration.