Saturday, January 4, 2014

Windows Phone 7.1 SDK Issues - MonoGame Requirements

I've had massive trouble, recently.  My primary hard drive failed, and then the replacement failed within twelve hours.  Long story short, I needed to rebuild my system's software from the ground up.

Since I've migrated my pet projects to MonoGame, I had some issues trying to get things setup again.  In particular, I kept trying to install the Windows Phone 7.1 SDK due to a dependency on it being needed for MonoGame.

When that occurred, I had the following error when installing (shown in the Error Log):

Windows Phone Emulator x64: *** ERRORLOG EVENT ***: Error: Installation failed for component Windows Phone Emulator x64. MSI returned error code 1603

Very specific, right?  Not.

So, what I ended up doing was downloading the offline installer for Windows Phone 7.1 SDK and navigating to what was important and what I *really* needed -- XNA.  The normal XNA you install apparently won't get the job done.

If you navigate off of the ISO for WP7.1SDK, you'll see a folder structure...

\WCU\WindowsPhone

Inside that, the relevant XNA installer is listed as XNAGS40_Setup.exe.  That's the dependency that MonoGame actually has.

Solved this error fairly quickly:

Error 1 Error loading pipeline assembly "MonoGameContentProcessors, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null".

Now, back to finally doing some development!

Wednesday, November 27, 2013

Use TitleContainer instead of ContentManager for MonoGame for Custom Content Pipeline Processing

So, I've been playing with MonoGame recently and one of the biggest challenges I've had is trying to figure out just how in the world I want to import content.  Especially custom content.

Typically, you load content using the ContentManager.Load<ContentType>(somePathHere) -- but what if I want to manually de/serialize things?  A lot of folks say, "Write a custom content pipeline to handle it."

Problem is -- that's reinventing the wheel.  I already have de/serialization methods.  I know how things are formatted.  The thing that I want now, is to load my content through this without having to do crazy additional content pipeline steps...

After some digging, I found that that you can use the...

Microsoft.Xna.Framework.TitleContainer.OpenStream(somePathHere) method to get you a stream to your content.  There are some caveats -- you will probably still have to build your items into a content project of some sort.  For Windows builds, this is pretty easy, since it's just a matter of dropping files over.  On Android, you apparently have to mark items to be built as an asset.  I haven't looked too deeply into any other platforms than Windows and Android, but I imagine Linux and Mac behave the same as Windows, leaving iOS as the only other weird question.

That being said, I'm going to be abstracting my code into this kind of a pattern (service), so I can manage the content pipeline myself.  I like the idea of being able to manage my own memory without all the extra details.  I'll also be using the Texture2D.FromStream method in conjunction with this, so I can grab my tiles, etc.

Hope that helps some folks!

Tuesday, September 24, 2013

ClickOnce Woes with VSTO's

So, I'm trying to redeploy a VSTO application and I get the following beautiful, beautiful, beautiful error...

Unable to install this application because an application with the same identity is already installed. To install this application, either modify the manifest version for this application or uninstall the preexisting application.

It's frustrating, because I know it has been uninstalled and everything is fine.  Registry doesn't even show it deployed.  Commence "tearing out my hair" mode.

And then, I found the problem.  Apparently, VSTO's can sometimes screw up the ClickOnce cache.  Awesome!  So, that being said, if you run this from the command line (and it's very fast, so don't freak out and think nothing popped up/succeeded) all will be better:

rundll32 dfshim CleanOnlineAppCache

And thus, order and balance was restored to the universe again... for a short time.

Wednesday, September 11, 2013

MSB3326 "Cannot import the following key file: ."

Due to restrictions, I'm limited in some of the things I'm allowed to post, so these updates will be less frequent than before... which isn't saying too much.

In any case, I bumped into a new problem: MSB3326 "Cannot import the following key file: ."

Where is the key file?  Why is it blank?  I know I'd deployed the key and everything was fine prior, so what was the big deal?

What this means is that it cannot access the key file -- maybe you're like me and have to use an alternative administrative account for building and keys and the like.  So, I had to manually open certmgr.msc as the same administrator that was building the project.

After that -- all was pie in the sky.  Things work, life is good, and finally there is an answer to this horrific question.

Tuesday, February 5, 2013

Windows 8 and Windows Server 2012 Hiccups


So, I recently was trying to put together a copy of SharePoint 2013 on Windows Server 2012, on a box that came with Windows 8.  My initial hope was to build a VHD and just have it capable of being transported around easily, but this caused issues.

The more I played with it, the harder it was to get Windows Server 2012 to install at all!  All sorts of trips through bcdedit and bcdboot were fruitless.  So were my attempts at using an easier editor on top.

Even throwing a simple partition on is difficult to install to.  The end result was that I had to go back to the tried and true method -- dump the install to a bootable flash drive.  After doing this, everything went peachy.

For anyone else having issues, this is the only way I was capable of dual-booting Windows 8 and Windows Server 2012, after playing with it in the evenings for a couple of weeks.  

Wednesday, January 16, 2013

SetResourceReference is the Awesome-Sauce for Styling

One of the biggest issues I've had with developing custom views is that there are so many different ways to implement your styling and linkage.  The best way I've found is just to call the following in the constructor:


SetResourceReference(StyleProperty, typeof(MyControl));

Wherein MyControl is the control you're working with.

A lot of people work with the default style key -- but I've found that in larger projects, there can sometimes be issues with this.  Using SetResourceReference has worked for me every single time.

Food for thought!

Monday, January 7, 2013

The type or namespace cannot be found... C# and the Client Profile woes

So, this is a very funny and unusual error I bumped into today -- and it drove me mad for a few hours.

When I build components, I generally like to abstract them out into a little test-bed WPF application.  Every time I kept compiling, it would blow up on a simple, new component I had just added, with a message looking like...

"The type or namespace '{0}' cannot be found."

When I did try to resolve it -- it pointed out a flaw in our architecture, wherein some numb-skull decided to rename a namespace in one assembly to that of another.  After I fixed that, I found that it was STILL not the problem.

Then I looked again -- for whatever I could find -- in my test-bed's properties.

It was set to run in .NET 4.0 Client Profile.  When I changed it back to .NET 4.0, everything compiled and worked fine.

In the future, I need to double check these things -- hopefully someone else will read this post and later figure this out as well!

Tuesday, October 2, 2012

Saving JPEG Metadata the FIRST Time with WPF

So, I've been seeing a bunch of problems at StackOverflow and bumped into this new problem at work...  Turns out that setting the EXIF metadata on an image is EXTREMELY difficult.  Most solutions involve first saving the image and then opening it back up...

Of course, I couldn't just "accept" that.  Unfortunately, the work-around is a bit of a hack, but it does work reliably!

So, in the following example, assume that I have a RenderTargetBitmap from WPF...

                    JpegBitmapEncoder imageEncoder = new JpegBitmapEncoder { QualityLevel = 100 };
                    imageEncoder.Frames.Add(BitmapFrame.Create(renderTarget));

                    using (MemoryStream memoryStream = new MemoryStream())
                    {
                        imageEncoder.Save(memoryStream);
                        memoryStream.Position = 0;

                        JpegBitmapDecoder decoder = new JpegBitmapDecoder(memoryStream, BitmapCreateOptions.None, BitmapCacheOption.Default);
                        BitmapFrame frame = decoder.Frames[0];
                        BitmapMetadata metadata = (BitmapMetadata) frame.Metadata.Clone();

                        metadata.Subject = "This is a test subject.";
                        metadata.Title = "This is a test title.";
                        metadata.Comment = "This is a test comment.";

                        imageEncoder = new JpegBitmapEncoder() { QualityLevel = 100 };
                        imageEncoder.Frames.Add(BitmapFrame.Create((BitmapSource)frame, (BitmapSource)frame.Thumbnail, metadata, frame.ColorContexts));

                        using (var fileStream = new FileStream(saveFileDialog.FileName, FileMode.Create))
                        {
                            imageEncoder.Save(fileStream);
                        }
                    }

This is, of course, a hack -- it saves the image to the memory stream and then is capable of creating a "good" metadata object (normally, this blows up in your face if you try to send one in that you created on the fly).

Now, you can set it up however you like -- go nuts!

Tuesday, August 7, 2012

3D Programming and Calculating Normals

So, I've had a really difficult time with calculating normal vectors (herein referred to as "normals") in OpenGL, and I've learned a lot to make sense of it, finally.  There are a few good tutorials, but they still don't explain everything you want to know.  So, I've decided to post about how they work and how to build them.

A normal is a vector that describes a direction perpendicular (pointing away) to a point (i.e. a vertex) or a face (i.e. a polygon).  It is important for lighting, since light needs to know how to reflect off of something.  I always figured lighting should be able to figure this out -- I mean, why shouldn't it?  However, that's another topic entirely.

Vertex and face normals serve their purposes.  For example, streamlined terrain generally looks better with vertex normals.  Since OpenGL blends the colors (and therefore lighting) between each point, you'll see a gradient between all vertices of your polygon with normals.  A face normal will basically have one normal for a vertex be applied to all vertices in the polygon, so the polygon as a whole will be flat with its lighting and uniformly lit/shaded.  This looks great for something like a cube where you'll want clear lines separating the object faces.  This looks really terrible on terrain.

For the sake of this tutorial, I'm going to explain how to calculate a face normal.  Since all polygons are composed of triangles, I will be using a triangle for our face.  You can calculate a face normal by averaging all of the normals in a complex polygon together (using a geometric average is the ideal way, but sometimes slow).


So, suppose we have a triangle with vertices A, B, and C.

We need to calculate the individual vectors and multiply them together.  Please note that you need to observe the right-hand rule when calculating the normals, such that you need to always build normals or vertices in the same order.  For example, in my example above, ABC is built counter-clockwise, from A to B to C.  Some people build their triangles in a format where the vertices A, B, C are the upper left corner, upper right corner, and then the lower left corner (whereas mine are upper left corner, lower left corner, and lower right corner, respectfully).  In the alternate case, it would built clockwise.  However, there are a number of ways to build a triangle -- just make sure you either build them all clockwise or counter-clockwise.  Make sure that each triangle is calculated in the same order as the prior.

From here, we need to calculate the vector of each component.  We use the middle vertex of a triangle (again, this can change based on how you build your triangles).  For my version, it is "B."  So, we want to calculate the vector of each direction around this "pivot" vertex.

Simply put, we will have two vectors, U and V, which will be built as follows:

U = B - A
V = C - B

To do vector addition and subtraction, we just add/subtract the components, so simply put...

method AddVectors( Vertex A, Vertex B )
{
  create Vector where Vector.X = A.X + B.X, Vector.Y = A.Y + B.Y, Vector.Z = A.Z + B.Z;
}

Now that we have U and V, we'll have to multiply the two vectors together... which is a bit more painful.

method MultiplyVectors( Vector U, Vector V )
{
  create MultipliedVector;
  MultipliedVector.X = ( ( U.Y x V.Z ) - ( U.Z x V.Y ) );
  MultipliedVector.Y = ( ( U.Z x V.X ) - ( U.X x V.Z ) );
  MultipliedVector.Z = ( ( U.X x V.Y ) - ( U.Y x V.X ) );
}

Aren't you glad we used vector names U and V, instead of X and Y?  That code would be impossible to read!

Now, you have a "normal" of the face of the triangle -- but you're STILL not done.  The normal should be normalized to a unit length.  If you want to calculate a vertex normal, you may save this operation until after you're finished calculating all of your face normals.

To normalize a vertex, you need to find the unit length, which is done with Pythagorean's theorem.

The unit length is built as follows with a vector T:

UnitLength = SquareRoot( ( T.X x T.X ) + ( T.Y x T.Y ) + ( T.Z x T.Z ) );

Then, divide each component of the normal by the unit length as follows:

T.X = T.X / UnitLength;
T.Y = T.Y / UnitLength;
T.Z = T.Z / UnitLength;

You have now "normalized" your normal.

But wait, there's more!  We really wanted to get the vertex normals!

We can calculate a vertex normal by adding all of the face normals that a vertex is used in and then performing the normalization we did prior after.

Suppose we use a data structure (I have a persistent Dictionary<int, Dictionary<int, Vertex>> object I use) that contains all of the vertices of a mesh by their X, Y values.  X, Y would refer to the X and Y coordinates of the triangle mesh, which in my case (and many others) are generally uniform distance from each other (i.e. always 1 unit away from the other).

Assume my earlier triangle now has another point directly above C, called D.  We now have a quadrangle.


Assume my format has several of these next to each other to make a surface of terrain or something else.  Assume that these share points, such that D and C become the next A and B vertices for a quad that would have an E and F added on.  (i.e. quad one is built with A, B, C, D; quad two is built with D, C, E, F)

Assume also, I can calculate a face normal by providing three vertices of a triangle with the method CalculateNormal.  This would utilize the same pseudo-code mentioned above.

I could loop through a mesh as follows:

normals = create Dictionary[int][int] containing Vector;

for( y = 0; y < mesh.Height - 1; y++ )
{
  for( x = 0; x < mesh.Width - 1; x++ )
  {
    //Triangle ABC
    Vector normal = CalculateNormal( mesh[x][y], mesh[x][y + 1], mesh[x + 1][y + 1] );
    
    //Add the normal components to the vertices that are used
    normals[x][y] += normal;
    normals[x][y + 1] += normal;
    normals[x + 1][y + 1] += normal;

    //Triangle ACD
    normal = CalculateNormal( mesh[x][y], mesh[x + 1][y + 1], mesh[X + 1][y] );

    //Add the normal components to the vertices that are used
    normals[x][y] += normal;
    normals[x + 1][y + 1] += normal;
    normals[x + 1][y] += normal;
  }
}
At this point I would have all of my normals added up, but they'd be huge and non-normalized.  So, we'd normalize them by calculating the unit length as I did for a face normal, and then finally dividing the components by that unit length.

That, my friends, is how you would go about building normals from a uniform mesh with differing heights.

References:

Tuesday, July 10, 2012

JSON and the Null Character

I've been working with WebSockets lately and have been attempting at porting them across various applications.  Well, everything has been fine and dandy, until I bothered to get to the HTML5 version of our application (or rather, the future of it).

For some reason, I kept getting "invalid_token" or "invalid token" with no trace of any other information.

Turns out, C# and the WebSocket were appending \0 at the end of the data.  D'oh!

The simple fix for this (when you're having issues with JSON.parse) is to change your code from:


var jsonObject = JSON.parse(jsonEncodedString);

to

var jsonObject = JSON.parse(jsonEncodedString.replace(/\0/g, ""));

With that, your code should hopefully work!  If not, there's always http://jsonlint.com/ to attempt to validate your JSON.

Wednesday, May 23, 2012

The Amazing EventProxy

Recently at work (as these posts usually come), I've been tasked with handling loading our entire framework (after downloading it from a remote source), and executing everything in a way that let's us administrate it.  I've been delving into the entire AppDomain paradigm which was plenty fun to deal with in the 70-536, but I haven't really touched it (or read on it) in about five years.

That being said, when working with AppDomain's, you have to make sure that the objects you're using can remote across to other AppDomain's correctly -- and by doing so, the easiest method is generally to derive the classes in the calls from MarshalByRefObject.  Pretty easy, huh?  Almost.

There is one caveat to this -- if you want to access an event on your cross-domain object, it requires your class to be Serializable or also be derived from MarshalByRefObject.  Still pretty simple, right?  Mostly -- but what if you have a control or user interface element that is already derived from something else?  Something that shouldn't be serialized at all...  In my case, it is a ViewModel.

After much deliberation, the smartest idea was to create a proxy -- pretty cool and easy, right?  Almost.  The only problem is that if I hard-coded the proxy, we'd be stuck with constantly updating the proxy for each and every object.  Some of our calls are just a simple EventHandler<EventArgs>, but some of our calls are more complicated EventHandler<MakesYourMindExplodeFromAnotherAppDomainEventArgs>.  How could I possibly allow this level of flexibility...?

Enter, the EventProxy:

    public class EventProxy<T, Args> : MarshalByRefObject
        where Args : EventArgs
    {
        public event EventHandler<Args> EventOccurred;

        public EventProxy(T instance, string eventName)
        {
            EventInfo eventOccurred = typeof(T).GetEvent(eventName);
            if (eventOccurred != null)
            {
                MethodInfo onEventOccurred = this.GetType().GetMethod("OnEventOccurred", BindingFlags.NonPublic | BindingFlags.Instance);

                Delegate handler = Delegate.CreateDelegate(eventOccurred.EventHandlerType, this, onEventOccurred);

                eventOccurred.AddEventHandler(instance, handler);
            }
        }

        private void OnEventOccurred(object sender, Args e)
        {
            if (EventOccurred != null)
                EventOccurred.Invoke(sender, e);
        }
    }

It is incredibly simple.

It's also important to note that this needs to be an assembly that both AppDomains reference.

For my ViewModel's, I'm adding it as such:

   EventProxy<CrossDomainObject, EventArgs<string>> Proxy = new EventProxy<CrossDomainObject, EventArgs<string>>(MyCrossDomainObject, "StatusUpdated");
   Proxy.EventOccurred += (sender, e) => { Status = e.Value };

In this example, CrossDomainObject is my CrossDomainObject class, wherein MyCrossDomainObject is the instance of that class.  The EventArgs<string> is a generic EventArgs that takes a string.  From there, I just update my status in the ViewModel, without any issues of the SerializationException.

There are a few safe-guards that would help make sure the EventProxy doesn't blow up and Exception out to hell, but it's a good start for someone to build on top of.

Thursday, May 17, 2012

DependencyProperty vs. INotifyPropertyChanged

I've been developing UI components for work and I've noticed a lot of shift and use between DependencyProperty and implementing the INotifyPropertyChanged interface.  When and why do we use this? 

The simplest answer is that DependencyProperty is a lot more heavyweight than INotifyPropertyChanged.  Primarily, you'll see DependencyProperty much more useful for UI components and binding, rather than on the ViewModel.  Why is this?

Simply put, implementing INotifyPropertyChanged will not allow you to style or template your control off the bat.  While there are other ways to get around this, it's a bit more of a pain and why make your life painful when you can make it simple and easy?

DependencyProperty, on the other hand, will allow you to do just that.  If you implement a Gauge control, for example, and then have it so that a specific element on the Gauge has a certain color, you won't be able to put a global style on this with INotifyPropertyChanged.  DependencyProperty will register it immediately and you're good to go.

I think it really boils down to two cases.

  1. For UI control development and tight-coupling, use DependencyProperty.
  2. For everything else (when serialization is necessary) use INotifyPropertyChanged.
That being said, there is one caveat -- writing the DependencyProperty in a ViewModel is a hell of a lot easier and quicker for updating things.  Using the "propdp" snippet in Visual Studio makes coding them a breeze.

Wednesday, April 18, 2012

OpenGL Picking with the Tao Framework

Disclaimer: This is an old post, which I am migrating from my old blog, for the sake of preserving it.  It originally was posted on June, 30, 2008.
I’ve been playing around with the Tao Framework quite a bit, and I found that I had serious issues trying to figure out how to do “picking” or “selecting.” My goal was to create a 3D isometric tile map-editor (in short, a tilted-perspective map editor for a game).

There’s always the option of “drawing” under selection rendering mode — but this is ugly and complex, and didn’t work very good. The real trick that did the job, was to actually use GLUT (OpenGL’s Utility Library) to find a pixel and read the depth buffer (which had been set after the prior scene was rendered) and determine the spatial coordinates. In C++, this is an easy task, but in C#, this is a little more complex, since the Tao developers lurk in the dark at night and seldom come out into the light of day to write a tutorial or two. So, I’ve managed to figure out (after a month, tearing out of hair, and nearly a bit of seppuku tossed in the mix) how to properly do “Picking” in GL. I’m very pleased with the results, as should the Gods of GL (who roam the interweb and all GPUs).
//Variable Declaration
double Output_X, Output_Y, Output_Z;
double[] ModelviewMatrix = new double[16];
double[] ProjectionMatrix = new double[16];
int[] Viewport = new int[4];
float[] Pixels = new float[1];
//Used for some of the messy pointer work.
IntPtr PixelPtr = System.Runtime.InteropServices.Marshal.AllocHGlobal( sizeof( float ) );
//Grab Information about the Scene in OpenGL
Gl.glGetDoublev( Gl.GL_MODELVIEW_MATRIX, ModelviewMatrix );
Gl.glGetDoublev( Gl.GL_PROJECTION_MATRIX, ProjectionMatrix );
Gl.glGetIntegerv( Gl.GL_VIEWPORT, Viewport );
//Find the Depth and store it in a conventional manner with C# in mind
Gl.glReadPixels( e.X, Viewport[3] - e.Y, 1, 1, Gl.GL_DEPTH_COMPONENT, Gl.GL_FLOAT, PixelPtr );
System.Runtime.InteropServices.Marshal.Copy( PixelPtr, Pixels, 0, 1 );
System.Runtime.InteropServices.Marshal.FreeHGlobal( PixelPtr ); //yes, free the memory
//Finally grab the actual X, Y, and Z from all the data we have
Glu.gluUnProject( (double) e.X, (double) ( Viewport[3] - e.Y ), (double) Pixels[0], ModelviewMatrix, ProjectionMatrix, Viewport, out Output_X, out Output_Y, out Output_Z );
Let’s dissect this a little.

Each matrix in GL is a 4×4 matrix, so I initialize the storage for the matrices as a 16-length double array. The viewport is quite simply, just four variables, but we want to store them all in one continuous array, so that’s why the Viewport is stored as a 4-length integer array. And finally, the Pixels array is necessary for C# and it’s weirdness with typecasting code. This code is all technically “safe” because of how I use the Marshal InterOp code (also note the fact that I built a PixelPtr to associate Pixels to a pointer).

The next 3 methods grab all of the data necessary to the matrices for projection, etc, and the display settings. Pretty simple and straight-forward.

Now, we need to figure out what the “depth” is at the current location. Notice that the code has literally been pulled out of a MouseMove event, so e.Y and e.X refer to the mouse’s X and Y coordinates. The depth is stored in PixelPtr. Note that to get the Y coordinate in correct terms, I subtract the Mouse Y from the size of the Viewport.

Now, I use the Marshal to copy data back over to the Pixels pointer. Very simple, but a pain-in-the-butt to figure out on your own with lack of documentation.

Finally, we make use of gluUnproject to un-project (normally we project the display) based on the data we have and determine the location of the mouse in X, Y, and Z coordinates. This is why we have that Output_X, Output_Y, and Output_Z declaration at the top.

SharePoint Warmup Script

Disclaimer: This is an old post, which I am migrating from my old blog, for the sake of preserving it.  It originally was posted on October, 14, 2008.

A colleague of mine was discussing that after an iisreset/deployment to SharePoint, it’s pretty common that one needs to refresh/warm-up all of the possible URLs that may be accessed. Since SharePoint does caching of pages and the like, we can secretly (like a ninja) ping our destination with VBScript/Windows Scripting. Sound complicated? Hardly. Even more, I’ll make it very simple for you — just copy and paste the following script (like a ninja), and then adjust it to your needs:
'
'SharePoint Warmup Script
'
'
'Create new object to ping URLs
Dim BaseURL
Dim NewURL

BaseURL = "http://my.sharePoint.installation/sites/mySiteCollection/"
NewURL = ""

Dim Ping
Set Ping = CreateObject( "Microsoft.XMLHTTP" )

'If we don't have capability to access the XML/AJAX Object, break out
if Err.Number <> 0 Then wscript.Quit
'Start attempting to open the following URLs:

'Copy/paste the code below for several different sites/subsites/collections.
'
'Base Portal Dashboard
'
NewURL = BaseURL & "" 'Enter your new extension of the main URL
wscript.Echo "Pinging: " & NewURL
Ping.Open "GET", NewURL, False
Ping.Send

Monday, February 27, 2012

ClientAccessPolicy or Bust

I won't lie -- I'm no expert, heck, even a decent Web Service developer.  I'm a novice.  If you want an awesome user experience, I'll rock your world, but I digress...

I know WCF is supposed to be pretty easy and cool to work with, so I took it upon myself to write some of our latest "service" code for a demo.  The awesome thing about WCF is that it handles all of the underlying connections and the like for you -- all you have to worry about is the actual logic.  If you want to get a little more "dirty" you can configure which channels it runs over.

So, I wrote a handy little wrapper around our service that handles callbacks, initialization of the connection, and the like.  Whenever it called it, I kept getting a "Security error."  Of course, had I not run through the entire Silverlight debug prompt where it notified me that the service and application needed to run in the same web project, I might have figured it out sooner.

Instead, I decided to make it harder on myself (and actually easier).  I added a ClientAccessPolicy.xml to the WCF service project, similar to how one is necessary for our framework.  The WCF service and application no longer need to be hosted in the same web project -- the ClientAccessPolicy allows the Silverlight client to connect without any issues.

Now, mind you, this is probably a possible point of attack for a hacker if you're not careful, so it's probably best not to do this on a production machine -- but for local development work, it sure helps!

Monday, November 14, 2011

NLog Network Target

Recently at work, I'd been tasked with utilizing NLog's targeting system to dump data into our system.  NLog itself has been working really well for us, but the downside is that the documentation leaves a lot to be desired.  Furthermore, examples and samples are extremely limited.

So, how in the world do we utilize this?

My first thought was to tear everything open in .NET Reflector (ILSpy, since I can't find a free copy of .NET Reflector anymore) and then work to understand how it works.

The targets we were most interested in were the Network and Memory targets -- such that we could grab data that was being logged and then further process it.  Why not have our complex-event processing system also process logs as well?  A self-logging system.  Hell, why not?  Also, doing what your boss asks is generally a good way to stay employed.

The Network Target


So, the network target.  It handles several different variations of address -- UDP, TCP, variations of IP4/6.

The standard attack pattern for this is actually pretty much the same as any other TCP/UDP application.  Manage your clients (if necessary) and then process the data.


The only difference is that handling the data is different.  The chart above shows the general jist.

  1. When reading from the socket, convert your incoming data to a string.
  2. Ensure that it is decoded properly -- by default, your message will be in UTF8.
  3. Store message in a buffer.
  4. Scan for end of line characters and process as necessary.
It's pretty simple.  A very simple handler would look like the following:

  string incomingMessage = UTF8Encoding.ASCII.GetString(incomingSocketBuffer, 0, incomingLength);
  incomingStringBuffer.Append(incomingMessage);
  //Process and analyze for "\r\n"

Not bad, eh?  The above code assumes that incomingSocketBuffer is what was received from the Socket's Receive method, and the incomingLength is the length of what was received.  incomingStringBuffer is a StringBuilder that I use to store up the data.

Of course, there are much better ways of handling this, but this is the most simplistic and hopefully it demystifies NLog's Network target.

Friday, September 23, 2011

Heisenbugs! Schrödinbugs! Multi-Threading Programming, Quantum Mechanics, and You!

My team leader has a saying for strange bugs popping up -- Heisenbugs.  Your code is correct.  Everything should be fine.  However, for some reason...  BOOM!  Exception.  You lose some hair.  I think a more appropriate name is Schrödinbugs, though.  They appear to be correct and if you step through them, they'll work.  However, the second you stop observing them, they always seem to have the potential for a different result.  Ahhh...  unpredictability!

This is frustrating, but I've noticed one of the biggest problems generally stems from multi-threading.  Most developers aren't tuned to developing multi-threaded applications.  Even when they are, it's just another thing to watch out for when developing code.

So, you may be writing an application in WPF.  Say, it subscribes to an asynchronous TCP socket at the application level.  You have a callback on a user control.  Is there a potential problem?

YES.

Any time you have another resource that can act of its own accord and interface with another thread (events to the user interface, for example), you have a chance of having a Schrödinbug!  For example, at work I had a strange issue -- a control would hit the end of its life-cycle.  Disposed and all was well, right?  Well, not quite.  I had a DispatcherTimer that was syncing up some things for that control.  I stopped it in Dispose -- so the timer shouldn't be called, right?

Wrong.

The timer did stop -- but it had already entered its callback on the event thread.  The thread then swapped back to handle the Dispose that I had called.  It finished the Dispose, then went back to the event callback to finish.  Surprise surprise!  The control had been disposed and threw an exception.  So, how do we get around this?

I've developed a fairly simple pattern...  using a lock and the basic Disposable pattern.  I'm attaching the basic skeleton on how to implement this in your code:


    public class MyClass : IDisposable
    {  
        private object _lock = new object();
 
        #region IDisposable Pattern
 
        private Boolean _disposed = false;
 
        private void OnEventCallback(object sender, EventArgs e)
        {
            lock(_lock)
            {
                if( _disposed)
                    return;
 
                // Handle callback here
            }
        }
 
        /// <summary>
        /// When called, throws an ObjectDisposedException if the object has been disposed.
        /// </summary>
        protected virtual void CheckDisposed()
        {
            if (_disposed)
            {
                throw new ObjectDisposedException(this.GetType().Name);
            }
        }
 
        /// <summary>
        /// Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.
        /// </summary>
        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }
 
        /// <summary>
        /// Core dispose methods
        /// </summary>
        /// <param name="disposing">True if called from IDisposable::Dispose</param>
        protected virtual void Dispose(bool disposing)
        {
            lock (_lock)
            {
                if (disposing && !_disposed)
                {
                    // Clean up managed resources here
                }
 
                _disposed = true;
            }
        }
 
        /// <summary>
        /// Releases unmanaged resources and performs other cleanup operations before the
        /// <see cref="MyClass"/> is reclaimed by garbage collection.
        /// </summary>
        ~MyClass()
        {
            Dispose(false);
        }
 
        #endregion
    }


Notice the lock around the two most important parts -- I wanted to make sure that I have critical sections on the _disposed, such that I can break out as necessary.  Notice, if it enters the thread for the callback, we're fine.  If it disposes on the other thread, we can still break out before the code hits something disposed.  Essentially, we're making textbook critical sections and managing them appropriately.

Nothing unusual or entirely special -- just adapted to be mindful of another thread.

Wednesday, September 7, 2011

Control Lifecycle Gotcha's in Silverlight

I've come acrosss some more "fun" in Silverlight.  One of the most irritating (and not very well documented) pieces involves the tear-down and destruction of your controls.  Creation of controls is pretty simple, with a few caveats.

Control Creation


When a control or page is created in Silverlight, if the child controls are not visible, they are not "created."  Rather, they are created when they become visible.  For instance, if you have a Container control of some kind (Grid, etc) that is Collapsed, all of the child controls will not be created until it becomes visible.  Given how the rendering/layout engine works in WPF and Silverlight, this kind of makes sense -- only worry about what is visible.

Control Teardown and Destruction


The Unloading event occurs in a different order.


This is the most irritating part for me, as a developer.  Primarily because it doesn't make a whole lot of sense to me and is rather different compared to other frameworks.

Let's start with what we would think should happen, normally.  Supposing you had controls each in a hierarchy of:

A is the parent of B, which is the parent of C.

You would think C gets Unloaded first, then B, then A.

It's the exact opposite.

A is Unloaded, then B, then C.

If you have something, for instance, at point B that needs to be taken care of before C, you'll have some very frustrating issues ahead of you.  For example, C may consume resources that are created in B (such as a service).  Suppose the control is closed, B will attempt to clean up its resources before C does (assuming you've built your controls cleanly).  So, if C is still trying to access the resource created at the scope of B...  C will blow up with all kinds of exceptions.

Finalizers are called upon Application exit.

Not much to be said here -- whereas WPF and WinForms call finalizers generally as soon as the references disappear, Silverlight nukes them upon Application exit.  So, if you want to free up resources, you need to do that beforehand.

In Closing

In short, writing Silverlight is a bit more complicated and doesn't handle things quite as easily as other frameworks we're used to.  However, knowing the afore mentioned, you should be able to make your code cleaner and more efficient.

Tuesday, September 6, 2011

'x' was already registered by 'y' in Silverlight and WPF

So, I've had the extreme pleasure of working with a lot of Silverlight recently -- and my code in WPF had never been tested with multiple controls (stupid me).  When I did, I got all kinds of errors about properties not being set correctly, and eventually, after commenting out enough, I received the error

"'X' was already registered by 'Y.'"

So looking deeper, I notice it always happens on the second element.  Weird.  Looking further, I notice that my DependencyProperty pattern is basically declared at a private-instance level, i.e.:
DependencyProperty TitleProperty = DependencyProperty.Register("Title", typeof(string), typeof(SomeControl), new PropertyMetadata(string.Empty));
In Silverlight, this isn't a big deal.  In WPF, it's a deal-breaker.  It appears that Silverlight can automatically handle instance-level dependency properties (or more likely, translating bad code into them).  In WPF, it's not as forgiving and needs to be prefaced by:
public static readonly 
i.e.,
public static readonly DependencyProperty TitleProperty = DependencyProperty.Register("Title", typeof(string), typeof(SomeControl), new PropertyMetadata(string.Empty));

With that, everything works again and my Silverlight code doesn't break either.

Interesting difference between WPF and Silverlight, for sure.

Tuesday, August 23, 2011

Thank you Bing Maps!

After enough crying from developers, Bing Maps has apparently *finally* released a WPF control.

I had my solution *nearly* working -- with a few bugs I was going to ask Microsoft about in relation to accessing via quad-keys and getting a tile based on latitude/longitude via their web services.  Go to the blog and ten minutes prior to me arriving, they announced the official Bing Maps control for WPF.

Rejoice, friends!  Go get it!

http://www.bing.com/community/site_blogs/b/maps/archive/2011/08/23/announcing-the-bing-maps-wpf-control.aspx