Error Readout:
1st Error:
this class is not key value coding-compliant for the key managedObjectContext

2nd Error:
NSImageCell's object value must be an NSImage

Fix:
1st Error:
There is one prominent reason you could get this answer. You didn't spell your property correctly when you were binding it to....well....whatever you want to bind it to, in my case it was an Array Controller.

My problem however had nothing to do with this. When I created a new project after I upgraded to xCode 3.2 I forgot to check one very import checkbox, Create document-based application (Note: it was not a check box in older version of xCode it was a full icon selection upon creating a project). By not checking this I created a big variety of problems for myself. One of the errors occurring when I didn't check the Create document-based application, was the error this class is not key value coding-compliant for the key managedObjectContext.

2nd Error:
This error is very clear in it's issue. I was creating an entity with a property of native type binary and the compiler wanted NSImage. Grrr but I should be able to pass an image as a binary object, I would say to myself as I had urges to break my laptop and anything else in reach over my knee. My fix again was to simply create a project and remember to click Create document-based application. I know this is not your typical fix, but in case someone else runs into this issue the same way I did I hope they find this and it will be a quick and easy resolution.

Explanation:
All of this pain could have been resolved from the very beginning had I known to click Create document-based application. It was a silly little mistake that cost me a few hours. In my defense however I was under the impression of not checking Create document-based because in Hillegass's book he states that for this exercise we will not be using NSDocument, but NSPersistentDocument instead. It turns out this still means you have to check Create document-based application.

I will state that I should have known something was wrong when I didn't have a MyDocument.xib in the Resource folder after I created the project.

I've attached an image, mainly because blog posts are more fun when there is an image, but also because it shows where this one simple little check box changed my life for a hot minute.

Error Readout:
HTTP Error 404 - File Not Found
HTTP Error 404- File or Directory not found

Fix:
Enable a Pre-existing Web Service Extension in IIS 6.0

To permit IIS to serve content that requires a specific ISAPI or CGI extension that is already listed in the Web service extensions list, follow these steps:

1. Open IIS Manager, expand the master server node (that is, the Servername node), and then select the Web service extensions node.
2. In the right pane of IIS Manager, right-click the extension that you want to enable. In this example, this is Active Server Pages.
3. Click to select the Allow check box.

Microsoft Link: http://support.microsoft.com/kb/315122

Explanation:
Apparently there was no easy Google search for this stupidly easy fix. (UPDATE: I'm wrong Google the title of this blog entry and a Microsoft fix is the first result) Consequently, I spent more time than I would like on trying to fix it.

Here is how it went down. I recive a HTTP Error 404 - File Not Found error on a page I was browsing to from IIS 6.0. How could this be I ask myself, the page does exists, I know because I see it in IIS 6.0, I right click the file and I select browse. WTF. Upon a little investigation I found out what was wrong and I found a Microsoft website furthers my fix. Soooo  easy! Anyways moving on, going to go drink a beer and forget this time was lost in which I will never get back.

Error Readout:
unable to read unknown load command 0x80000022

Fix:
Upgrade to xCode 3.2 with the 10.6 libraries.

Explanation:
This error doesn't do anything to your application except provide some really annoying output to your Debugger Console. File under annoying. You can get xCode 3.2 DOWNLOAD HERE for free at the apple website. It will require you to create a login.

Snow Leopard has only been out since Friday, but a few people got the OS upgrade early and blogged all the good stuff. Knowing this, I'm still going to blog about the new OS from Apple.

Error Readout:
Exception: System.Web.HttpException
Message: Authentication of viewstate failed.  1) If this is a cluster, edit configuration so all servers use the same validationKey and validation algorithm.  AutoGenerate cannot be used in a cluster.  2) Viewstate can only be posted back to the same page.  3) The viewstate for this page might be corrupted.
Source: System.Web
   at System.Web.UI.LosFormatter.Deserialize(String input)
   at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()


Fix:
I encountered the above error the other day. Since the server wasn't on a web farm I was a little confused. The fix I ended up using was updating the web.config key to

requiressl=true


Explanation:
The next thing I asked myself was how can that key affect the viewstate. With some serious investigation into viewstate and best practices I finally made the link of how our applications viewstate is tied to session state which is tied to SSL when the session cookies are encrypted manually, a step (encrypting our own session cookies manually) we did because we are still running asp.net 1.1.

In .net 1.1 there is a property called "ViewStateUserKey" located in the viewstate, this key adds user-specific information to the view state. When the request is processed, ASP.NET extracts the key from the view state and compares it against the ViewStateUserKey of the running page. If the two match, the request is considered legitimate; otherwise an exception is thrown. In our application we use the Session.SessionID to set the property. This is where my problem starts.

When a user fills out a form utilizing viewstate to create an account to login to our system the user establishes a viewstate in their asp.net page.  In order to make the view state slightly more secure we give the viewstateuserkey the same value as the session ID. The session ID is a much better fit because a session ID is unpredictable, times out, and varies on a per-user basis
[http://msdn.microsoft.com/en-us/library/ms972969.aspx]

Once the user has completely filled out the form, we authenticate them.  This is where my error occurs [See beginning of post].


The error is caused because the session id is now encrypted. It's encrypted because our security team said, all information stored in cookies is to be secured. Our team consequently set up a flag in the global.asax file that states if this flag is set to true it should grab the session id out of each cookie and encrypt it. The reason we did this by hand is because asp.net 1.1 does not offer secure cookies with one easy key change in the web.config [NOTE: In asp.net 2.0 all you have to do is have the requiressl=true and you are done].

Now understanding that our session ID is tied to our viewstateuserkey you can understand the viewstateuserkey is now invalid because the session ID is a different value, simply because it's encrypted and the server does not know to decrypt it.  [NOTE: The session ID may still be the same value, it's just encrypted.] Now asp.net states the viewstateuserkey is invalid and pumps out the error you have seen above.

To fix this I simply change requiressl=true in the web.config.  How does requrie ssl affect an encrypted session id within a cookie that I set to encrypt? Well, when requiressl is not on but you are sending the server a secure cookie value, which we did since we created our own secure cookies in asp.net 1.1  the server doesn't know to decrypt the cookie because requiressl is not turned on [apparently you have to send secure cookies over ssl in asp.net 1.1 and possibly other run times, I didn't know this] which in turn invalidates the viewstateuserkey because the viewstateuserkey uses the session ID which is encrypted in the secure cookie.

What made this confusing for me is the first part of the form worked without a hitch. It's when the user authenticates when the error arose. The reason for this being that the requiressl key is not applicable until authentication happens. If you'll notice the requiressl key is nested in the authentication element in the web.config file.  Additionally we don't encrypt the cookie until the user is authenticated.  Sooo, the first few postbacks for our page were just collecting information.  It wasn't until we authenticated the user to our system that requiressl actually cared if we had secure cookies or not.


Overview
Viewstateuserkey is set to the session ID.

Session ID is encrypted and the updated value is set to the viewstateuserkey

requressl being turned on tells the server to decrypt session id in which case allows the viewstateuserkey to remain valid with the server.