These days it’s hard to find someone who doesn’t know about Twitter as a social networking status updating site mainly founded in 2007 with the very simple and basic idea to let people share their status on the web with 140 characters and follow others’ updates.

I was among the first group of users who appeared on Twitter and have been continually tweeting for almost three years to now, so I’ve been able to witness the progress of the site and the way it evolved.

The idea behind this service was very simple that had been tried by some other sites before, but Twitter was able to gather a reasonable number of known people to incorporate because it had a very simple and basic structure, and was founded by some of the well-known names on the web. In this while many rivals have appeared to challenge this success but none of them could go so far.

As many other people have stated already, in my opinion over half of the Twitter’s success was related to its simple idea and implementation that despite the technical issues in all these years, has helped it survive and get more users. This simple core allowed developers and other companies to build services and sites to complement the basic structure and make it suitable for specific applications, and inspire it as a general platform for content publishing for various applications; therefore, a diverse group of users benefited from the service whether for personal updates, entertaining stuff, technical matters, or anything else.

Like any other service or site, Twitter had its own progress. From a perspective, there were two waves of progress for Twitter: the first wave was the appearance of new users as individuals, companies, or authorities, and the second wave was the addition of new features by Twitter leadership to improve it or by adjunct services or client applications to simplify a task for the users. Most of the features added to the core service/site were inspired from these third party tools and projects that could gain a widespread popularity among users.

Both these waves had a good progress and quickly took Twitter from a very lower point to somewhere that is now a de facto standard of online communication among many individuals, colleagues, companies, media, and politicians. I can exemplify this by pointing to the main role of Twitter in post-election events in Iran or its usage for communication between the American nation during the last presidential election. Likewise, it’s used widely to share the news, opinions, and interesting updates about some events such as Microsoft, Apple, or Google conferences.

On the other hand, as I had written before, Twitter and micro-blogging came to challenge blogging and had their obvious impact on the frequency and quality of blogging and online publishing for almost everybody around the world.

However, despite all these matters, recently I came to the conclusion that Twitter has begun to worsen, and is slowly losing its active role on the web, and that’s the reason for me to write this blog post.

I think that there are three main threats challenging the future success of Twitter:

• Development of the service and appearance of more users, specifically ordinary people, on the site without considering a good mechanism to maintain the privacy and quality.
• Leaving the simple nature of the service by implementing some new features by Twitter leadership/developers.
• The advent of Twitter spammers and spamming on the site specifically in the trending topics.

The Number of Users - A Double-Edged Sword

The first and foremost threat for Twitter is the number of users! With almost no exception all the social networking sites founded during the Web 2.0 era had a similar progress starting from a lower point, evolving with a good speed by adding good features and attracting users, and stopping at a higher point, then slowly losing the quality. The only exception that I can note is Facebook and I’ll explain why.

Apparently the number of users is a very important factor in the success of a social networking site (even though I personally consider the level of education and sophistication of the users as the primary factor), so all these social networking sites compete to get more and more users on board. This isn’t necessarily bad because it brings a wider community of people to contribute and improve the level of communication and information sharing. But if not handled in a good way, this also has its own drawbacks that even can drive the whole community to a bad point.

Usually social networking sites begin with a small group of users that are often technical people and community leaders. These users are innovative, sophisticated, and well-aware of the culture of online life, so they communicate wisely and take the site to a better point. When new users, that are mostly more ordinary people, come to such sites, less or more, they lack that level of sophistication and awareness and it can have a huge impact on the quality of the content. If the site administrators don’t handle this wisely, it can cause the growth of mushroom-like groups of users who disturb the site. I think that everybody can notice this on many of the social networking sites such as the first-wave sites like Orkut or middle-wave communities like MySpace.

I believe that the best way to prevent such issues on a social networking site is to isolate users to some degree, so they let each other communicate if and only if they’re interested to do so. In other words, a powerful privacy management mechanism can maintain the independence of users on a site, so even if someone is bothersome, he or she bothers his or her friends/contacts only. I believe that this is the main reason for Facebook that has let it continue its growth and success. Facebook allows all users to have full control on their privacy settings and share certain information with their friends.

In my experience (that is easily provable by reviewing the history of social networking sites) the number of users is a double-edged sword that if controlled and managed, can help a site succeed, otherwise, it becomes the main weapon against the site, itself!

Unfortunately, Twitter lacks a good mechanism to allow its users to maintain their privacy. While I’m a big advocate of simplicity in the core service and site (as I’ll explain in a moment), I strongly believe that the privacy is the only area that mandates a lot of features even complex features. Being able to make something public or private/protected is not enough! Here I note that obviously the type of privacy settings would be different from Facebook or other sites. For instance, I always wanted to be able to hide certain people that I’m following from the public eye to prevent some people from stalking (thank to Steven Smith for introducing me to this term).

Recently I protected my own Twitter account and removed many of my followers for this specific reason. Since then I’ve been rejecting most of the follower requests to keep a small but active group of followers for myself who aren’t possibly a threat to my privacy.

Complexity - Back to 90’s

In the introduction text I stated that simplicity was the key factor for the growth and success of Twitter but in the past couple of months they have forgotten this principle and have been adding some unnecessary features (in my opinion these features are redundant for the main site) with a very bad implementation. Two notable features are the Lists and the Retweet button. Not only these features aren’t necessary for the site, but also they’re implemented in a very ambiguous and complex way, so still I have difficulties in understanding which is which with each feature. In my honest opinion Twitter hasn’t made things complex. It has taken an step further and has returned to 90’s days of poor user experience needing a guide to teach each and every user what to do!

I’d like Twitter to be as simple as it was before, with a textbox that lets me write 140 characters of text only, and I’d like this service to be complemented by a rich API that allows me to expand this basic idea for anything I need. If I want to Retweet, then I can go and download from hundreds of clients that have much simpler and richer Retweeting features. If I want to categorize my contacts, I can go and use one of those clients or online services.

Basically, it doesn’t make sense to see Twitter leadership focusing on these redundant features while there isn’t a single day that all users don’t  see those funny errors. Why don’t they concentrate on scaling up the service to handle all the requests rather than adding new features? Isn’t it obvious that the former one has more priority?

Spamming - The Old Enemy of Content

The last main threat to the success of Twitter is our old friend, spamming. This one is the natural cause of this type of content publishing. There are various types of spam and tweeting has its own spam as short text messaging does. On Twitter there are two general types of spamming: one that follows many users to receive some mutual followers to publish advertisements for them, and another that uses the popular trending topics to promote something in front of thousands of eyes. These spam updates are slowly growing and disturbing the relevance of content.

The problem with Twitter is that it still doesn’t have a very effective mechanism to block these spammers and filter the content and solely relies on user reports. Of course, one technical difficulty is the length of Twitter messages that are short enough to prevent automated anti-spam methods from filtering them.

Conclusion

All in all, I haven’t liked Twitter recently as I used to in the past. Different people have different expectations from the people they follow and from the general content. Some people are interested in technical discussions, while some others are interested to read technical news and links. There are some users who like to see personal status updates, but there are others who like a combination of different types. There are even people who just want entertaining images, videos, and jokes!

I’m not very interested in those personal status updates even though I don’t reject them all, but there are some users who salt it!

Besides, in my understanding the usefulness of live event reports is lowered on Twitter as there are more people who repeat something over and over. One instance was this recent PDC09 event where I was witnessing something repeated by many people. Believe me, it becomes boring at some degree! I’m lucky to follow a very limited group of community leaders only!

To summarize my discussion I have to say that Twitter needs to revisit its new strategies, otherwise I can’t imagine a better future for this site. You, as dear reader, may argue this and oppose to my statements here but usually such predictions rely on experience, and only time can prove what is right and what is wrong.

As of my own Twitter account, I’ve been thinking about stopping it and continuing everything on my Facebook profile where I’ve been so active recently. I think that tweeting doesn’t have much value for this world while I and many other people can save our time and effort to use them for more beneficial tasks.

It’s PDC time, and unlike the last two conferences, I haven’t been very active in publishing the news and my opinions about it. PDC used to be one of my favorite technical events before, but to be honest, the last two conferences were very disappointing for me.

As you may have noticed, these days I’m more like a listener than speaker, and would like to read others’ content rather than writing my own blog posts on different topics, however, this great post by Frans made me write my own opinions on Windows Azure and cloud computing stuff that are being presented in this huge atmosphere by Microsoft because I believe that this whole thing is not a big deal to have such a noise around it, and somehow Microsoft is exaggerating about the products that it has provided in this area.

In PDC 2008 and 2009 Ray Ozzie has been focusing on Windows Azure and the nature of cloud computing as the future of software world and Microsoft development technologies, and has been stressing that they’re trying to provide an integrated set of tools and a unified model of software development based on cloud computing for Desktop, Mobile, and TV devices.

I have no comment on the latter assertion as I also admit that Microsoft is good at providing integrated solutions and it’s one of the main reasons for its success in this field, but I think that I’m not at the same line with Microsoft and some fellow community leaders on the importance of Azure at the moment. In essence, I believe that Microsoft has missed many things in between that had to come before Azure in the mainstream and has quickly jumped to something that is far (maybe impossible) from becoming the main concern of common software development scenarios. I try to develop this and explain my reasons in the below paragraphs.

I know PDC as the main Microsoft event for developers in which they try to introduce and showcase the newest products for software developers, and have a set of different sessions in various categories to teach developers some general information about the new technologies to get them started, and send them to the community and their companies in order to promote these products and spread the word. PDC 2003 and 2005 were great examples of this strategy and I can recall them as two great conferences that had a huge impact on the Microsoft community and follower companies for years.

In my opinion Bill Gates was a great leader for Microsoft and one of the key points of the long-time success of the company was the fact that he was able to predict the main requirements of the software world to invest in them. He knew when to enter the video gaming field by a console, and when to enter the mobile world with Windows Mobile. On the other hand, he also had some mistakes and one of them was the inability to recognize the importance of online search and advertisement, and they’re still unable to catch Google in the field!

PDC 2000 and 2001 focused on the .NET Framework and new generation of Visual Studio and in 1-2 years they became the mainstream because there was a huge demand for a cross-platform technology for software development. In PDC 2003 and 2005 they introduced enhancements in the .NET Framework and new technologies such as ASP.NET 2.0, ASP.NET AJAX (formerly known as Atlas), WCF, WPF, and WF, and you saw that they had their own demand in the past few years.

Here I’d stress that the reason that all these products could succeed was the real demand that was there for them among ordinary software developers and companies for common software projects. The set of classic controls and wizards in ASP.NET 2.0 or ease of AJAX development in ASP.NET AJAX were some stuff that were becoming the common demand for developers.

But PDC 2008 and the current one, 2009, are far from that point or at least it’s hard to believe for me that the main topic of these conferences, Windows Azure, can have that demand in the coming years. I think that Microsoft leadership has the wrong imagination of the current situation in the software world.

The first question that comes to mind is about the importance of cloud computing in the main software development world? Putting some discussions that support the assertion and are all made by evangelists aside, do you, as some ordinary software developers, believe that cloud computing is the main area of the software world in the next 3-5 years? What is it coming to solve? What is it coming to help with? Are these concerns the main concerns of all software developers, teams, and projects, especially yours? In my experience, the answer is a simple “No”!

The second question is, if cloud computing is really necessary, do we really need such a big and complex structure to respond to our needs? Why can’t we use another solution such as those provided by Amazon or Rackspace? Why should we go this far and put all this effort in Windows Azure? In other words, even if cloud computing is a major concern, what are the advantages for Azure over its smaller rivals that are simpler and easier to implement? Even if there are some software projects needing a cloud solution, I do think that most of them will be satisfied with very simpler solutions.

The other challenging point is about the precedence of cloud computing in comparison with other requirements in the software world. How can you run a software on cloud when a simple change and redeployment requires a recompilation? Yes, I know that Dynamic Extensibility has been a field of work in the .NET Framework but it seems that it has more priority and precedence over cloud computing while it hasn’t received it yet.

The last point is somehow related to the politics of software. Considering that Windows Azure is going to host enterprise large-scale applications, we all know that most of such applications fall in two categories: strategic applications (such as those written for banks, militaries, etc), and big commercial applications that would be comparatively less. How many governments and banks are ready to host such strategic applications on Microsoft data centers? I think that you know the answer yourself!

Besides, this Azure wave is something more like an imposed discussion by Microsoft evangelists to the community than something really demanded by people, themselves. There were noticeable demands for say, new features in ASP.NET 2.0 or ASP.NET AJAX, but I can’t see such a demand except those encouraged by Microsoft evangelists.

Having all this stuff said, to me it seems that in the current economic situation the best thing to work on is some ways to automate the Software Development process, accelerate the coding speed, and reduce the overall costs of a project for companies. I think that this could be a better area to invest in than cloud computing.

As a side-note, it’s very interesting for me that Microsoft conferences have become a place saturated with evangelists to spread a noise about something to advertise it. Microsoft wants to force people to accept its products and technologies rather than attracting them to use. At this point, some readers want to find me and kill me!

The bottom line is that they can waste much money on holding such relatively expensive conferences, giving fantasy keynotes with 3D glasses, and asking people to cheer them (the people who have paid to come and watch this fantasy), but the software market in the world is demanding something else, and if they can’t respond to these demands, they’re letting their rivals take the power. What I see is a huge group of community leaders and talented people who prefer to stay at home, and even don’t watch these keynotes and follow the stuff because they’re becoming so boring.

Windows Azure should be a great technology for a company like Microsoft to host many of its own services and upcoming integrations on it, but I doubt that it can be something appropriate for the main body of the software world.

My blog subscribers would remember that earlier this year during the new Persian year holidays I had a short trip to Shiraz and Isfahan, wrote about my trip, and uploaded a huge batch of photos to Flickr. It’s a matter of a fact that Iran is saturated with historical sites and natural attractions very suitable for tourism, but after the Islamic Revolution, the new regime hasn’t done much to maintain these sites and advertise to attract more people to come, visit, and enjoy them.

Fellow .NET community members, specifically those who are active in the ASP.NET development, should know Mads Kristensen as one of the ASP.NET community leaders, Microsoft ASP.NET MVP, and the founder of BlogEngine.NET that is one of the very prominent and widely-used blog engines powered by ASP.NET.

At that time Mads had seen my photos, and as a very active tourist who has travelled to many countries, he told me about his interest to come and visit these places. Fortunately it didn’t take that long for him to make his travel arrangements and finally he arrived at Tehran with a group of friends yesterday.

Mads and his group have a very busy schedule to go to Shiraz, Yazd, Isfahan, and Kashan in the next days and leave Iran, but I was lucky to meet him in Tehran tonight.

I spent a few hours with Mads and one of his friends, Tobias Haagen Michaelsen, who's also a professional Software Developer.

Since Microsoft is not that old and after our revolution in 30 years ago, there were comparatively less tourists coming to Iran, I think that Mads Kristensen is the first prominent .NET community leader who’s coming to Iran.

We had a traditional Persian dinner together (even though I was on one of those bad diets and couldn’t eat anything more than a few pieces of Iranian Kebab) and talked about Iran’s history, all these distinct races living in Iran, our culture, our customs, my own plans, and of course, the software world.

Mads and his friends are going to leave Tehran tomorrow but they’ll stay in other cities for some days and visit many places in different central areas. I hope that he and his buddies enjoy their trip to Iran and this makes good memories for them from our country and our people.

Not only in the software world, but also in almost every aspect of our life, sometimes we need to make small movements rather than making big plans just in order to activate a work and let it proceed. I think that this BlogML release is such a minor change to reactivate the project after a long time.

Background

Unlike what some people think about the BlogML project as something originally started by me, BlogML was a pet project started by Darren Neimke in 2005 with a few initial versions that subsequently improved a proposed specification and a corresponding .NET API. The idea behind BlogML was simple yet nobel: to represent the content of a blog with an XML derivation. There were two general advantages for such a format: the ability to back up/restore the content of a blog on the same blog engine, and the ability to move the content of a blog from one blog engine to another.

Version 1.0 of BlogML was the first mature version that could earn a good reputation and wide usage on the .NET community, and I joined to the project and Darren at this point by implementing a converter for Telligent Community Server.

Since then I was an active contributor to the project for almost two years and got the help from other team members to take the project to the next level. We moved the project from GotDotNet to CodePlex as one of the first projects hosted on the new open source community by Microsoft, and implemented BlogML 2.0 specification and .NET API to releas it in September 2006 in which we basically added a set of new features to the project. Version 2.0 has been the most stable and widely used version of BlogML ever, and since then we’ve been hearing about new implementations and migrations done by this standard. We even heard about the good use of BlogML on other communities while BlogML is already a part of all prominent ASP.NET blog engines.

To be honest, I have to admit that BlogML needed more attention after version 2.0 and could be much better, but my military service and the fact that no one else had taken any role in leading the project suspended everything. There were some errors and complains as well as comments and suggestions reported for the project, but being busy with my conscript and books, I had no time to think about this project.

I had a few attempts to implement a new version of specification and the .NET library in this while but the codebase, itself, was also daunting enough to distract me and stop my work.

As a matter of a fact, BlogML is a great idea and the best of its kind and the proof for this assertion is the growing usage of this standard despite its long suspension and some problems it has. But its original design that was inherited in later versions isn’t relevant for today’s software world at all. There is no documentation for the specification and API, and things are ambiguous for someone new. Additionally, the Writer part of things are implemented by manual XML operations while the Reader part is implemented using the serialization techniques in the .NET framework. Having these said, one big problem for solving the issues was that I had to maintain the compatibility with the previous versions and some inheritances were restricting me from going far. It’s also worth saying that we didn’t have time to unit test the .NET API for version 2.0, so we couldn’t have a good level of quality assurance in that version.

Therefore, all my attempts failed in reactivating the project until just recently when I finally decided to go for a fresh new .NET API that doesn’t care much about the old structure. I was smoothly working on this new version until Saturday when Phil Haack reminded me of a few issues specifically a very bad bug in the .NET API that forced me to drop a minor version as 2.1 to resolve this issue.

Seeing this encouraged me to neglect the whole compatibility thing and go for a fresh new specification as well because some inheritances in the specification were also restricting further work on the standard.

BlogML 2.1

So BlogML 2.1 is just a minor revision with a very small fix to a very big bug, and I have to confess that it was my fault that I hadn’t tested this to catch it before the release.

This new version doesn’t change anything with the XSD schema and other stuff. It only updates the .NET library but you even don’t need to worry about compatibility or recompile your projects. All you need to do is replacing the previous .NET assembly with the new one to resolve the issue. All the existing converters and tools that work with BlogML 2.0 will work with BlogML 2.1 assembly.

But the issue is with embedded file attachments that are supposed to be stored in Base64 format, however, that bug was adding a sequence of constant A’s to the output.

You can download the new version from the CodePlex workspace that contains both the binaries and source codes.

The Future Perspective

This was a good reason to push me forward in accelerating the development of BlogML 3.0 codenamed Haacked, a new fresh version of this standard. I’m going to contact some members of the team such as Darren, Phil, and Simone to ask about their thoughts and comments to plan for the next version, but I strictly want to have a Beta out by the end of the year.

While there should be many stuff coming out from our conversations, I think that there are some big changes happening for sure: hopefully, we’ll move the project off the CodePlex, and will rewrite the specification and .NET API from the scratch. For the new .NET library we’ll use a very simple and straightforward API using the standard framework design guidelines, also will use a Test-Driven approach to make sure we’ll meet a minimum level of quality.

I’d also like to see a rich documentation written along with each and every phase of development added to the project even though I’m lazy to do this myself, and I hope we can get new team members to help with such stuff.

Speaking of new contributors to the project, it’s a very sad fact that the whole .NET Open Source community is limited to some specific contacts and specific project types. You may not agree with me on this, but for a long time I’ve been having negative impressions on what is called an open source community around the .NET. Many of these projects are ported from the Java and a reasonable number of prominent projects are focusing on specific areas such as blog engines, forums, photo galleries, O/R mappers, etc. The fact that there wasn’t even a single developer to take the responsibility of BlogML during our long absence was very disappointing as BlogML has a relatively simpler structure than other open source projects while it has a great potential to become a de facto in blog standards.

All in all, I hope that we can reactivate the project and proceed with a better quality, and also get new active members on board to assist us in development and documentation.

Looking in the past is usually nostalgic for many people including myself specifically in the past few years after passing 20 as I ought to waste much time for things beyond my power like the military service.

One of the advantages of having an old blog like this is the opportunity to go back and read your own archive to see what has happened in your life, and how you’re changed! Yes, it’s now the fifth time that I am writing about my birthday on this blog. It means that I’ve been blogging here non-stop for the long and important era of 20-25 when many things happened in my life. I began blogging when I was 20 and today I become 25 to hit one of the important points of life! By the way, it may be interesting to go back and read my posts for 21st, 22nd, 23rd, and 24th birthdays!

A few months ago I read an article about aging and feelings that come to a person from a psychological point of view. In that article the author had mentioned that there are some milestones in our lives in which we go back and review what we’ve done. Such milestones are 10, 18, 30, 40, 50, and 60.

We all have some goals and plans for ourselves and less or more try to achieve them. For each milestone we have different types of demands. For instance, at 30 we may be looking for education, job, and relationships, but at 40 we may be looking for family, kids, and their future; however, at 50 or 60 we may be looking for the same stuff that we had in our 20’s or 30’s, but for our children. The author has mentioned that each of these eras are like an stage of a game and if our achievements can’t satisfy us, then it’s like a Game Over because neither we can go back and change them, nor our age and new demands allow us to continue trying for the same goals. Therefore, if we don’t get them by that point, we’re failed and this brings sadness and a bad feeling.

Although 25 is not such a major milestone, it’s an important point when you leave the first half of the youth with some characteristics and become mature in some aspects. There are some teenager-like behaviors that you start to leave and some higher demands you start to have. You also learn to put closer goals to reality that are achievable for you in regards to your qualities and time.

I always hope that I don’t have the bad feeling of failure at abovementioned points especially at 30 that in my opinion seems to be the most important and sensitive milestone. To now, I’ve been satisfied with what I’ve done specifically when I consider my geographical location, the environment, and all the limitations imposed by the surrounding world, and contrasting it with the fact that my achievements were also very high that mark me as one of the special members of this society. I’m already at a point where many others like to be at, but just speak about it. Of course, no one is perfect and there were some parts that I could act better.

The most notable difference between my situation in the past 25 years and my current situation is that in the past, I mostly used to be stuck with classic stuff, the stuff like education or conscript that were coming to me one after one like they come to others, but this time I’m on my own to decide and feel some kind of freedom for myself.

Fortunately not only I earned good knowledge, expertise, and skills from the past, but also could get much experience from all the difficulties that I faced with, and I’m happy to say that I have more experiences than the average of the youth at my age, at least in Iran. This softens my path in the future and helps me make better decisions and achieve my goals.

Speaking of the difficulties that later helped me earn much experience, the conscript was one of them. Most likely you can remember that how difficult it was for me to pass my days during the service, but now it turns out to be an influential part of my life that indirectly helped me learn many things. Last year I celebrated by 24th birthday when I was very close to the end of the service, but now I’ve been able to adapt myself with the new life, and see things from a better perspective. When I compare myself with other people at my age, and see the huge differences between us, and the fact that I’m far ahead of most of them, I believe that after all, it was a positive yet an arduous part of my life specifically as it trained me in a relatively long time to work hard and resist.

But some good stuff happened in the past year in my life that I can share here. I completed the military service after 20 months, and since then have been recovering myself. It can be seen from my photos and the smile that is being expanded on my face! Besides, I could publish my fourth book that I co-authored with Simone for Wiley/Wrox and seems to be one of the best titles in this field. As I stated before, there is a high chance that I stop writing books for a few years and concentrate on other stuff. I used to be one of the youngest (even the youngest) author for this publisher as I wrote my first book at 22. I also had some resolutions for 2009 and luckily have had good progress with them. I could have more fun, gain a much better fitness by losing 22 pounds in less than two months and exercising, and fortunately, leaving some fancy noise on the web.

There isn’t much to say for this year except the fact that as always, some unfortunate events and issues outside my realm didn’t allow me to achieve everything that I had planned to achieve, but I hope I can overcome them in the future.

In the past couple of months I’ve been writing a blog post series about Visual Studio add-in and integration package to compare their structure, applications, and differences, and some related stuff. So far I’ve written five parts:

• An overview and historical perspective
• Technical structure of an add-in and its applications
• Technical structure of a Visual Studio integration package its applications
• Differences between add-ins and VSPackages
• How to choose between add-ins and VSPackages

In this sixth and last part I want to give a short overview of general steps to upgrade an add-in to an integration package and wrap the discussion up.

How to Upgrade an Add-In to an Integration Package

You’re not always going to build an extension from the scratch. You may have some older add-ins in hand that you’d like to upgrade to VSPackages in order to have a better integration and provide better features.

Generally, there isn’t a documented constant progress to upgrade an add-in to an integration package. You might expect to see a classic wizard like Visual Studio solution upgrade wizard or a multi-step process that can simply guide you to upgrade an add-in to a VSPackage, but there aren’t such options available. This upgrade process varies based on your existing add-in and its features as well as the VSPackage that you want to build and its features.

However, with a simple example and some theoretical discussions I just want to give you an idea on how to perform this upgrade task easier. There are some general guidelines that you need to consider when performing the upgrade.

Add-ins are associated with one or more commands in the IDE and in a similar mechanism VSPackages register some commands, too. For a VSPackage, each element is associated with one or more commands. When upgrading an add-in to a VSPackage, you need to move your logic to the appropriate events. This depends on your project. For instance, you may have an add-in that displays something as a Tool window. In this case you need to move the code logic to the command associated with the Tool window in your VSPackage. This is a common step in your upgrade process but in details it varies based on your project.

There are some visual user interface elements in the IDE that you may use for your add-ins. In this case, you need to find the appropriate element in the VSPackage and then move your Windows Forms and user controls to the VSPackage and apply them in the element.

Of course, VSPackages provide much more functionality, features, and elements than add-ins so you always are moving from a smaller space to a larger one and will not require all features of the VSPackages to get it to work.

In the below example I suppose that there is an add-in with some basic features that I’d like to upgrade to a VSPackage. This add-in simply shows a text message in the MessageBox when user triggers the command for the add-in. This may be via a manual call of the command or clicking on the Tools menu option. The main part of the source code of this add-in is presented below.

public void Exec(string commandName, vsCommandExecOption executeOption, ref object varIn, ref object varOut, ref bool handled)
{
    handled = false;
    if (executeOption == vsCommandExecOption.vsCommandExecOptionDoDefault)
    {
        if (commandName == "SampleAddin.Connect.SampleAddin")
        {
            ShowMessage(); 

            handled = true;
            return;
        }
    }
} 

private void ShowMessage()
{
    MessageBox.Show("Visual Studio Extensibility");
}

Now suppose that I want to upgrade this add-in to a VSPackage. All I need to do is simply moving my code logic to VSPackage and bind it to the appropriate command. Of course, this is the most common scenario because many of the add-ins are built on topic of the commands.

When you’re creating a new VSPackage, Visual Studio opens a wizard and asks you to enter information for some commands that are associated with your command window or Tools menu option. You can use these commands to upgrade your add-in to an integration package.

Here I just add my logic to the MenuItemCallback method of the package. This method is called whenever you run the command for the menu item of your VSPackage whether manually or by clicking on the menu item. So in in the code below the MenuItemCallback simply implements the same logic for the VSPackage.

private void MenuItemCallback(object sender, EventArgs e) 
{ 
    IVsUIShell uiShell = (IVsUIShell)GetService(typeof(SVsUIShell)); 
    Guid clsid = Guid.Empty; 
    int result; 

    MessageBox.Show("Visual Studio Extensibility"); 
}

Summary

This post series walked through something that heavily relies on developer’s experience and knowledge, and just tried to give some theoretical points and guidelines to help you understand the key characteristics, similarities, and differences between add-ins and VSPackages as well as when to use each, and how to upgrade an existing add-in to a VS integration package.

Although I gave some guidelines, your experience is a very important parameter to achieve everything covered in this series and it was just an attempt to give a better understanding of concepts and put you on the right way.

One common feature of any modern web application to improve its SEO and traffic is the use of sitemap as a standard XML derivation. I’ve been using such sitemaps on my blog for a very long time. I can remember the days when sitemap was an extension to Community Server written by the community, and the days when it became a built-in feature. I also had written a plug-in for Graffiti CMS to add sitemap to my blog.

However, for Behistun (my new ASP.NET MVC powered blog engine) I had to implement the sitemap with my own code. In ASP.NET WebForms the most common way to implement a sitemap is through an HttpHandler that handles the request to sitemap URL and generates the valid XML data of the sitemap in response.

For ASP.NET MVC and Behistun I used a different approach that replaces HttpModule and HttpHandler in many cases: Action Result. I implemented a custom action result that generates the sitemap as the output.

Looking around, I didn’t see such an implementation shared on the community even though it’s comparatively easy to implement it in ASP.NET MVC. So here I share my approach shortly hoping it helps some developers in the future.

Action result is a very nice and helpful part of ASP.NET MVC that can act as a extensibility point as well. There are various derivations of ActionResult base class available in ASP.NET MVC, and there are some interesting extensions such as the one written for RSS feed generation.

For my sitemap implementation in ASP.NET MVC I created my own SitemapActionResult class by inheriting from ActionResult base class, and used it to generate the sitemap based on the blog posts list.

First, assume that I have a Post class that represents a post with a very simple structure that I’ll use later in my example.

using System;

namespace SitemapActionResultSample.Models
{
    public class Post
    {
        public int ID { get; set; }

        public string Title { get; set; }

        public string Body { get; set; }

        public DateTime DateAdded { get; set; }

        public DateTime UpdatedOn { get; set; }

        public string Slug { get; set; }
    }
}

Now I implement the custom action result for sitemap generation as follows.

using System;
using System.Collections.Generic;
using System.Web.Mvc;
using System.Xml;
using SitemapActionResultSample.Models;

namespace SitemapActionResultSample.Components
{
    public class SitemapActionResult : ActionResult
    {
        private List<Post> _posts;

        public SitemapActionResult(List<Post> posts)
        {
            this._posts = posts;
        }

        public override void ExecuteResult(ControllerContext context)
        {
            context.HttpContext.Response.ContentType = "application/rss+xml";

            using (XmlWriter writer = XmlWriter.Create(context.HttpContext.Response.Output))
            {
                writer.WriteStartElement("urlset", "http://www.sitemaps.org/schemas/sitemap/0.9");

                writer.WriteStartElement("url");
                writer.WriteElementString("loc", "http://site.com");

                writer.WriteElementString("lastmod", DateTime.Now.ToString("yyyy-MM-dd"));

                writer.WriteElementString("changefreq", "daily");
                writer.WriteElementString("priority", "1.0");
                writer.WriteEndElement();

                foreach (Post post in this._posts)
                {
                    writer.WriteStartElement("url");
                    writer.WriteElementString("loc", string.Format("http://site.com/{0}", post.Slug));

                    writer.WriteElementString("lastmod", post.UpdatedOn.ToString("yyyy-MM-dd"));

                    writer.WriteElementString("changefreq", "daily");
                    writer.WriteElementString("priority", "0.5");
                    writer.WriteEndElement();
                }

                writer.WriteEndElement();

                writer.Flush();
                writer.Close();
            }
        }
    }
}

The code is straightforward. The SitemapActionResult gets a list of posts via its public constructor and applies some XML operations to iterate through the list of posts and generate the appropriate and valid XML output in the response.

To test this in action, I create a controller with a single action method to generate a few fake posts and pass them to the SitemapActionResult and generate the sitemap.

using System;
using System.Collections.Generic;
using System.Web.Mvc;
using SitemapActionResultSample.Components;
using SitemapActionResultSample.Models;

namespace SitemapActionResultSample.Controllers
{
    public class SitemapController : Controller
    {
        public SitemapActionResult Index()
        {
            List<Post> posts = new List<Post>();
            posts.Add(new Post()
            {
                ID = 1,
                Title = "First Post",
                Body = "Body for the first post.",
                Slug = "first-post",
                DateAdded = DateTime.Parse("October 4, 2009 7:02 AM"),
                UpdatedOn = DateTime.Parse("October 4, 2009 7:02 AM")
            });
            posts.Add(new Post()
            {
                ID = 2,
                Title = "Second Post",
                Body = "Body for the second post.",
                Slug = "second-post",
                DateAdded = DateTime.Parse("October 5, 2009 1:48 PM"),
                UpdatedOn = DateTime.Parse("October 6, 2009 6:36 AM")
            });
            posts.Add(new Post()
            {
                ID = 3,
                Title = "Third Post",
                Body = "Body for the third post.",
                Slug = "third-post",
                DateAdded = DateTime.Parse("October 6, 2009 11:20 AM"),
                UpdatedOn = DateTime.Parse("October 6, 2009 11:20 AM")
            });

            return new SitemapActionResult(posts);
        }
    }
}

And I add a route to my routes collection to map incoming requests to the sitemap URL to this controller.

using System.Web.Mvc;
using System.Web.Routing;

namespace SitemapActionResultSample
{
    public class MvcApplication : System.Web.HttpApplication
    {
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                "Sitemap",
                "sitemap",
                new { controller = "Sitemap", action = "Index" }
                );

            routes.MapRoute(
                "Default",                                              // Route name
                "{controller}/{action}/{id}",                           // URL with parameters
                new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
            );
        }

        protected void Application_Start()
        {
            RegisterRoutes(RouteTable.Routes);
        }
    }
}

This generates something like the below output.

The sample code for this post is available for download here.

Recently I started a new blog post series on Visual Studio Extensibility and two major options available in this technology known as add-in and Visual Studio integration package. So far I’ve written four parts covering the following topics:

• An overview and historical perspective
• Technical structure of an add-in and its applications
• Technical structure of a Visual Studio integration package its applications
• Differences between add-ins and VSPackages

Here in the fifth part I want to discuss one of the ultimate goals of my post series about choosing between add-in and integration package based on requirements.

When to Use an Add-in and When to Use a VSPackage?

One of the main things that I want to help you learn is choosing between add-ins and VSPackages when appropriate.

This, of course, requires you to have experience and knowledge. These are two extensibility points that help you a lot. More experience with add-ins and VSPackages and seeing more implementations and their applications as well as having a deeper knowledge in these two extensibility options can help you choose between them.

But there are some theoretical points that I can share with you to give you a good understanding and start point.

I first outline four questions that you can ask yourself before choosing between these options:

• Which features do I need to implement for the project?
• What are the APIs that I need to implement this project?
• How much of effort can I put into this project?
• What’s my expectation of the depth of integration for this project?

Good and clear answers to these questions can help you so much. Let’s dive deeper into these questions.

Which features do I need to implement for the project?

There are obviously some features that you want to include in your project. These features lead you to some requirements such the necessity of some APIs that will be covered in the next sections.

But first you need to have a complete list of features to include in your project. Sometimes you may require some features that can be implemented as a VSPackage only, and sometimes you may have features that can be implemented with add-ins and VSPackages both.

What are the APIs that I need to implement for this project?

Based on the first question, you can decide on which APIs do you need to implement for the project?

Some features can be implemented both with add-ins and VSPackages while some features can be implemented only with VSPackages. For instance, having the capability of copying the source code of a file from the IDE to clipboard with code highlighting can be achieved with add-ins and VSPackages (of course, add-ins are the best option in this case) because all you need is accessing to DTE APIs that are available in add-ins and VSPackages.

But in the opposite direction you may need to implement a custom designer for yourself like a designer to build user interfaces with SVG (Scalable Vector Graphic). In this case, add-ins can’t help you and you can only work with VSPackages.

Here there would be a question in your mind: what are the API limitations of add-ins and VSPackages? The answer is wider than something that can be covered in documents and relies on experience and knowledge. But in general, add-ins are heavily relied on some APIs that may not allow you to do much things in some circumstances. Of course, VSPackages have limitations, too, but limitations of VSPackages are really ignorable and we can say that there is almost no limitation for VSPackage. If there is any limitation for VSPackages then somehow you can ignore your project because there wouldn’t be any other way to achieve it. However, there is an online list of features available in Visual Studio integrated package that you can read to decide.

At this point you may find your answer because if you can’t implement your project as an add-in then you have no choice but VSPackage whether you can put this effort and time for the project or not!

How much of effort can I put into this project?

If you’re here then it means that you’re able to implement your project both as an add-in and as a VSPackage so decision has become a little harder. This rarely happens because 80% of times there is a clear difference based on your requirements that give you the answer in first two steps, but here you can ask yourself about the effort that you can put into the project.

VSPackages are harder to design, develop, deploy and maintain and you have to keep this in mind.

An add-in implementation costs less and takes less effort while a VSPackage implementation costs more and takes more effort. You have some limitations here so can prefer add-ins.

What’s my expectation of the depth of integration for this project?

And the last question: the level of integration! You may have passed all above questions to reach here. Here you can decide based on your expectation of the depth of integration. If you want a completely integrated extension, then Visual Studio integration package is much better than add-in.

If you thought that our story with DZone and ASP.NET MVC was limited to the recently published Refcard, you were wrong, because there were more stuff to come out about us.

Yesterday, Alvin wrote a review of our book on DZone and highlighted the major topics of the book, and today he published an interview with Simone and me about ASP.NET MVC and the book to complement our trilogy on DZone about ASP.NET MVC.

In the book review Alvin has walked through the major topics discussed in our book and has highlighted the main concepts that you can learn from each part of the book. Luckily, Alvin is among the initial group of readers who have sent us their very positive feedback on the book.

In the interview that he had with Simone and me we discussed the ASP.NET MVC and our book. In this interview we answered to some questions about our own web development background, the current and future status of the ASP.NET MVC, and its usage in contrast to ASP.NET WebForms as well as some stuff about the book, our motivations to write it, and its target audience.

Here I have to thank Alvin for all these works and for his continuous activities on .NET Zone on DZone community that has enhanced this topic on the website significantly.

Speaking of initial feedback about our book, it’s worth saying that we have received excellent comments from our readers in less than a month after the publish date. Two major highlights are the great reviews done by Maarten Balliauw (on his blog) and Justin Etheredge (on Amazon) that both praise the quality of the content. I thank Maarten and Justin for these reviews, too.

As I had written before, Simone and I had planned to write a Refcard about ASP.NET MVC 1.0 for DZone to be published after our book and promote it. Therefore, we were in touch with Alvin Ashcraft and other DZone editors to get this Refcard done.

This Refcard, entitled Getting Started with ASP.NET MVC 1.0, is now published on DZone website and you can download the PDF copy for free.

Previously I had written about DZone Refcardz and the goals that they have to deliver a compact introduction to a software technology to readers. The emphasis is on key concepts, principles, and use of diagrams and tables to express the concepts.

Our Refcard about ASP.NET MVC 1.0 follows the same approach to give a quick overview to ASP.NET MVC 1.0.

After giving an introduction, this Refcard talks about the prerequisites of learning ASP.NET MVC and the installation process for ASP.NET MVC, then reviews the MVC pattern. After that, it follows with building a simple application and connects it to some fundamental concepts of ASP.NET MVC such as routing, model, controller, action method, model binder, view, and HTML helper. The last parts of the Refcard discuss T4 templates as a tool to generate text templates for ASP.NET MVC applications and the implementation of AJAX scenarios in ASP.NET MVC 1.0.

It’s tried to cover all the key concepts in ASP.NET MVC 1.0 in this short guide, and I think that it delivers all these topics very well.

Here I have to admit that almost all the work for this Refcard is done by Simone, and unfortunately I faced with some unexpected difficulties in personal life that didn’t let me keep my end, however, Simone was kind enough to include me in the final work, so I have to thank him here. This Refcard would be the last work that I’ve done with him for a while. We’ve worked on some open source projects as well as the book and this Refcard in the past few years and all these works were great experiences for me, and I hope that I can work with him in the feature on other projects. Also I’d like to use this opportunity to congratulate his upcoming birthday.

In the first three parts of my post series about two major extensibility options in Visual Studio, add-in and integration package, I gave an introduction, discussed the technical structure of an add-in with its applications, and talked about the integrated package and its applications as well.

In this fourth part I’m going to cover the differences between an add-in and an integration package, and highlight these points that are a vital part of making your decision to choose one of them to implement your extensions.

Differences Between Add-ins and VSPackages

From this point, we can move to the main topic of this series about the differences between add-ins and VSPackages.

Previous parts gave you some basic information about add-ins and VSPackages. Many of the differences between add-ins and VSPackages can be discovered from these definitions and information.

API Access

The first and obvious difference between add-ins and VSPackages is in the way that add-ins use higher level APIs while VSPackages use lower level APIs. This is a very important difference.

Add-in has access to the APIs that are designed specifically for the extensibility and the automation system (Development Tools Extensibility) so development of add-in is easier and faster than VSPackages. In turn these APIs are apparently limited in scope and do not provide all the functionality that you may need for some cases. Of course, there will be lots of the common scenarios considered to build these APIs but you’re not always dealing with common stuff.

VSPackages, on the other hand, have access to lower level APIs that are just the fundamental of Visual Studio, so they’re not limited in scope and you can freely work with them in order to build enterprise integrated features and extensions. Unlike add-ins, VSPackage development takes more effort because Visual Studio APIs are a little harder in comparison with the DTE APIs that add-ins use. The nice point to mention is that add-ins actually use VSPackage APIs themselves to simplify a common part of package API features.

Development Languages

There is also a difference in the development languages that you can use to build add-ins and VSPackages. Visual Studio has a built-in support to build add-ins with Visual C#, Visual Basic, Visual C++ / CLR and Visual C++ / ATL. To build VSPackages, you need to install Visual Studio SDK in order to enable project templates that work with Visual C++ or C#. Of course it’s possible to use other development languages but it needs a hard process of writing all code templates by hand and referencing appropriate APIs.

As you see, you can achieve add-in development faster, easier and with more options.

Level of Integration

One of the biggest differences between an add-in and a VSPackages is the level of integration that you can achieve with them.

Generally, you can have a much better integration with integration packages in comparison with add-ins. Whatever you do, add-ins are an external thing for Visual Studio while VSPackages are a completely integrated part of the IDE.

Of course, this integration level depends on several parameters and one of them is the effort that a developer puts into his or her work. For instance, a developer may put a good effort to write an excellent add-in that has a better integration than a VSPackage that is not written very well. So here development skills and effort are two important points as well.

Development Process

One of the other differences that both software vendors and developers would care about is the development process and cost of development for each option regarding all the other differences and features that they provide.

Sometimes you may not be sure between add-ins and VSPackages and knowing the development process/cost can help you decide to go with a faster and easier option.

Generally, the development process for add-in is easier than VSPackage for some common and very well-known reasons that we outline:

• Add-ins are optimized for common scenarios during the time while VSPackages are comparatively newer and don’t have such goals. So with add-ins you can achieve some common goals faster and easier.
• For VSPackage development you need to know more concepts and have a deeper knowledge in Visual Studio Extensibility while for add-ins you don’t need such an in-depth knowledge.
• The time of development process for add-ins is less than VSPackages, hence its cost. This is due to the abovementioned nature of add-ins that are easier to develop.
• Debugging, testing, and deployment of add-ins is easier than VSPackages as well.

Of course, again this is a general comparison for same levels of skills and experiences. Someone with better skills would be able to do things in less time than someone who lacks these skills.

It was quite a long while that I had decided to migrate my blog from Graffiti CMS to a new engine, and today I finally completed this task.

There is a long story to tell about this process and my reasons to choose my own blog engine after over 4 years of using Telligent products (Community Server and Graffiti CMS), and I try to talk about them shortly in this post.

Why Migrate?

Old followers of my blog know that I’ve been using Telligent products since the beginning of this blog for a very long time. First I was using Community Server as a single-blog and then migrated to Graffiti CMS as a more appropriate option for my blogging style. I used to be an active community contributor to Telligent products, ran popular open source projects for both products, and praised both these products as they really deserved it at the time of being. I used to be a Community Server MVP and a prominent name in Graffiti CMS development, and could find great friends inside Telligent and via this company and its products. Many of my old readers had come here from my initial activities on this community and suddenly we became great friends.

However, as all of you already know, this economic crisis had a huge impact on the way that Telligent leadership were managing the company, and after many layoffs during the last year, they restricted the activity around their products. The main product that was negatively affected by this movement was Graffiti CMS. There has been a long time that Telligent hasn’t contributed any update to this product and this has been the source of many complaints by customers and community members recently.

Here I’d mention that Graffiti was a great product as was, and it’s still a thorough product for its own whether as a CMS or a blog engine. However, I don’t want to deviate from the main point of this post by talking about Telligent and its products, and why many of the community members including myself believe that Telligent had to drop new builds in the past months.

But the reason that convinced me to move off Graffiti and write my own engine was the fact that most likely I won’t have time to spend on maintaining the technical side of this blog in the next few years, and I thought that it’s better to have something simple and easy to maintain that I have full control on. Graffiti was written for ASP.NET 2.0 and IIS 6.0 and there was no source code available, so it could cause difficulties in the future to manage this product.

Destination Options

It’s a matter of a fact that after more than 4 years of blogging, I’ve realized that the type of a blog engine and the technology behind it are not a big deal whether you’re a technical developer or not. All an author wants is a tool to go, and almost all the current blogging engines are satisfactory in this matter specifically for me as a blogger who has stopped categorizing and tagging his posts. I really need a plain blog engine that works for me.

I had many destination options to use. I was very interested to use an engine powered by ASP.NET MVC, but neither Oxite nor AtomSite were what I wanted. Both these options add an extra complexity that doesn’t have any value for my needs.

There were also some great engines written by ASP.NET WebForms such as Subtext or BlogEngine.NET but less or more, they couldn’t satisfy my requirements, too.

Looking around, I was seriously going to migrate to a PHP option like MoveableType or WordPress, and even used Jon Sagara’s tool to export my posts, but somewhere in the middle of the process I disliked the quality of my imported posts in the destination engine. It was breaking all my URLs and couldn’t carry all the data that I had.

Why Write My Own Engine?

Having this in mind, I thought about writing my own blog engine. To be honest, I dislike writing blog engines as I think that world is saturated by various engines available out there. I’ve contributed to many open source projects but never wrote a blog engine myself because I don’t believe in its necessity. When there are many engines available, why should we start a new project, drop one or two releases, and then stop the project after a while to make difficulties for our users?

However, I was locked in the middle point of a process where I couldn’t satisfy my needs with any of the existing blog engines. My blog is old and there were over 1000 posts (mostly lengthy with source code samples) written by me with many feedback. It wasn’t easy to find something suitable for this amount of data and type of content. I was looking for a simple blog engine that can import my posts and maintain the huge number of incoming links to my blog that have become a reference for the community over the years.

Furthermore, it was a while that I wanted to use ASP.NET MVC to power my blog engine, and I had promised some of our book readers to build a blog engine similar to WroxBlog that I’ve written for Chapter 18 of the book that lets them learn about the backend part of the blog.

Therefore, I decided to write a simple blog engine for my own that meets my goals and doesn’t make things complex

What is Behistun?

After spending much time on finding an alternative, I started writing my simple blog engine and called it Behistun. Behistun is the name of an ancient UNESCO World Heritage Site near Kermanshah, Kurdistan (Iran) where I was born.

I wrote Behistun in 7-8 hours then spent 4 days to end up with this simple theme and wasted 7-8 days to move the images and other files of my old blog to a single location to make them consistent!

As you see, Behistun is pretty simple. It’s written with ASP.NET MVC 1.0 (C#) and applies SQL Server as its storage. I used LINQ to SQL to interact with the data storage that consists of four tables only. I also used WCF for some parts such as RSS feed generation and XML-RPC service hosting.

Behistun is as simple as following features that are all built for single-blog functionality.

• Post management
• Comment management
• Trackback and Pingback (the latter one is not enabled yet)
• Monthly archive
• MetaWeblogAPI
• Sitemap
• FeedBurner support

The first and foremost advantage of Behistun is its simplicity, but it’s also a cool engine as it’s built by ASP.NET MVC, generates neat URLs, and loads pretty fast!

In order to build Behistun I used some third party tools and components that I list here:

• Ninject
• RhinoMocks
• CKEditor
• Ryan Lanciaux’ HtmlHelper for Gravatar
• Eran Kampf’s RSS Feed Action Result.

There is only one minor issue to inject my XML-RPC services built with WCF that I’m working with Ninject team members to resolve.

The theme for this blog is a simple one as the engine is. I inspired some ideas in coloring and fonts from Posterous design.

Major Changes

During the migration process I applied some major changes in my blog:

• Now I’m using Google Custom Search as the search engine for my blog. The search engine for Graffiti was pretty slow for this number of posts, and I saw no point in reinventing the best wheel that is ever built for the search on the web!
• There is no excerpt for posts anymore. You see the full content of the posts in the homepage.
• There is no About or Contact page anymore. You see a short biography along with a few links in my sidebar that you can use to contact me (don’t forget that I’m not that type of guy who accepts any friends request on social networking sites).
• After a long while, I restored my monthly archive with tons of blog posts that shows the power and age of this blog!
• Once again I migrated my feed to FeedBurner! This time just to make you happy and let you laugh a lot!

Having these changes in look and feel and functionality, I’m also going to apply major changes in my blogging style in a smooth manner. You’ll be witnessing a transition from my current focus on Software Development and .NET-related stuff to other topics that I like them more than these.

New License

The very important change is that I changed the license of my blog to a copyleft GNU Free Documentation License. I’m a big advocate of openness in software (don’t look at my Microsofti face!), so I thought it’s worthwhile to open all the doors for anyone to use this resource of content about .NET and Software Development and spread the word. There are some content stealers that steal my posts every time I publish them, and there is nothing I can do. At least, I can help them do a legal job!

Behistun as a Public Project?

The short answer is no, not at the moment! As I said above, I don’t like to add something to this mess of blogging engines and stop supporting it after a while.

However, the good news is that at the moment I’m using an Alpha version of Behistun and once I complete working on the first version as a stable engine, I’ll publish it as a disclaimer project with a very open license, so anyone can adapt the code and use it with no support on my side.

Having this said, if I can find 1-2 contributors who are really interested to get Behistun and make it a public open source project, I’m ready to cooperate with them.

Recently I started a new blog post series on Visual Studio Extensibility and two major options available in this technology known as add-in and Visual Studio integration package. So far I’ve written four parts covering the following topics:

• An overview and historical perspective
• Technical structure of an add-in and its applications
• Technical structure of a Visual Studio integration package its applications
• Differences between add-ins and VSPackages

Here in the fifth part I want to discuss one of the ultimate goals of my post series about choosing between add-in and integration package based on requirements.

When to Use an Add-in and When to Use a VSPackage?

One of the main things that I want to help you learn is choosing between add-ins and VSPackages when appropriate.

This, of course, requires you to have experience and knowledge. These are two extensibility points that help you a lot. More experience with add-ins and VSPackages and seeing more implementations and their applications as well as having a deeper knowledge in these two extensibility options can help you choose between them.

But there are some theoretical points that I can share with you to give you a good understanding and start point.

I first outline four questions that you can ask yourself before choosing between these options:

• Which features do I need to implement for the project?
• What are the APIs that I need to implement this project?
• How much of effort can I put into this project?
• What’s my expectation of the depth of integration for this project?

Good and clear answers to these questions can help you so much. Let’s dive deeper into these questions.

Which features do I need to implement for the project?

There are obviously some features that you want to include in your project. These features lead you to some requirements such the necessity of some APIs that will be covered in the next sections.

But first you need to have a complete list of features to include in your project. Sometimes you may require some features that can be implemented as a VSPackage only, and sometimes you may have features that can be implemented with add-ins and VSPackages both.

What are the APIs that I need to implement for this project?

Based on the first question, you can decide on which APIs do you need to implement for the project?

Some features can be implemented both with add-ins and VSPackages while some features can be implemented only with VSPackages. For instance, having the capability of copying the source code of a file from the IDE to clipboard with code highlighting can be achieved with add-ins and VSPackages (of course, add-ins are the best option in this case) because all you need is accessing to DTE APIs that are available in add-ins and VSPackages.

But in the opposite direction you may need to implement a custom designer for yourself like a designer to build user interfaces with SVG (Scalable Vector Graphic). In this case, add-ins can’t help you and you can only work with VSPackages.

Here there would be a question in your mind: what are the API limitations of add-ins and VSPackages? The answer is wider than something that can be covered in documents and relies on experience and knowledge. But in general, add-ins are heavily relied on some APIs that may not allow you to do much things in some circumstances. Of course, VSPackages have limitations, too, but limitations of VSPackages are really ignorable and we can say that there is almost no limitation for VSPackage. If there is any limitation for VSPackages then somehow you can ignore your project because there wouldn’t be any other way to achieve it. However, there is an online list of features available in Visual Studio integrated package that you can read to decide.

At this point you may find your answer because if you can’t implement your project as an add-in then you have no choice but VSPackage whether you can put this effort and time for the project or not!

How much of effort can I put into this project?

If you’re here then it means that you’re able to implement your project both as an add-in and as a VSPackage so decision has become a little harder. This rarely happens because 80% of times there is a clear difference based on your requirements that give you the answer in first two steps, but here you can ask yourself about the effort that you can put into the project.

VSPackages are harder to design, develop, deploy and maintain and you have to keep this in mind.

An add-in implementation costs less and takes less effort while a VSPackage implementation costs more and takes more effort. You have some limitations here so can prefer add-ins.

What’s my expectation of the depth of integration for this project?

And the last question: the level of integration! You may have passed all above questions to reach here. Here you can decide based on your expectation of the depth of integration. If you want a completely integrated extension, then Visual Studio integration package is much better than add-in.

If you thought that our story with DZone and ASP.NET MVC was limited to the recently published Refcard, you were wrong, because there were more stuff to come out about us.

Yesterday, Alvin wrote a review of our book on DZone and highlighted the major topics of the book, and today he published an interview with Simone and me about ASP.NET MVC and the book to complement our trilogy on DZone about ASP.NET MVC.

In the book review Alvin has walked through the major topics discussed in our book and has highlighted the main concepts that you can learn from each part of the book. Luckily, Alvin is among the initial group of readers who have sent us their very positive feedback on the book.

In the interview that he had with Simone and me we discussed the ASP.NET MVC and our book. In this interview we answered to some questions about our own web development background, the current and future status of the ASP.NET MVC, and its usage in contrast to ASP.NET WebForms as well as some stuff about the book, our motivations to write it, and its target audience.

Here I have to thank Alvin for all these works and for his continuous activities on .NET Zone on DZone community that has enhanced this topic on the website significantly.

Speaking of initial feedback about our book, it’s worth saying that we have received excellent comments from our readers in less than a month after the publish date. Two major highlights are the great reviews done by Maarten Balliauw (on his blog) and Justin Etheredge (on Amazon) that both praise the quality of the content. I thank Maarten and Justin for these reviews, too.

As I had written before, Simone and I had planned to write a Refcard about ASP.NET MVC 1.0 for DZone to be published after our book and promote it. Therefore, we were in touch with Alvin Ashcraft and other DZone editors to get this Refcard done.

This Refcard, entitled Getting Started with ASP.NET MVC 1.0, is now published on DZone website and you can download the PDF copy for free.

Previously I had written about DZone Refcardz and the goals that they have to deliver a compact introduction to a software technology to readers. The emphasis is on key concepts, principles, and use of diagrams and tables to express the concepts.

Our Refcard about ASP.NET MVC 1.0 follows the same approach to give a quick overview to ASP.NET MVC 1.0.

After giving an introduction, this Refcard talks about the prerequisites of learning ASP.NET MVC and the installation process for ASP.NET MVC, then reviews the MVC pattern. After that, it follows with building a simple application and connects it to some fundamental concepts of ASP.NET MVC such as routing, model, controller, action method, model binder, view, and HTML helper. The last parts of the Refcard discuss T4 templates as a tool to generate text templates for ASP.NET MVC applications and the implementation of AJAX scenarios in ASP.NET MVC 1.0.

It’s tried to cover all the key concepts in ASP.NET MVC 1.0 in this short guide, and I think that it delivers all these topics very well.

Here I have to admit that almost all the work for this Refcard is done by Simone, and unfortunately I faced with some unexpected difficulties in personal life that didn’t let me keep my end, however, Simone was kind enough to include me in the final work, so I have to thank him here. This Refcard would be the last work that I’ve done with him for a while. We’ve worked on some open source projects as well as the book and this Refcard in the past few years and all these works were great experiences for me, and I hope that I can work with him in the feature on other projects. Also I’d like to use this opportunity to congratulate his upcoming birthday.

In the first three parts of my post series about two major extensibility options in Visual Studio, add-in and integration package, I gave an introduction, discussed the technical structure of an add-in with its applications, and talked about the integrated package and its applications as well.

In this fourth part I’m going to cover the differences between an add-in and an integration package, and highlight these points that are a vital part of making your decision to choose one of them to implement your extensions.

Differences Between Add-ins and VSPackages

From this point, we can move to the main topic of this series about the differences between add-ins and VSPackages.

Previous parts gave you some basic information about add-ins and VSPackages. Many of the differences between add-ins and VSPackages can be discovered from these definitions and information.

API Access

The first and obvious difference between add-ins and VSPackages is in the way that add-ins use higher level APIs while VSPackages use lower level APIs. This is a very important difference.

Add-in has access to the APIs that are designed specifically for the extensibility and the automation system (Development Tools Extensibility) so development of add-in is easier and faster than VSPackages. In turn these APIs are apparently limited in scope and do not provide all the functionality that you may need for some cases. Of course, there will be lots of the common scenarios considered to build these APIs but you’re not always dealing with common stuff.

VSPackages, on the other hand, have access to lower level APIs that are just the fundamental of Visual Studio, so they’re not limited in scope and you can freely work with them in order to build enterprise integrated features and extensions. Unlike add-ins, VSPackage development takes more effort because Visual Studio APIs are a little harder in comparison with the DTE APIs that add-ins use. The nice point to mention is that add-ins actually use VSPackage APIs themselves to simplify a common part of package API features.

Development Languages

There is also a difference in the development languages that you can use to build add-ins and VSPackages. Visual Studio has a built-in support to build add-ins with Visual C#, Visual Basic, Visual C++ / CLR and Visual C++ / ATL. To build VSPackages, you need to install Visual Studio SDK in order to enable project templates that work with Visual C++ or C#. Of course it’s possible to use other development languages but it needs a hard process of writing all code templates by hand and referencing appropriate APIs.

As you see, you can achieve add-in development faster, easier and with more options.

Level of Integration

One of the biggest differences between an add-in and a VSPackages is the level of integration that you can achieve with them.

Generally, you can have a much better integration with integration packages in comparison with add-ins. Whatever you do, add-ins are an external thing for Visual Studio while VSPackages are a completely integrated part of the IDE.

Of course, this integration level depends on several parameters and one of them is the effort that a developer puts into his or her work. For instance, a developer may put a good effort to write an excellent add-in that has a better integration than a VSPackage that is not written very well. So here development skills and effort are two important points as well.

Development Process

One of the other differences that both software vendors and developers would care about is the development process and cost of development for each option regarding all the other differences and features that they provide.

Sometimes you may not be sure between add-ins and VSPackages and knowing the development process/cost can help you decide to go with a faster and easier option.

Generally, the development process for add-in is easier than VSPackage for some common and very well-known reasons that we outline:

• Add-ins are optimized for common scenarios during the time while VSPackages are comparatively newer and don’t have such goals. So with add-ins you can achieve some common goals faster and easier.
• For VSPackage development you need to know more concepts and have a deeper knowledge in Visual Studio Extensibility while for add-ins you don’t need such an in-depth knowledge.
• The time of development process for add-ins is less than VSPackages, hence its cost. This is due to the abovementioned nature of add-ins that are easier to develop.
• Debugging, testing, and deployment of add-ins is easier than VSPackages as well.

Of course, again this is a general comparison for same levels of skills and experiences. Someone with better skills would be able to do things in less time than someone who lacks these skills.

In the first two parts of my new post series about Visual Studio add-in and integration package as two primary options to extend Visual Studio IDE I gave a quick overview of the past history of Visual Studio Extensibility with an emphasis on these two options, and talked about the technical structure of an add-in along with its applications.

Now in the third part I want to go over the technical structure of a Visual Studio integration package also known as VSPackage and talk about its applications to contrast it with add-in structure and applications.

What is a VSPackage?

The second extensibility option that is a part of our discussion is VSPackage.

First of all, let’s make it clear about the name. VSPackage stands for Visual Studio Package and some other guys call it VS SDK Package and it’s also known as Visual Studio Shell Integrated package in Visual Studio 2008 (after the birth of Visual Studio Shell technology). I usually refer to it as VSPackage which seems to be the well-known term.

A VSPackage, as its name suggests, is a component that integrates into Visual Studio environment like a built-in part of the IDE and here is the key point. It integrates with the IDE very well and can do things that add-ins can’t do and this is the primary advantage for it in comparison with add-ins.

VSPackage applies low level APIs of the IDE to accomplish things. These APIs are similar to those that development teams at Microsoft use to build many built-in parts of the IDE.

When you use a VSPackage, you’re actually using a built-in part of Visual Studio and when you develop a VSPackage, you’re developing something like what a Microsoft developer may develop inside the company.

A VSPackage consists of groups of some main elements including:

• User interface elements
• Projects
• Services
• Designers
• Editors

You can develop each of these elements for your VSPackage to integrate a new feature or some new features with existing Visual Studio features.

One of the good examples of a VSPackage is an implementation done by Microsoft as Team Explorer. Team Explorer, a client to work with Team Foundation Server source control, is a VSPackage that integrates some features with Visual Studio.

VSPackage, like add-in, is one of the first level Visual Studio extensibility options that is already known as the most professional way to extend this IDE with a deep integration.

Technical Structure of a VSPackage

Like add-ins, VSPackages are also some components that are compiled in a way to be accessed by Visual Studio COM components that implement interfaces. A VSPackage mainly implements IVsPackage interface but since VS 2005, Managed Package Framework (MPF) is introduced to make things easier and now you just need to derive from a base class named Package that automatically derives from several interfaces including IVsPackage.

Although this is the main part of the package implementation but there are lots of things besides it that make a VSPackage include commands, designers, editors, tool windows, and related stuff that are beyond the scope of this context.

When you want to develop a VSPackage, you need to implement various parts of this component mainly the part that derives from VSPackage. As you can guess, the development of a VSPakcage takes more effort and requires a deeper knowledge in Visual Studio Extensibility and COM programming.

Note that the most suitable language to use in order to develop a VSPackage is VC++. Although other .NET languages such as C# can be used, in some circumstances you face with limitations with these languages.

Two days ago I started a new post series to discuss Visual Studio add-in and integration package in order to introduce their structure, applications, differences, commonalities, and how to upgrade from an add-in to a VSPackage. My main goal is to cover some aspects of this discussion that have been an ambiguous part of Visual Studio Extensibility for a newbie.

In the first post of this series, I gave a quick overview of the past history of Visual Studio Extensibility, these two options, and how they evolved during the past decade or so. In this second part I want to review the technical structure of an add-in along with its applications.

What is an Add-in?

In fact, the term add-in refers to something general in Microsoft products including Visual Studio IDE and Office Suite and in Visual Studio it’s known as VSAdd-in. But it’s common among Visual Studio users and developers to simply call it “Add-in”.

But what’s the application of an add-in and why it’s designed as a part of Visual Studio extensibility?

Add-in is actually an extension to Visual Studio that lets developers apply high level APIs of the Visual Studio and Development Tools Extensibility (DTE) to extend Visual Studio in several ways but with some limitations that relate to the API that they can use.

Above paragraph states some important facts about add-ins:

• Add-in is an extensibility option.
• Add-in uses high level APIs. This is important when we talk about VSPackage that uses low level APIs.
• The main APIs to use with add-ins are those that are part of the Development Tools Extensibility (also known as DTE). You’ll read a short overview of the DTE later in this series.
• There are some limitations to build add-ins and use them. Add-ins use some high level APIs and this restricts them in some points. You’ll read more about these limitations later in this series.

Now that you read a quick definition of add-in and a short description about important aspects of an add-in, let’s dig into more details about add-ins.

Technical Structure of an Add-in

From a technical point of view add-in is a compiled package of code that can run by a mechanism in Visual Studio known as Visual Studio add-in system. This is in opposite direction to the definition of VSMacro that is not a compiled piece of code.

Add-in is a COM component. It means that add-in, like many other COM components, implements a programming interface for a component. In general Visual Studio Extensibility consists of lots of these interfaces and their corresponding implementations to enable interoperability between .NET and COM.

The development mechanism of add-ins is a built-in part of Visual Studio and there is a Visual Studio template for this purpose.

From a technical point of view add-in implements IDTExtensibility2 interface from EnvDTE80 namespace (this is of course what you see in Visual Studio 2005 and 2008 and names are different for prior versions). This interface contains five methods that can be implemented to handle events that let you implement your logic for these main events including OnConnection, OnDisconnection, OnAddInsUpdate, OnStartupComplete and OnBeginShutdown. The structure of an add-in is shown below.

Beside this, there is an XML file with a .vsaddin extension that acts like a configuration file for your add-in and you must configure it.

Before Visual Studio 2005, the deployment of add-ins was a little hard and required the registration of COM assemblies on the machine but thank to the introduction of this .vsaddin file, now you just deploy the assembly and this configuration file to a specific path.

You’re able to integrate an add-in into Visual Studio as a part of some user interface elements. You can add a Visual Studio command for your add-in to the IDE and then use this command to achieve many things.

For example, you can add your add-in to the user interface as a new menu item for default Visual Studio menus or right-click menu.

Since add-ins have access to the automation model API, they can do many things that I outline some of them here:

• Trigger your logic for various events
• Manipulate some default Visual Studio windows like Tasks List, Output or Error List
• Manipulate the text in documents regardless of being code or not
• Manipulate the code in code files using the code model
• Manipulate solutions, projects and project items
• Manipulate and customize the build process
• Work with source control and implement your own source controls or customize existing ones

These are some main tasks that add-ins can do but besides them, you’re able to design your own user interface for the add-in to show to the user in order to return outputs or get inputs. Moreover, you’re able to integrate a Tools Options Page in order to have dynamic configuration and settings for your add-ins.

There is a Visual Studio mechanism to load and run add-ins. This mechanism looks for add-in files in specific paths (that you can modify) and then loads all valid add-ins (that implement the interface and have a valid .vsaddin file). After loading these add-ins, it calls the specific method whenever that event type occurs. You saw that there are five main events that an add-in implements and can respond to them when Visual Studio calls such methods.

By implementing an extra interface called IDTCommandTarget and registering a command for your add-in, you’re also able to respond to the command whenever it’s called and this lets you do much more things than what you can do by default implementation of add-in. This also lets others to develop macros and add-ins that will apply your add-in.

In general, there are many goals that can be achieved with add-ins quickly and easily. The development and deployment process of add-ins has been made much easier in Visual Studio 2005 and 2008, and now it’s the fastest way to extend Visual Studio with high level APIs.

It’s been quite a long while since the last time that I wrote something about Visual Studio Extensibility as a topic that I used to write a dedicated book for. Therefore, to improve my blogging activity and feed those readers of my blog who are interested in VSX, here I’m going to publish a post series with a few posts that discuss add-in and integration package, contrast their similarities and differences, and talk about the process of upgrading an add-in to a VSPackage.

By the way, this is a good topic to elaborate because in many areas add-ins and VSPackages may overlap in their applications, and it may be difficult for a newbie to choose which of these two main extensibility options to use.

Overview

Visual Studio Extensibility consists of a set of different extensibility options available in Microsoft Visual Studio IDE to let developers extend this popular IDE for their requirements.

In this post series my main goal is to talk about two famous and common extensibility points included in the IDE: add-in and VSPackage.

Objectives

Let’s take a look at the objectives for this post series before digging into them:

• Discovering the concept of add-in and VSPackage and their applications
• Understanding the similarities and differences between these two extensibility options both in applications and in their access to VS API
• Learning when to use an add-in and when to use a VSPackage
• Learning how to upgrade an add-in to a VS SDK Package when necessary

An Overview of Visual Studio Extensibility, Add-In, and VSPackage

The first thing that I need to talk about is the role of add-in and VS SDK package in Visual Studio Extensibility and a short history of them. This can give a general understanding of the differences between these two options to you.

Visual Studio Extensibility (VSX) consists of a set of basic concepts, general API, and different options that form its foundation. Some of these options are very well-known for their role in VSX, and are actually a first-level extensibility option while others may be placed in the second and third level per their commonality in VSX.

Speaking of these three levels, we can split all Visual Studio Extensibility points into three levels based on their commonality in extensibility and their role.

The first level consists of some options that are specifically designed for extensibility like add-ins, macros, and VS SDK packages. The second level consists of some options that are designed for extensibility but are targeting other fields as well. Some examples are debugger visualizers or templates. And the third level of extensibility options contains some features of Visual Studio that are specifically designed for other purposes but can help the extensibility as a side-application.

But here our focus is on the first level and some very well-known extensibility points including add-ins and VS SDK packages. Both these options are primary extensibility options for Visual Studio. Add-ins have been with this IDE from the early days but VS SDK packages are introduced as a part of Visual Studio SDK in the newer versions.

As Visual Studio was built on top of COM technology, add-ins were introduced in the first version as an extensibility option and were implementing a COM interface. Actually add-in was the first extensibility option for Visual Studio that we know. Add-in has been improved in each new version of Visual Studio. Introduction of the .NET framework in 2002 had an important impact on add-in structure and changed the way that an add-in could be developed. So Visual Studio 2002 came with new structure for add-ins based on the .NET languages. While developers had to implement an interface (due to the COM nature of Visual Studio all the time), they could use cool new features introduced with the .NET framework. Microsoft made this possible via the interoperability between the .NET and its prior development technology, COM. Later with Visual Studio 2005 Microsoft improved add-in again and used XML to simplify its deployment process.

But the story of VS SDK package is a little different. The growing importance of Visual Studio in the past 10 years convinced Microsoft to start a new program called Visual Studio Industry Partner program (commonly known as VSIP program). This program targets bigger Microsoft partners that are working around Visual Studio and allows them to have access to many stuff related to Visual Studio.

As you’ll read later in this series, there were some limitations with add-ins in extending Visual Studio while many developers and partners wanted better ways to extend the IDE. The result was that Microsoft finally introduced a new extensibility feature called VS SDK package. VSPackages first introduced to VSIP members as a part of a private program and then became public to everyone.

These two options are nowadays the most common ways to build extensions for Visual Studio and many of the current extensions for the IDE are written as an add-in or VS SDK package, however, Visual Studio 2010 is supposed to change extensibility of Visual Studio significantly by introducing Visual Studio extensions as the new and great way to expand Visual Studio features.

A few days ago I received some extra author copies of our newly published book, Beginning ASP.NET MVC 1.0, at my address. I was thinking about meeting with some old friends in Tehran for a long time, and decided to use this opportunity to have a presentation and meeting to share some copies with my friends. By the way, those who have read the book know that I have dedicated this book to all Iranians around the world.

Today we had a meeting with a few friends including Hamed Banaei, Mahdi Taghizadeh, Soheil Rashidi, Behnam Yusefi, Milad Karbasizadeh, Mohammad Reza Mohammadali, Farid Arzpeyma, and Pedram Pourhossein where I had an introductory presentation on ASP.NET MVC 1.0.

The presentation was an introduction to ASP.NET MVC 1.0 and I tried to give an overview of the ASP.NET MVC 1.0 including a historical perspective, the MVC pattern, reasons to have ASP.NET MVC, main components of ASP.NET MVC, and best practices for ASP.NET MVC.

Finally I had a random draw to share a few copies of our book with old friends and we talked about future plans to hopefully gather Iranian developers and organize better groups for future community activities.

Mahdi has published some photos of this meeting and presentation where I had worn an anti-WebForms t-shirt designed and sent by Simone to me.

For your information some of these friends were among those who brought the knowledge of the .NET Framework to Iran, shared their expertise, and spread the word about the new technology as early as it was introduced by Microsoft. We were contributing to some local communities by writing articles and improving the common knowledge in this field. Unfortunately we missed each other for a long time and became busy with career and personal stuff, so couldn’t meet each other (except Hamed and I that meet regularly).

We’re looking to having more meetings after this and plan some nerd dinners, workshops, monthly talks, and hopefully technical conferences in the future, and welcome anyone who can help us in any way.

You can download the slides of my presentation from here.