Error	1	Error : DEP0600 : The following unexpected error occurred during deployment:
Illegal characters in path.
   at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
   at System.IO.Path.Combine(String path1, String path2)
   at Microsoft.VisualStudio.ImmersiveProjectServices.Shared.AppxLayoutManager.CheckPackageLayoutState(DeployPackageName deployPackageName, String location)
   at Microsoft.VisualStudio.ImmersiveProjectServices.Shared.LocalDeployJob.GetLayoutState(DeployPackageName deployName, Boolean hasFrameworkDependencies)
   at Microsoft.VisualStudio.ImmersiveProjectServices.Shared.RegisterAppxLayout.Start(Boolean forceNewLayout, Boolean forceRegistration, NetworkLoopbackState desiredNetworkLoopbackState, Boolean refreshLayoutOnly, String& packageMoniker, String& firstUserAppID, Exception& deployException)

Not knowing what to do, because the error is vague and cryptic. I decided to throw a hail mary pass and remove the application I was developing from the start menu. And lo and behold this was the problem. I know this is still a beta framework and everything, but can the Windows team please throw us a bone and put in exceptions that actually mean something.

tl;dr

Just uninstall the application you are developing from the start menu.

To understand why I can’t just use the decimal type in .NET you have to understand that BigDecimal is designed to scale way beyond typical numbers that anybody would realistically use in their day to day programming. And supporting one of these types as a standard type, would eat up much more memory than a typical programmer would want to use for a single number.

Java’s BigDecimal can scale from a number that is as small as 1 byte to as many as 64 bytes. When Java’s BigDecimal generates a byte array it can range from 5 bytes up to 68 bytes depending on the number being represented, with the last 4 bytes being an integer representing the number of decimal places in the number.

Here is what I came up with, which you can also find on GitHub’s Gist.

using System;
using System.Numerics;

///

/// A crude implimentation of the essentials needed from Java's BigDecimal
/// 

public struct BigDecimal
{
	private readonly BigInteger _unscaledValue;
	private readonly int _scale;

	public BigDecimal(byte[] value)
	{
		byte[] number = new byte[value.Length - 4];
		byte[] flags = new byte[4];

		Array.Copy(value, 0, number, 0, number.Length);
		Array.Copy(value, value.Length - 4, flags, 0, 4);

		_unscaledValue = new BigInteger(number);
		_scale = flags[0];
	}

	public static explicit operator decimal(BigDecimal value)
	{
		var scaleDivisor = BigInteger.Pow(new BigInteger(10), value._scale);
		var remainder = BigInteger.Remainder(value._unscaledValue, scaleDivisor);
		var scaledValue = BigInteger.Divide(value._unscaledValue, scaleDivisor);

		if (scaledValue > new BigInteger(Decimal.MaxValue))
			throw new ArgumentOutOfRangeException("value", "The value " + value._unscaledValue + " cannot fit into System.Decimal.");

		var leftOfDecimal = (decimal)scaledValue;
		var rightOfDecimal = ((decimal)remainder) / ((decimal)scaleDivisor);

		return leftOfDecimal + rightOfDecimal;
	}
}

To understand why I had to create my own BigDecimal type, you have to understand that the .NET decimal type always generates a byte array of 16 bytes, the first 12 being the integer, and the last 4 being the number of decimal places or the scale. And because .NET always generates 16 bytes it assumes you are always going to read in 16 bytes, which is a bad assumption, but it is what it is. And because of this 16 byte logic it brings me my problem. I was having trouble reading in any number that didn’t produce exactly 16 bytes for the decimal from Java’s BigDecimal. So I decided to create a very crude representation of the BigDecimal type in .NET.

I am putting this code out there, so nobody else has to hunt to find a solution to read in BigDecimal type from Java. Also there is a ton of room for expansion of this type, so if you do modify please let me know so I can update the gist.

The part that got me scratching my head is the fact that nothing in .NET Framework mentions ZLIB as a supportable compression type. So I had to start hunting down the specification and found that you can actually generate ZLIB compatible compression with the DeflateStream. However the format that Java and other libraries expect has a header in the stream as well as an adler-32 checksum at the end.

Here is the solution that I came up with that can be seen below and also on GitHub’s Gist.

public static byte[] ZlibCompress(byte[] data)
{
	using (MemoryStream outStream = new MemoryStream())
	{
		// zlib header
		outStream.WriteByte(0x58);
		outStream.WriteByte(0x85);

		// zlib body
		using (var compressor = new DeflateStream(outStream, CompressionMode.Compress, true))
			compressor.Write(data, 0, data.Length);

		// zlib checksum - a naive implementation of adler-32 checksum
		const uint A32Mod = 65521;
		uint s1 = 1, s2 = 0;
		foreach (byte b in data)
		{
			s1 = (s1 + b) % A32Mod;
			s2 = (s2 + s1) % A32Mod;
		}

		int adler32 = unchecked((int)((s2 << 16) + s1));
		outStream.Write(BitConverter.GetBytes(IPAddress.HostToNetworkOrder(adler32)), 0, sizeof(uint));

		// zlib compatible compressed query
		var bytes = outStream.ToArray();
		outStream.Close();

		return bytes;
	}
}

I am putting this code out there, so nobody else has to hunt for hours trying to find a solution that should be built into .NET given the popularity of the ZLIB compression format.

When you compile a library against a strong named assembly, only that specific version of the assembly can be used with the assembly that you are compiling with out resorting to heroics. You may say what is the big deal that is how all libraries are compiled and linked. But that isn’t true in .NET, if you don’t have a strongly named assembly, you have for better terms a weakly named assembly.  And with weakly named assemblies there is no enforcement of the version, just the library name.  So this makes it possible for developers to update a referenced library without actually recompiling the original library that referenced it.  This is very powerful in the right hands, and pretty much what makes services like NuGet function with so many intermingling of references between projects.

So once you understand that and it has sort of sunk in.  Now consider what kind of monkey wrench would be thrown in to the NuGet references process if libraries were strongly signed.  Now consider the project that is strongly named is also the 5th most popular project on NuGet with over 125,000 downloads and is one of if not the most interreferenced library in NuGet.  That is a monkey wrench of epic proportions that can cause some real damage isn’t it.

Well you have probably guessed that this isn’t some hypothetical problem by the name of my post. This is an actual problem in NuGet and is causing the community great pains against the ever popular and wonderful library called JSON.NET by James Newton-King. You all have probably heard of it and used it in the past, here is a brief description of it if you haven’t:

Json.NET is a popular high-performance JSON framework for .NET

Features

• Flexible JSON serializer for converting between .NET objects and JSON
• LINQ to JSON for manually reading and writing JSON
• High performance, faster than .NET’s built-in JSON serializers
• Write indented, easy to read JSON
• Convert JSON to and from XML
• Supports .NET 2, .NET 3.5, .NET 4, Silverlight, Windows Phone and Windows 8 Metro.

Now that you understand the scope of the problem and the library involved, consider the fact that the ASP.NET Web Stack is also going to be using this library, so every developer that is going to be using ASP.NET MVC, Web API, or Web Pages is going to be taking on a reference to JSON.NET in the next release of the framework.

I hope you are starting to realize the boondoggle that is being created here.  Because there are some popular libraries that are slow to update because of their development cycles and the maintainers can’t jump on every JSON.NET release every month, and sometimes daily as happened in January 2012.

These monthly releases create undue pressure on the community as a whole especially when this library is one of the most referenced libraries on NuGet. And with the ASP.NET and many other teams in Microsoft moving to NuGet as distribution model, this problem is only going to get worse. And what are the chances that Microsoft is going to want to update the ASP.NET framework monthly and sometimes daily, based on James continuous release cycles.

Don’t get me wrong, I love it when developers are constantly updating their libraries, but because of the scope of JSON.NET’s use, it is creating a burden on the ecosystem as a whole. I am not advocating that James stop updating JSON.NET monthly and daily if he sees fit, what I am advocating is dropping the strong naming of libraries pushed to NuGet. That is why I am writing this blog post and that is why I am hoping you will support me and my effort to get James to stop signing NuGet assemblies.

Please support me and the community as a whole by voting up this request for JSON.NET to stop being signed on NuGet assemblies.

Work Item 22458 : Don’t Strong Name NuGet Assemblies

All that you have to do if you support this effort is to click the vote button on the work item. And leave a comment of support if you have anything to add to what I have said.

Thanks for the help and support.

We just released our 5th episode in which we talked with Brad Wilson of Microsoft about his work on the ASP.NET MVC and Web API team now commonly referred to as the ASP.NET Web Stack team.  Our conversation started with us focusing on Microsoft’s major announcement that happened last week regarding the open sourcing and accepting public contributions to the ASP.NET Web Stack. The announcement surrounded the fact that were going to make the process of developing the web stack open source, under the Apache open source license, instead of just releasing the source at major release points like they have done in the past. The difference may be lost on some people, but this means the direction of the framework is now influenced by the community instead of just a select few Microsoft employees and ASPInsiders.

Brad talked to us about what drove this decision with in Microsoft and some of the hurdles they had to over come legally and technically in order to allow people to contribute this source code. I think we are the first podcast to actually talk with a team member on the Web Stack team after the announcement was made, so that was pretty exciting for us. Even I got in on the action and contributed a small patch to ASP.NET MVC that has bugged me since ASP.NET MVC 2.

The patch can be seen here:

And the announcement of the accept request can be seen here by Marcin Dobosz:

After talking about the open sourcing of the Web Stack we dove in to the new ASP.NET Web API, which is a “newish” technology. The Web API was previously known as WCF, but it has been refactored and modernized into what is now called ASP.NET Web API.  The Web API has been designed to be first stop and best framework for creating web based API’s using a RESTful style. We had many questions relating to this new framework and Brad was able to answer them all and gave us many technical details about the design and process that the new Web API adheres to. Listening to Brad talk about the technology behind Web API is going to be very helpful for any .NET RESTful developers out there that will be starting new project soon, so if you have the time I highly recommend this podcast.

This podcast can be downloaded from our episode 5 page. If you’re interested to follow the Mash This Podcast, you can subscribe to our RSS feed or Apple iTunes.