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
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.
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).
I’ve noticed that the .NET DataContractJsonSerializer doesn’t recognise the __type if you format the JSON and it’s not the first __type in the document.
To workaround this but still have semi-formatted JSON, ensure the “__type” immediately follows the opening curly brace.
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).
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.
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.