The Problem

Recently, at work, we ran into an issue where a particular package update (angular-bootstrap) broke one of our crucial features.  Apparently, as mentioned here: https://github.com/angular-ui/bootstrap/wiki/Migration-guide-for-prefixes, the newer version (since 0.14.0) requires the directive selector to be prefixed with “uib-“. 

Potential Solutions

So, there are some solutions / options here:

Option 1

Completely fall back to version 0.13.4 to avoid the prefixing.

Advantage: there is very little new code that depends on the newer version where everything is prefixed with “uib-“.  So there is really minimal rework to be done to fix this issue.

Disadvantage: This locks any new development on the same project to version 0.13.4 and if anything new added afterward, we will not be able to take advantage of that.

Option 2

Upgrade the crucial feature to the latest version (i.e. 1.3.3).

Advantage: If anything new implemented in the package, we can take advantage of it.   Latest and greatest, yes!

Disadvantage: You are basically on the upgrade train forever.  Tons of rework and retesting to make sure that legacy code is always working going forward.

Option 3

Somehow allow multiple version of the library to be used side-by-side

Advantage: No major rework need to be done on the crucial feature.  It can stay happy at version 0.13.4.  New custom components / features can be on a newer version of the library (i.e. 1.3.3).  Good isolation.

Disadvantage: Eh…. *thinking*… *more thinking*…. nothing… (Well this is not true, we will still need to retouch the crucial feature where we are importing this component since the alias will change in the require / import statements)

Option 3 is definitely the clear winner here, but the question is … HOW?

So, I’ve looked at the different package managers that come to mind, which are:

1. NPM
2. JSPM
3. Webpack

Webpack

Well, let’s rule Webpack out since it’s not really a package manager.  I have to admit I’m not a Webpack user, but looking around the web, I found this article: http://ilikekillnerds.com/2015/07/jspm-vs-webpack/ which basically tell me straight out that basically, and I am quoting here, “It actually offers almost everything that Jspm does except it is not a package  manager”.  Then again this article is pretty old (in JavaScript timeframe, LOL), so things might have changed now.  If anyone know any different, let me know…

So that leaves me with only NPM and JSPM.

JSPM

Now, at work, we are already using JSPM, so this becomes the first choice for me to investigate.  And from my investigation (which is not much…), basically, I ran jspm help on the console and Ouila! I came across this line: install jquery=…     Hmm… that looks like aliasing to me, so I gave it a try.  Created a test folder, ran jspm init, and then ran jspm install angular-bootstrap0134=angular-bootstrap@0.13.4 and then again jspm install angular-bootstrap133=angular-bootstrap@1.3.3.  And… guess what?  It FREAKING works!!! YAY!!

In package.json I saw:

"jspm": {
  "dependencies": {
    "angular-bootsrap133": "github:angular-ui/bootstrap-bower@1.3.3",
    "angular-bootstrap0134": "github:angular-ui/bootstrap-bower@0.13.4",

Similarly, in system.js config file:

map: {
    "angular-bootsrap133": "github:angular-ui/bootstrap-bower@1.3.3",
    "angular-bootstrap0134": "github:angular-ui/bootstrap-bower@0.13.4",

Therefore, now where I need the older version I can just require(“angular-bootstrap133”) or in ES2015 syntax: import “angular-bootstrap133”

PERFECT! Problem solved.

So…

NPM

Just to be complete, I tried to figure out how to do this using plain vanilla NPM… 

I looked around on the web and I found this article which is pretty old and it looks a bit promising: http://blog.izs.me/post/1675072029/10-cool-things-you-probably-didnt-realize-npm, especially the big bold section titled 1:Handle multiple versions of the same thing at the same time.

Looked through npm help install documentation as well, but there is nothing there that tell me how to do this…

So, I tried by running npm install angular-ui-bootstrap@0.13.4 --save and that net me a node_module/angular_ui_bootstrap folder and the following lines in package.json:

"dependencies": {
   "angular-ui-bootstrap": "^0.13.4",

Then I tried again using npm install angular-ui-bootstrap@1.3.3 --save, and as expected, it basically override the node_module/angular_ui_bootstrap folder with the newest version and the dependencies line for it is also updated to:

"dependencies": {
    "angular-ui-bootstrap": "^1.3.3",

This is DEFINITELY NOT what I want.  So searching further on the web, net me no solution to this.  There are discussions around this topic such as this GitHub issue: https://github.com/npm/npm/issues/5499, which looks like this is still not possible using NPM  and http://stackoverflow.com/questions/26414587/how-to-install-multiple-versions-of-package-using-npm  which again point to JSPM for something like this.  Also found a google group message (couldn’t find it again) that basically tell you to install the old version, copy it to a folder like angular-ui-bootstrap0134 and install it again so it will override the original folder with version 1.3.3.  Very very messy.   I guess a different approach is to create your own copy of npm package for the different versions and use those instead… again not very good solution.

Conclusion

And so… the clear winner here is… JSPM.  Lucky us… we already use JSPM at work .

At work, we are still doing Cloud Service for our Azure solution which requires the Compute Emulator.

I was helping my co-worker to test his upgrade to Azure SDK 2.9 so we could move on to Visual Studio 2015. At the time, our solution was running on Azure SDK 2.6 and so I installed Azure SDK 2.9 for Visual Studio 2015 and ran the upgraded version of our solution on my machine. It ran just fine but since we wanted to make sure that this is properly tested, we didn't want to commit to using Azure SDK 2.9 yet.  Until such point in time, we actually wanted the main development to still use Azure SDK 2.6.  This itself is fine since we specifically created an Azure SDK 2.9 Upgrade branch so the affected source code is isolated to that specific branch and the rest are still on 2.6 SDK.  This is all well and good until...

When I tried to go back to my own feature branch that is still on Azure SDK 2.6 and started the debugging session, the Azure Compute Emulator did not work any longer.  It kept throwing the following "Error: The installed Microsoft Azure Compute Emulator does not support the role binaries." and suggested that I upgrade my solution to Azure SDK 2.9 which I certainly do not want to do until our test is completed and passing.

I am now in a bind.  I can't run and debug my own feature branch due to this problem.  Apparently the emulator does not support side-by-side installation and itself has been upgraded to version 2.9 and Emulator 2.9 just don't like 2.6 projects.  Sigh.

After looking around the web for the answer and finding none, I got to thinking that there are about 2 options that I could do to fix this...

Option 1.  Use System Restore to go back to a previous state when the SDK 2.9 bits are not yet installed... Unfortunately, the installation didn't create a System Restore point and I didn't do it manually either... so there goes that option.

Option 2.  Somehow reinstall Azure Compute Emulator 2.6 and force it to overwrite the current 2.9 Emulator.  This seems to be my only option now...
So, from previously spelunking attempts, I know the Azure SDK bits is located in "%PROGRAMFILES%\Microsoft SDKs\Azure\Emulator".  If my hunch is correct, the bits should be installed here.  So, what if I try downloading the 2.6 Compute Emulator installation bit from https://azure.microsoft.com/en-us/downloads/archive-net-downloads? Clicking the Azure SDK for .NET version under April 2015 (version 2.6) link which took me to: https://go.microsoft.com/fwlink/?linkid=534218&clcid=0x409. Clicking the big red Download button showed me a bunch of bits which include the MicrosoftAzureComputeEmulator-x64.exe which is exactly what I needed.   After downloading the program, I tried running it and got stopped in the middle of installation since a newer version of the emulator is already installed... So, now what do I do?

Well, I tried running that exe using /? options and lo and behold, there is an /uninstall parameter that I can use to uninstall... So, what if I download the 2.9 Compute Emulator installation program and run it with that parameter from Command Prompt... and... Voilà!! All the bits now got removed from inside the "%PROGRAMFILES%\Microsoft SDKs\Azure\Emulator" directory.  Great... so now I tried reinstalling the 2.6 Computer Emulator bit using the 2.6 installation bit... and... it got installed just fine. 

The final step was to try running my 2.6 solution back from Visual Studio and... YAY, it ran just fine.  Problem solved.

I hope this is useful for other people that also run into this issue.  Like I mentioned, I couldn't find anywhere on the web that explains this.

Enjoy.

1. Login to your Visual Studio Online and navigate to the related project collection group where the affected build belongs to.
2. Click on the cogs (Administer Account) link next to your account name to bring up the Collection Control Panel page. 
3. Click on the Services tab and expand the endpoint node you are tying to deploy your build to.
4. Choose Endpoint Administrators group and click the Add... button and select Add User.
5. In the add user dialog, expand the selection and choose Elastic Build (...) user.
6. Requeue your build from VS or from the portal and if there is nothing wrong with your check in, your build should get deployed correctly.  (If this does not work still, try adding the same Elastic Build (...) user to Endpoint Readers group as well.

I was answering SO questions and someone asked how to null guard stuffs when calling a property or a method of something that might be null.

I mentioned that C# 6 provides a way to do this by allowing you to use the following syntax: foo?.bar?.baz which will prevent the code from parsing the rest and erroring out once a null is encounter anywhere in the method / property chain which it is called null-propagation.

So, an idea popped in my mind since C# 6 is not quite there yet, how can we do this in C# 5?  After some thinking, I came up with the idea of using lambda expression combined with extension method and some generic magic that I think might work and came up with the following syntax: foo._(_=>_.bar)._(_=>_.baz)  that seems to work okay.

The implementation is like so:

public static class ObjectExtension
{
    //Probably not a good idea to name your method _, but it's the shortest one I can find, I wish it could be _?, but can't :(
    public static K _<T, K>(this T o, Func<T, K> f) 
    {
        try 
        {
            var z = f(o);
            return z;            
        }
        catch(NullReferenceException nex) 
        {
            Trace.TraceError(nex.ToString());
            return default(K);
        }
        
    }
}

The running example can be found below:

From time to time, and for whatever reason…. like oh…say… your solution contains multiple projects and you decided to upgrade the cloud service project to the latest Azure SDK from version x and for whatever reason you have a reference to a specific Azure SDK component in one or more projects that are not your Web / Worker Role project… Guess what… you might run into this (Role perma-recycling fun)  after deploying to Azure that when tested on the development fabric it is working just fine.

*Digressing*

You know what, sometimes Azure baffles me.  I upgraded my Azure SDK previously and managed to deploy it to the cloud and have it running just fine on one deployment and then when doing another deployment some time after it just refuses to start and start the recycling crap… and this is not a staging slot swap to prod slot thing, it’s direct deployment onto the production slot too.  I haven’t deep dive into Azure internal to understand what’s going on when you do deployment, but I think there are optimization steps (to make the deployment process faster perhaps) where sometimes the same VM is being used and when previously it still have the residual DLLs from previous deployment and when this happens, everything work just fine even after the SDK update and you forgot to update the outdated DLL… and sometimes, Azure just says, “… meh… screw you… I’ll drop your bit on a totally new VM and  guess what, HAHA!!, the bits that you think will be there is no longer there, so there…” and the recycling crap happens.

Is this what happened? I don’t know… maybe.  Some insights into this perhaps or not… http://blog.smarx.com/posts/what-happens-when-you-deploy-on-windows-azure.  Step 2 is a bit ambiguous…  Maybe Azure Friday will invite someone to explain how this thing works internally? *Nudge nudge wink wink*

*More digression*

You know what… this reminds me of something else… Sometimes when my Continuous Deployment build got processed by Visual Studio Online, I get this annoying Cannot copied such and such blah error during the build and the build crapped and stopped there. FAIL!  And the only thing I need to do is re-queue the build and guess what… It successfully build and deploy…

What the !(*&$&!#!!!  My theory… there is a build agent machine that is not configured right… and I was just unlucky to get sent to that agent from time to time.

*End of more digression*

Geez… what is this… Digression Inception?

*End Digression*

If you are a newb at Azure like I was previously, you’ll be scratching your head for a looong looong time trying to figure out what the heck is going on… 
It worked on my machine… Damn it..
*pull hair* … oh no *bald spot forming*.

After running into this issue a couple of time and doing searches for answers on stack overflow and what not… You’ll finally realize that you have missing reference and the web / worker role just can’t start your application because of that, which I think is the most likely candidate anyhow…

So, how do you go about troubleshooting this?

Remote Desktop is Your Friend

One easy way to do this is via Remote Desktop.

You DID configure remote desktop on that role, did you not…?

No?  You dummy you, go do it now!

… … …

You DO know how to configure remote desktop for your role, do you not?
No? *sigh*  Read this.
I’d recommend creating your own client certificate to use for this and CHECK IT INTO YOUR SOURCE REPOSITORY.  You never know when you need the certificate again… for example, when you need to redeploy the cloud service to a different Azure subscription and the original certificate is now nowhere to be found for reasons like the original developer who created the certificate on his / her machine left the company, the machine got wiped and YAY… no more certificate copy anywhere…  Happened… True story.

So, now that’s out of the way, go launch remote desktop and login…

What? You don’t remember what’s the password for the VM? Are you kidding me? *sigh*

Go read this and follow the instruction on how to reconfigure…

Event Viewer is Also Your Friend

Okay… now that you are logged into the remote desktop, go start Event Viewer.  If you don’t know how to do this, go quit and sell ice cream in a truck… or ask your boss to hire a DevOps... or go learn how to do it!!  Google or Bing maybe… like “How to launch Event Viewer from Windows Server 2012 R2?”…

Got Event Viewer up?  Good.

Now go open the Windows Logs node and drill into the Application node and find some errors (such as one that is shown below…)

AHA! See that FileNotFoundException!!! I knew it, File Not Found…. It’s the same thing that is shown in the Azure portal.

Yeah…. but… what file?…. Uhm….
What a freaking useless error message.

Okay… maybe we are looking at the wrong place…. Let’s see what else is there…

Let’s try the Applications and Services Logs node… drill drill, aha… Windows Azure/Diagnostics/Bootstrapper node… It’s related to starting up the role right?  Bootstrapping = start up, right? Must be here..

AHA! I see some errors.

… WT #(@$! CRuntimeClient: OnRoleStatusCallback #(*@#(*@#(*$  What the heck does that mean?

Yet more useless crap!

*sigh*  Oh well, let’s continue mining…

Applications and Services Logs/Windows Azure… WELL… what do you know… More errors… and this time.. we found GOLD… well, sort of…!

Could not load file or assembly ‘Microsoft.WindowsAzure.ServiceRuntime, Version=2.3.0.0…’ at XXXXXXX.Shared.Configuration….

Now we are going somewhere…

What’s Next?

Well, now that you know what it can’t find during the startup, you just need to ensure that the DLL or whatever component the role needs to start is correctly packaged and deployed to Azure.  Upgrade the DLL using Nuget and fix your references, and make sure to set the missing reference to be copied always to the bin folder.

Check in your changes, trigger your Continuous Delivery build or package it and redeploy manually.  Whatever your deployment style is… Hopefully it will work this time… 

If it doesn’t…,
Well, go figure it out. Gave you a clue on how to troubleshoot this… Do I have to hold you hand through all the process? What are you? Kindergarten student? PHAW!