In one of my older posts I announced out loud and shamelessly that I find it really difficult to code without intellisense. Besides Intellisense, I’ve always been for tools which increase developer productivity. A couple of months ago I played around with a Resharper 3.0 Trial to see what the interesting new features were. I have all good things to say about Resharper 3.0 but this post is not about any of those good things. It’s about one tiny little complaint I have towards Resharper Trial.

It killed my Visual Studio Intellisense.

After I had installed it and played around with it for around a week I lost intellisense from my Visual Studio – suddenly and completely. I could use the Intellisense Resharper offered me but Visual Studio Intellisense wouldn’t work while the trial was working. Soon the Resharper trial was over and the Resharper Intellisense died as well. Another colleague had a similar problem. She had tried out Resharper, and had lost her intellisense as well. Google and you'll see a few others running into similar problems.

As soon as I lost intellisense, I hit Resharper Options and told it not to use Resharper Intellisense and to use Visual Studio Intellisense instead – restarted my Visual Studio - didn’t help.

Turns out, whatever Resharper had done to turn Visual Studio Intellisense off is very easy to undo. Turning intellisense on or off in Visual Studio is a simple option I didn’t know about. In-fact, it is a part of those thousands of IDE options that a lot of us don’t even know exist.

If your Visual Studio Intellisense does not work, because you installed resharper and it killed your Visual Studio intellisense (or if your Intellisense doesn’t work for any other reasons) here’s a process to get back your Intellisense:

The picture pretty much sums up all you need to do to get your intellisense back in Visual Studio but if you’re a “Follow-the-instructions” kind of guy here are the instructions:

1. Hit Tools / Options in your Visual Studio.
2. On The Left Tree click Text Editor / All Languages.
3. Under Statement completion ensure that “Auto list members” is checked with a tick mark. (Make sure that this option is fully selected and not partly selected)
4. Under Statement completion ensure that “Parameter information” is also checked with a tick mark. (Make sure that this option is fully selected and not partly selected)

If you’ve downloaded Visual Studio 2008 / Orcas Beta Releases and have observed that you do not get intellisense (for whatever mysterious reasons) the above procedure works with Oracas too and will help you get your intellisense back. And if you're like me, hopefully with your intellisense back, the world will seem like a slightly better place to live in. :)

At a client’s office, almost a year ago, a very talented developer on their team thought it was interestingly funny when I said - “and that’s how you divide and rule”. “We call it Divide and conquer” – he laughed. [Being an Indian, at times my English tends to have a slightly different touch to it. :)]

“But you’re probably correct. You don’t just want to conquer. What you really want to do is to conquer and then control the situation and rule, for a long time.” - He added on.

No, we were not making a sinister plan to take over the world. We were just talking about how we can break one big Monolithic BizTalk Orchestration into smaller, easy to mange, easy to comprehend and faster orchestrations.

He had drawn up this Big Design of their existing approach on the left and then I had proceeded to draw smaller designs of multiple Orchestrations and how they would talk to each other on the right when I finally wrapped up the meeting with the line “divide and rule”. I was suggesting that he break his Orchestrations down to smaller moving parts so that when a part doesn't work - he can take it out - independently - and Analyze it!

I don't think any programmer disagrees with the fact that we should Code Smaller. A Lot of basic concept articles, teach a person who is starting out on his programming endeavors how he can Break Larger Pieces of Code into Smaller Pieces. But divide and conquer (/rule) design paradigm goes beyond just writing cohesive, small and easy to maintain functions and classes.

Every now and then I see even good developers forget the Divide and Conquer paradigm under pressure. Or they simply do not put it to practice for tasks other than coding. I've recently seen a very capable business analyst trying to learn build management by taking a CuriseControl configuration file and trying to configure CriuseControl to get the source code from SVN, fire the build, send email notification when the build fails and log the result in the formatted HTML report, all at once.

When I was called in to help, my first reaction was to wipe out all other code from the 50+ line config file - and leave just 5 lines that will have cruise control fire the build. Turns out, those five lines were broken. Once that was fixed we moved on to Getting the source code from SVN - another 3 lines which just worked. We kept fixing a part at a time and soon we were done in a couple of hours.

I've seen so many engineers (Highly capable ones. At times, I'm guilty of this too) run through more than 10 screens before they can reach a reported bug and just reproduce it. Then apply the fix, go through the screens all over again only to find out that the fix doesn't work. Then start thinking of a different fix. Over and Over again. Spending more than 5 minutes on every attempt, just to check if the fix worked. 

When we do this the time taken to fix a bug increases dramatically, the frustration level increases dramatically and the ability to think using a Pragmatic Approach comes down with every failed attempt. We start programming by co-incidence! In situations like these, Isolating the problem by replicating it using smaller code snippets and moving it out of your codebase so that you can analyze it separately, can help a lot. 

If you are trying to fix a bug that requires more than a couple of minutes to just reproduce and has taken more than 5 attempted fixes already, you might be better off isolating the bug by bringing it out of the codebase and reproducing it independently using simple code snippets. If you are finding a bug too complex to fix you're probably trying to fix more than one bugs at a time. If a feature you're building in your sprint seems too complicated you're probably trying to build two connected features simultaneously.

In the pressure of fixing a bug that refuses to get fixed or in the excitement of writing code for something fairly complex, it's very easy to tell yourself - "I'm almost there!" - and it's easy to spend away hours or sometime even days - by continuing to tell yourself that, not realizing that you're in fact, getting nowhere!

If something takes much longer to fix or build than you initially expected or you're starting to get frustrated with a problem - Divide and Conquer! And then, once you've conquered the problem, enjoy your Rule over the situation! :) 

I've often said that the really good part about Windows is What can be done, or sometimes... what happens ("seemingly automatically"), can be undone (and explained). The same is also true for Visual Studio 2005. At rare occasions there are errors in the IDE which seem magical and mysterious. With the right debugging techniques, commands, some time the mysterious errors can be fixed and explained.

I've been busily coding away at Windows Workflow Foundation for a few months now. Currently I'm using the final released version of Windows workflow foundation with the released version of Workflow extensions for Visual Studio, and my experience with WF has been very good. So when this strange error popped up today without any particular reason, I was a little surprised.

The error wasn't very helpful in describing what was going wrong. All it stated was: Package Load Failure. It basically said - "Package 'Microsoft.Workflow.VSDesginer.DesignerPackage, Microsoft.Workflow.VSDesigner, version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' has failed to Load Properly (GUID = {some_guid}..." and then it went on to ask me If I wanted to disable my workflow foundation extensions for now.

Even though my workflow project opened and worked perfectly this was just an irritating error which popped up every time I started Visual Studio 2005. Determined to put an end to this harmless yet irritating error, I started my investigation and Google searches.

I started off with basic commands like - "devenv.exe /setup" - which did not fix the issue at hand. Then there were posts out there which suggested that I delete my native images and regenerate them using the ngen.exe tool. That solution did not seem to work either.

After a few hours of Google searches I came across this post which basically described what the issue was. Turns out, a few days ago I had tried my hand at writing Visual Studio Add-ins and had forgotten to delete an Add-In I had written. Remains of my HelloWorld Addin existed in "C:\Users\admin\Documents\Visual Studio 2005\Addins" on my Vista Partition.

All I had to do was to delete the ".Addin" file (which btw, had nothing to do with Windows Workflow Foundation, so it's a little difficult to suspect this would be the cause of the problem) and as soon as I had done that Visual Studio Started without any Windows Workflow Extension Add-in errors.

If this doesn't do the trick for you - here are few other commands / resources which are usually helpful in catching and fixing Visual Studio.NET 2005 IDE issues:

1. devenv.exe /setup - very useful for a host of other IDE setting related problems or if you just want to restore VS settings to their original state. Did not help in my case because the failed add-in was something I had written myself and my problem had nothing to do with visual studio settings. In my case, the settings were just fine, even though I had initially suspected that they had gone corrupt. 
2. ngen.exe - Aaron Stebner's Post describes this pretty elaborately. The basic idea here is to delete your Visual Studio Native Image files and regenerate them using this tool.
3. devenv.exe /log - this generates XML log which can be quite helpful in trouble-shooting various startup issues with the IDE.

And if you're still struggling Aaron Stebner also provides a Definitive list of workarounds for Package Load Failure errors in Visual Studio 2005, here.

We spend so much of our time with the IDE everyday writing code. Mysterious errors like give us a chance to look under the hood and see what's going on. It's just like the joy of fixing that little problem in your car, yourself. After all knowing how to fix minor problems with your car, or knowing how to replace a flat tire, is also important besides knowing how to drive. Isn't it? :)

For the past couple of years my desktop ran on a Windows 2003 Server which was tweaked to make windows look like a Mac. I loved my desktop, but I also loved everything that had been going on the Windows Vista side and had been trying things out on VMWare instances and other non-work machines since the Beta 1 days. I had always stated that I would move to Vista as soon as Microsoft comes out with a Released version. Just wasn't adventurous enough to run a Beta version of an Operating System on my primary work machine. Yesterday, I finally made the move to Vista.

As a developer / geek, there were a few minor hiccups in 'getting up and working' and I'll probably post about all of those and their workarounds in other posts but this post is focused on getting Visual Studio 2005 to run with F5 / Play based Debugging on ASP.NET 2.0 Web-sites. I thought I would post about and document this, since this was the most tricky part and 'almost' kept me awake all night, trying to figure out what the heck was going on.

The Vista Install itself was a Smooth install. Minor hiccups here and there. Surprisingly, there were no drivers issues (things have come a long way since the Beta 1 days, when I had a bad time with the drivers). I didn't have to install a single driver manually. It detected everything on my Dell 700m and pretty much installed it, automatically. Sweet! Most hiccups were compatibility issues with 3rd Party tools, which is expected anyway, because of the enhanced security. Workarounds and alternate tools that work in Vista were pretty easy to find. Yes, there were some very minor issues with the default display drivers - which work fine with extended monitors but somehow, will not let me run on a external projector. I think I can live with that till Dell comes out with their own drivers. [This was resolved. If you googled to this page, in search of Intel-Adaptor-on-Dell Display Driver issues for Vista, see update at the end of the post.]

The real "Opps!" moment however, came when I was done with installing IIS 7.0 and started installing Visual Studio 2005. This is when I was warned that Visual Studio 2005 has known compatibility issues with Vista. I ignored the warning and the installation continued smoothly. Finally I decided to test my installation by making a simple ASP.NET 2.0 Hello-World website. Apparently, Studio would not let me open a website from the Local IIS.

The Warning Said: "You must be a member of the Administrator group on the local computer to access the IIS..."; This however, is a known issues and has to do with the Vista's On-Demand Administrator (i.e. UAC) feature. Installation of additional IIS components, A right click on Studio's Shortcut, followed by a "Run As Administrator" fixes this issue. There's a detailed post on this both as Scott Guthrie's Blog and MSDN. Both of these are pretty helpful and elaborate; So I won't repeat that information here.

After I did everything mentioned in the MSDN / Scott's Post, I could now open web sites from the local IIS. But wait, that was not the complete Fix. Once those steps were applied there were issues with Visual Studio which wanted me to have Integrated Windows Authentication in the Virtual Directory. Now this is something that is not installed by default with IIS 7.0. Which means that I had to explicitly go to "Turn Windows features on or off" and install Integrated Authentication for IIS. (I went ahead and installed all three since I am used-to and use all three - Integrated, Digest and Basic, in different projects. With this done I configured the virtual directory to use Integrated Windows Authentication using IIS Manager.)

So, was that it? Not Really. I still wasn't able to Debug my website. This time Visual Studio showed a security Dialog Box telling me that wasn't able to start debugging on the web server:

The workaround for this is to configure the site / virtual directory (depending on what you're trying to debug from Visual Studio) to run under the "Classic .NET Pool". To Do this just right-click the site on the new IIS Management console and click "Advanced Settings". In the Property Pane that opens up, change the Application Pool Setting to "Classic .NET AppPool" instead of "DefaultAppPool". 

With this done I opened my sample site in Visual Studio.NET 2005 and clicked the Play button (F5 key) and the Debugging worked, just like it should!

Yet another tricky Gotcha here is that changing the Application Pool for the website to Classic .NET pool doesn't seem to change the pool for all virtual directories under it. In other words, if you moved your entire site to DefaultAppPool but are trying to debug a specific virtual directory, you still need to go ahead and manually change the Advanced settings of that Virtual Directory to run Classic .NET AppPool, to enable debugging on it.

There were some 'really convincing' posts out there, that I came across, in a couple of Forums (I can't seem to find the link to those) where people suggested that F5 / Play and Debug is something you cannot do in Vista. I guess, that information is either old (from early beta builds) or just inaccurate. I would have liked to post a reply there and clear this up, but I can't seem to find the link again after reaching the right answer. So, I'm going to post this article here and hopefully Google will index it and help others who're trying to get this to work. 

Update [12/29/2006]: If you are looking for more details and other approaches, Mike has recently provided detailed step-by-step instructions on various approaches you can take and has described several tradeoffs associated with each approach. His detailed post is available here.

Update [02/07/2007]: Even though this post is not directly related to Dell 700m Intel Display Cards and Vista drivers for these cards a lot of people seem to be googling their way to this page in search of similar answers. This update might help. If you are running Intel(R) 82852/82855 Graphic Adaptor on Your Dell 700m and are having problems switching to clone mode with Dual Monitors or running on a Projector by pressing Fn-F8 key, start your Add New Hardware Wizard on Vista, select the manual driver installation process, choose Display Adaptor in the type of device and from the list of drivers Vita offers, choose Intel as Manufacturer, and "Intel(R) 82852 / 82855 GM/GME Graphics Controller (Microsoft Corporation - XDDM)" as your driver, even if Vista had detected your driver successfully during installation. Complete the Wizard and Reboot. Once the reboot is complete, you should be able to see two display adaptors with the same name installed in your Device Manager. Now disable Extended Desktop and should be able to switch to a projector or clone your desktop on your second monitor using the Fn-F8 key.