How Do I Sign Up

You can signup here: http://phillydotnet20120531.eventbrite.com/

The Event

May 31	Scott Hanselman: The Future of ASP.NET
Thursday Blue Bell, PA	This special meeting will be held at the Montgomery County Community College Science Center Auditorium in Blue Bell, PA on Thursday, May 31 from 6:30-9:00.We have some great meetings lined up for the next few months. Please take a look at the upcoming schedule on the web site and follow other local user groups on our community calendar.
6:30	Scott Hanselman, Microsoft The Future of ASP.NET 8
	Spend a night with Scott and learn about the future of ASP.NET.Scott Hanselman works for Microsoft as Principal Community Architect for Web Platform and Tools, aiming to spread the good word about developing software, most often on the Microsoft stack. Before this he was the Chief Architect at Corillian Corporation, now a part of Checkfree, for 6+ years and before that he was a Principal Consultant at STEP Technology for nearly 7 years. He was also involved in a few things Microsoft-related like the MVP and RD programs and will speak about computers (and other passions) whenever someone will listen to him. He’s written in a few books, most recently with Bill Evjen and Devin Rader on Professional ASP.NET. He blogs athttp://www.hanselman.com for the last 10 years and podcasts weekly at http://www.hanselminutes.com and http://www.thisdeveloperslife.com.We are pleased to have Apprenda Software as our sponsor for this event:Apprenda is an Open Platform-as-a-Service (PaaS) stack for .NET that enables any organization to transform their existing infrastructure into a self-service cloud application platform. By decoupling applications from infrastructure and Developers from IT, Apprenda empowers organizations to achieve significant cost savings and massive productivity improvements that result in better business/IT alignment. Come enjoy the company of the best geeks in the Delaware Valley!
9:00	Books, software, and other goodies!

As I was developing my first Metro App today I came upon this weird error.

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.

Similar to the situation I previously posted about in my last blog entry on ZLIB Compression in .NET. I needed to support a byte array coming from Java’s BigDecimal type.

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.