Kubernetes, Azure Dev Spaces and Visual Studio

Some powerful tech in the title, this isn’t so much a blog article but a correction to some out of date Internet information that might help someone looking for a brief moment till the links change again.


Great article and nice short video that captures just enough imagination! However, the link to http://aka.ms/signup-vsce will now give you a 404.

Instead, head to:

az aks use-dev-spaces -g MyResourceGroup -n MyAKS



Workaround: ReactScriptLoadException: Error while loading “~/build/server.bundle.js”: ReferenceError setTimeout is not defined

For a pet project I have Visual Studio Online using npm to install webpack and run a gulp task to package my ReactJS app that uses ReactJS.net serverside rendering.

However when it deployed to the server, an error was shown that was not encountered locally:

ReactScriptLoadException: Error while loading “~/build/server.bundle.js”: ReferenceError setTimeout is not defined

I tracked the difference between my local execution (which works) and my server deploy to a point release difference in webpack 1.13.0 vs. 1.13.1. My package.json file had “webpack”: “^1.13.0” so VSO was installing the latest which was 1.13.1 but locally I still had 1.13.0 as I am not currently running npm automatically.

As a temporary workaround for this issue (and preferable way forward) I’ve removed the carat and opted to use webpack 1.13.0 explicitly (something I should have done in the first place) but I haven’t looked into why the behavioural change is occurring yet.

Intermittent “The request was aborted: Could not create SSL/TLS secure channel.” solved

When trying to establish a TLS connection, the above message was seen intermittently. Other messages included “The underlying connection was closed: The connection was closed unexpectedly.”

At the same time these apparent comms errors occurred, looking in the System event log showed a lot of Schannel EventCode 36888 with the message:

"The following fatal alert was generated: 80. The internal error state is 301."

The explanation for code 80 from http://blogs.msdn.com/b/kaushal/archive/2012/10/06/ssl-tls-alert-protocol-amp-the-alert-codes.aspx is:

An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue, such as a memory allocation failure. The error is not related to protocol. This message is always fatal.

The key to solving this was memory allocation failure, it was not the external system but internal memory pressure that was causing the problem. Fixing the memory issue also resolved the communications issues.

Unfortunately this is just one cause of this error message, other times it has turned out to be the external system in which case System.Net tracing could help:

(At the time, one of the external systems had upgraded a version of Apache that had an issue in mod_proxy_http).

There was an error processing type ‘{0}’. Type member ‘{1}’ declared in ‘{2}’ is missing required ‘{3}’ property. If one class in the class hierarchy uses explicit sequencing feature ({3}), then its base class and all derived classes have to do the same.

This was due to having Order on some but not all DataMembers of the data contract (might have been more helpful if the error had actually contained values for the format parameters).

Resolving namespace conflicts in C#

This came in useful today to enable a type to be qualified by the assembly since the namespace clashed:

Background: I’m using a client proxy assembly that had to match the exact namespaces the DLL (due to the JSON contract serializer needing a data contract that matches exactly on .NET namespace due to that __typeName mechanism) on the server was using.

FIX: System.ArgumentException: ”, hexadecimal value 0x07, is an invalid character.

If you get the following exception, try specifying CheckCharacters as false on XmlWriterSettings:

XmlWriterSettings settings = new XmlWriterSettings();
settings.Indent = true;
settings.CheckCharacters = false;

XmlWriter writer = XmlTextWriter.Create(sw, settings);

System.ArgumentException: ”, hexadecimal value 0x07, is an invalid character.
   at System.Xml.XmlEncodedRawTextWriter.InvalidXmlChar(Int32 ch, Char* pDst, Boolean entitize)
   at System.Xml.XmlEncodedRawTextWriter.WriteElementTextBlock(Char* pSrc, Char* pSrcEnd)
   at System.Xml.XmlEncodedRawTextWriter.WriteString(String text)
   at System.Xml.XmlEncodedRawTextWriterIndent.WriteString(String text)
   at System.Xml.XmlRawWriter.WriteValue(String value)
   at System.Xml.XmlWellFormedWriter.WriteValue(String value)
   at System.Runtime.Serialization.StringDataContract.WriteXmlValue(XmlWriterDelegator writer, Object obj, XmlObjectSerializerWriteContext context)


I had to do this because I didn’t care that 0x07 was an invalid character and the exception only started happening when I used XmlWriterSettings for indentation.

This is an alternative to Robert Horvick’s now dated article on MSDN.