2048 2048 2048 2048 – “The Windows PATH Can Be a Source of 2 Tons of Fun”

tl;dr Keep your Windows 7 PATH under 2048 characters and you’ll be good – don’t and you won’t.  In related news, if you already have a lot of dev tools installed on your PC, look at your path length first if it all gets pear shaped after your VS install…

Now the non-tldr…

I recently decided to give Visual Studio 2015 a spin… Having been working a lot with Ionic (Cordova) apps lately, I was interested to see what Microsoft was bringing to the party on that front (See Here and Here)…

The installation seemingly was going smooth enough, but at the end I was greeted with a lot of yellow exclamation marks – “man, that’s no good!”

Naturally, I start reading into the borked install components, one of which is Nuget… I see a lot of people that appear to have been in the same boat as me with previous RC installs… Now, I was installing the official final MSDN ISO release, but just figured it was in the realm of possibility that some of the issues had been carried over…  So I start following some of the processes that worked for those who’d traveled this path before me…

All of which I concluded without positive or desired results…

In addition to the messed up VS install, I began noticing a lot of other issues with my PC that didn’t exist before the attempted install..  One of the most troubling ones was that none of my environmental variables seemed to properly work anymore – %windir% resulted in a “Windows cannot find”, error as did most every other variable that I tried…

Figuring something surely must be wrong with my path, I start looking there – but nothing jumps out at me and it appears valid… Interestingly enough, from a cmd prompt %path% resulted in a very small substring of my actual PATH value – “definitely sounding like a PATH issue”, I continue to think..

But not knowing what I was looking for, I keep chasing the “VS2015 broke me” assumption via Google… Which keeps me coming up empty handed – after multiple uninstalls and reinstalls.. Keeping in mind that each install/uninstall takes about 2+hr on my quad 3Ghz/16gb dev machine – so not exactly a quick process, nor a resource light one (read: “dev machine very slow”)

After many wasted hours and not being able to shake the feeling that it had more to do with changes made to my PATH during the install more than any other system changes made, I decide to search to see if there is a limit to the PATH length (and if it’s possible to exceed this limit, if such a thing does exist)… It wasn’t until I entered in “Windows 7 path variable length” into the search that I came across this post, which answered everything…

2048 it is…  A number that I probably won’t forget for a long time…  2048….

Now, of course it would have been nice if the VS installer would have warned me of this… It would have been nice if any of the errors that made it into the installer error logs would have even so much as hinted at this… But they didn’t… but in all fairness, I am betting that MS aren’t the only or biggest offenders on this front… Though I do think that if your installer requires PATH updates and then makes them automatically for me, it should probably also ensure that it’s operating within the limits of what’s allowed by the OS… This is especially true when the company behind the installer is also the company behind the 2048 char constraint in place on the OS 😉


Ionic – CORS with Live Reload Part 2

Hello again, reader.

I wanted to follow up (better late than never, right?!) on my previous post regarding CORS issues encountered while working with the Ionic Framework’s –livereload feature.

If you’re reading this, then you likely already know that some interesting things can happen when using the Live Reload (–livereload / -l) features of Ionic… Namely:

XMLHttpRequest cannot load http://someresource.com/api/?id=1.
No ‘Access-Control-Allow-Origin’ header is present
on the requested resource. Origin ‘’
is therefore not allowed access.

As you may very well be aware, generally speaking, resources external to a Ionic/Corodova project are whitelisted in the project’s config.xml via an ‘access’ element possessing an origin property having a value of ‘*’. This is so that you can consume external resources, such as an API.

As a result of how Live Reload currently works, this origin policy has to be updated while using –livereload – where it’s changed to the URL of your live reload server (generally an http://local_ip:port variety) when you kick off the “ionic run -lcs android’ (or whatever) command.

Due to the changes of the project and perhaps due to the way the livereload does the magic that it does (I admittedly have a high level understanding of this system, as I’ve not had time to dig in too deeply), many users have ran up against CORS issues when developing/debugging using –livereload.

While I’d previously read on proxy configuration in Ionic, it hadn’t quite clicked in relation to this issue until a helpful github user spelled it out using crayon fonts for me. Here is the response that I am referring to: https://github.com/driftyco/ionic-cli/issues/89#issuecomment-86034156

Essentially, as Yonn-Trimoreau has spelled out, you can configure a proxy in your ionic.project file that will proxy your external resource requests ‘locally’, effectively eliminating CORS issues while working with –livereload…

Here is an example of this configuration (ionic.project file) for 2 proxies:

"name": "MyProject",
"app_id": "",
"gulpStartupTasks": [
"watchPatterns": [
"proxies": [
"path" : "/remoteAPI",
"proxyUrl": "http://reddit.com/api"
"path" : "/localAPI",
"proxyUrl": ""

As you’ve likely inferred, after adding the proxy configuration to your project, you will be enabled to call external resources as if they are local – “/remoteAPI” and “/localAPI” in the case of this example.

Quite useful when developing against multiple APIs or when using Live Reload in general.