Intellisense in VS2005 stops working

Its a very well known issue with VS2005. Intellisense is not all intelligent, though it is programmed to be like that. It is indeed helpful and helps us avoid a lot of dog work and remember the big long names and types and parameters a function takes and all that regular crap. But the bad thing is that, the intellisense works fine for the first few days until we get addicted to it and one fine day when you are close to your deadline it suddenly stops working crippling you like anything and your work almost comes to a halt.

Thank god for editors like Vim and build systems which use "Make" and other command line tools. These keep our mind fit enough to do some exercise in case of emergency. Nevertheless we still want that intellisense thing to work, because we have this "IDE" here and it must be better than any editor. So here is how you get it working again:

• Close the solution.
• Go to the directory of the solution and delete the .ncb file.
  
• Re-open the solution and build it once. The .ncb file must be regenerated now. This must wake up intellisense again and get it working.
• If not then delete the obj directory of the project also and then build it again.

If none of these work then there is some serious problem that you should not try solving and stop reading this blog and read something useful.

VS2005 has a feature (supposedly) called "Copy Local"

VS2005 and .NET users are pretty familiar with the way the IDE makes the job so easy and keeps us away from all the build related things like references, linking and all that stuff. But in many cases this might actually be far from desired behavior. One such that recently took away some of my time was the "Copy Local" attribute on the references. This is a boolean property on the references added to a project. If this is set to true, then when the project is built the assemblies added as references as copied to the 'bin" folder of that project. Depending on the build, its either the "Debug" or the "Release" folder. With this, in future whenever the project is built, the DLLs in the bin directory are used, unless you change your references. This will cause a problem when one of the referred assembly is updated and you expect the new behavior, but get the old one instead.

Example, You would have added an assembly, E:\assemblies\MyAssembly.dll as a reference. Now when you want to update the assembly you typically replace the old MyAssembly.dll with the new DLL in the above mentioned location. And then you expect your project to reflect the new assembly, but it does not do that because "Copy Local" being true would have lead to the old DLL being copied to the bin folder of the project and though you updated the DLL in its original location, the reference was pointing to the DLL copied to the bin directory.

So watch out for this Feature. From what I know, this feature can be serialized in the assembly itself. Though this might be a good feature for applications which will use the same DLLs for a long time, this is clearly a bad choice for people who are writing small test applications to test their DLLs. Because with every new build the DLL version changes and yet the references point to the old one.

.NET GAC --- CompileTime v/s Runtime synchronization

GAC - Global Assembly Cache is just a run-time thing.

People familiar with .NET will surely know about GAC. Its just a one stop for any application running on the .NET framework to look for the assemblies (DLLs). When ever we run any .NET application, the framework will look for the referenced assemblies in the GAC. Note that even the version number of the DLL must match. If the application was compiled with an assembly 'A' of version 1.0 and you currently have anything, but 1.0, the application will not run. It needs exactly what it was compiled with. And the best part is that multiple versions can co-exist in the GAC

But this GAC look up happens only at the run-time. In Visual Studio, we will add the required assemblies for a project under the project references. These references will be pointing to the locations where the assemblies are present on the file-system and may be remote locations in case of web references. When we build the project the compiler will look at these locations and not in the GAC. Now if you are referencing an older assembly but we have a newer version in the GAC, then the project will compile but not run. Because at run-time the framework will look for the older assembly but does not find it in the GAC. So be sure of updating your references when your assembly of a particular version in the GAC is updated or replaced by an assembly of a different version.

This problem becomes still more evident and a little tricky when we are using an assembly(say assembly 'A') which again depends on another assembly (say assembly 'B'). And in such a case the problem can become evident even before compilation itself(If the assembly 'B' is related to designer of the Visual Studio). Say assembly A-1.0 was built using assembly B-1.0. Now when we use assembly 'A' by adding it as a reference to our project we are using assembly 'A-1.0' that was built using assembly 'B-1.0'. 'B' does not come into picture during compilation at all. When we build our project and run it, the framework looks for 'A-1.0' and finds out that it needs 'B-1.0' and finds both in GAC and runs the application. Here as 'B' does not come into picture during compilation, it is sufficient if we have it GAC, where as 'A-1.0' has to be at some location on the file system (either local or remote).

Now if 'B' in the GAC is updated, i.e 'B-1.0' is replaced by something like 'B-1.1', and you try to run the previously built application, it fails. Though the assembly referred by you , 'A-1.0' has not changed, the assembly 'B' which is necessary for 'A' has changed. So at runtime the .NET framework will search GAC and the current-folder for 'B-1.0' and as it would not be found, the application fails.

There are a couple of other posts about GAC and references in VS2005. Look out for those.

One deadly enemy today’s youth is facing

This is another thing that swamiji told us during the gyaan transfer. The earlier one was about us all being so lucky. This post is about one of the several reasons why today’s youth is going haywire. As you would hear from any other staunch Hindu or a strong supporter of ancient ways of life, the first reason mentioned by swamiji was “Westernization”. But this term here was not against “Globalization” or international exchange. Swamiji also believes that there are a lot of things that we have to learn from the west and yet a lot more that we should not. But here are a few things that he said about modernization and how it has affected us.

Recent technological advances have almost removed the barrier of distance for communication. This has lead to increased and more frequent talk to our kith and ken. But this is what swamiji said “This technology has increased “Samparka” (communication) but has drastically reduced “Sambandha” (relation)”. This is very much true. With increase in communication the feeling or urge in us to visit our parents or relatives has come down. But this again is a choice. There is nothing like free meal, everything comes at a cost.

Coming to the enemy that we are facing, a surprisingly simple fact which is neglected is that in most cases the starting salaries of the current youth are very close to the retirement salaries of their parents. Though we can argue that the value of a rupee was much more than what it is now. The world has been through inflation and all that. But despite any inflation, a rise to the extent of retirement salary becoming starting salary is a steep one. This is not just alone. There are strings attached to it. The earning age is lesser than what it used to be and the responsibilities are lesser. All these result in superfluous money staying in the hands of not-so-mature and the so called adventurous youth. This combination of lack of knowledge and excess money is the deadly enemy that today’s youth is facing.

After listening to this I have realized that I should keep a check on my expenses, by which half of the enemy is under control and do lend my ears to elders to deal with the other half. Hope I am successful and so are the others in the same league as me.

Hari Om.

So many of us are so Lucky; but not all are so.

Sometime in November I had been to been on a bike trip to Mysore with Pavan.A.C and a couple of his friends. Though I really liked to go on a bike trip to Mysore, this one is something that I will not look forward to have again. The lack of preparation made me really tired and not to mention the dust, the hot wind and the charred faces at the end of the trip. But this blog post is not at all about the trip or the adventure. This is about a discussion that we had with Swami Maheshatmanandaji during our late night debates. Well actually this was more of gyaan transfer than a debate.

This is one of the several things that he told us. When we were discussing about the facilities provided to us as V’Shala in comparison with students outside we simply agreed that we are a lot lucky than several hundreds and thousands of children studying in other schools. At that time swamiji said that we are way too well off and blessed than what we actually think or just said. It’s not just the extra facilities or amenities available to us that make us the fortunate ones. The very fact we could live a “Student Life” during our childhood is something that a lot of unprivileged and unfortunate children do not get. This was something known to me and did not appear like some hard truth, but the gravity of the words was way stronger than I could imagine. To justify this he cited an example.

During the last vacations when he had been to bus-stand to see off some students going home, he saw a child in his early teens drunk and swaggering on the road. Well this is the treachery of the nature, I thought. Not all the fingers are same. But the treachery actually runs deeper than this. Swamiji continued and told us that it’s not the boy’s fault at all. The boy, by birth, has every right to be a student, to play like any other child of his age would do, to learn, to experience the joy of learning, to dream of great and big things and make every possible attempt to achieve them. He is deceived of all these. Instead he probably became an unskilled labor doing all sorts of small and petty jobs to earn his meal. Fortunately or unfortunately he got a little extra money which he used to purchase illicit liquor and now he is on the roads, unchecked, unadvised and without and help.

I protested to this saying that it’s the law of the nature and about he being unadvised, I said that he surely would have been told by someone about leading a healthy and successful life. Swamiji sapped back at me suddenly in strong disagreement. Here are his answers for my protests:

It’s not the responsibility of the nature. Is it nature that has taken care of us till now? Well it stuck me that parents/guardians are the ones who come into play here. They are the ones who nourish us, take care of us and make sure that we reach good heights and make us capable of leading a respectable life. This is probably what is missing in that boy’s life. Either he is not privileged enough to have a life with his parents or he is not fortunate enough to have parents who can give him a life. And about the advice, only words will not suffice and all that he would have got would be just that. As Swami Vivekananda said “Don’t advise hungry stomachs, they can’t be receptive”, this boy should be first shown some light and then advised to reach that light.

Then I realized what he earlier meant by we being way too privileged than what we talk or think. The only solution is to set a balance in nature and that would be possible only on a one-on-one basis with the privileged youth standing up and deciding to take care of one underprivileged. More about that in another blog post. As of now just realize that if you are reading this you are one of the most privileged in the mankind.

Hari Om.

WaterWays - An amazing way of transfer

Water ways - The most cost effective transport system:

This is the outcome ofyet another discussion with Doddappa(Uncle). We were actually about varied careers and how one can be successful and not be yet another engineer or a doctor. Though we came up with a lot of options like being a scientist after doing a masters in pure science or may be be take up journalism and many more, but the one that stood out as an extremely lucrative one was Merchant Navy. Then my sister asked the typical youngster question: "What do these people at Merchat Navy do??!!". That was what my uncle was precisely waiting for, an opportunity, and he started the gyaan transfer.

Though most of what he said was known to me, there was one thing which struck me like anything. He said that a large part of mass-goods transfer i.e actual large scale business hapened through water-ways because it was the cheapest mode. Though I knew this bit of fact the reason for this interested me more than anything. It is very simple. For roadways we ave to "maintain roads", for railways we have to "maintain rails", for airways though we do not have to "maintain air" its really a costly affair to maintain airports, the air traffic control and hence makes air-transport an ultimately costly choice for transfer of all regular mass usage goods. But with waterways there is no such thing at all. Ships move on waters and seas and oceans take care of that. Traffic control is a lot easier than airways. From what I know fuel is also much cheaper compared to the extremely high quality air-fuel. (So much of comparision with airways is because the others cannot be used for transport across the globe)

So all that we need to worry about is ports/harbours. i have heard about natural harbours and hence I guess even those costs are partly taken care by Mother nature already. This and so many other things make water ways the obvious choice for shipping large amounts of goods. may be other modes of transport will make transportation charges itself more than the actual cost of the goods being transported.

Now there might be some environmental considerations that need to be taken care of. Because recently when some American or French ship was coming to Gujarat port for scrapping there was a lot of opposition as it was hazardous and leading to pollution big time. But still cost stands a big deal. I hope our good scientist fellows will soon find a less hazardous and pollution-free shipping ways. :-)

So businessman and would be businessman, watch out for your shipyard. And also learn how to swim, just in case, you know. ;-)
Hail Water-ways, Hail mother Nature... (Thank god I can swim :P )

Registering and UnRegistering a DLL - Two ways

There are 2 ways to register a DLL.
Any DLL registration happens through the windows tool Regsvr32.exe present in C:\Windows\System32\

• The HARD-way: Using the above tool directly from command line. This is the obvious geekish way. This actually turns out to be simple after some practice. The command would be as per the following specification:

Regsvr32 [/u] [/s] [/n] [/i[:cmdline]] dllname
/s - Silent; display no message boxes
/u - Unregister server
/i - Call DllInstall passing it an optional [cmdline];
     when used with /u calls dll uninstall
/n - do not call DllRegisterServer; this option must
     be used with /i

• The EASY-way: Right-click on the DLL you want to register and open it with the above tool. Again the tool resides in C:\Windows\System32\. Thats it. The DLL if proper would be registered and error messages if any would be shown in an alert box.

I do not yet know of a easy way for unregistering a DLL. So for that command line is the way.