Comments by tgrt (Top 27 by date)

Thank you. I agree the design might be a bit smelly, but then again this was just a manufactured example to illustrate the point. I'll give the OP the benefit of the doubt.

Make sure the assembly is in the discovery path first. Next use the assembly binding log viewer (fuslogvw.exe) to determine exactly what is happening.

Here's the help topic that talks about using it: http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx

Thank you!

What is the inner exception?

That error should have an inner exception, and it usually gives you the answer. I'm guessing the problem is that you're asking it to deserialize the root element CRMMessage, but the actual root is the pre.

I would, but then it would just get downvoted. I think he's saying that the XML will always return one row, but the problem is that he doesn't know how to deserialize the XML.

The XML you provided only has one row (id 168209). So always having one row is the correct behavior.

You need to catch the unhandled exception that is being reported, so that you can get more information.

Thanks Bill.

You're welcome.

You can name the Execute method anything you want. That is, your command instantiation can be: AddUserCommand = new DelegateCommand(AddUser, CanAddUser);

In that case, you'd have two methods with the same signature as Execute and CanExecute currently have.

The only reason to use a parameter in your scenario is if you want poor maintainability. In other words, there's no good reason to do it that way.

You can also pass in lambdas to the instantiation if you have encapsulated an object that handles this type of stuff. For example:

AddUserCommand = new DelegateCommand(parm => userManager.AddUser(), parm => userManager.CanAddUser);

The following site has a good implementation of the DelegateCommand if you're not using Prism. http://blog.rdeverett.com/post/812093504/wpf-delegatecommand

See solution below.

Is that all your code? Because, I don't see where your command is being created. You have a property, but you're not setting it. You're binding to that property which is a null reference... So I'm not sure what you're expecting.

Tables usually have more than one column. Your query is asking for the column names for a specific table. So the question is, what column do you want?

I didn't realize you were using the System.Windows.Forms.Timer. It executes on the UI thread. You stated in your original post "...dataTable that's updated from a workerThread", so I surmised that you were doing all of your updates from a worker thread. I would more highly recommend doing something about the inefficient looping through the rows, because of the fact it's running on the UI thread.

I don't know what the overall picture of your solution is, but you could consider the events the DataTable exposes for adding and changing rows.

The key thing is that the DataTable is not thread-safe for write operations. That means any cross-thread write behavior is undefined. You're not performing any synchronization between your two write operations (one adding and one reading/changing).

Race conditions come up in unexpected ways. The sure bet that it can happen is when you perform operations on different threads that work on the same data.

I hate to break this to you, but you're never going to be a software engineer. You don't have the boldness to go out and figure things out. All you want is the answer. You also have a bad attitude. No one is going to help you once they figure that out.

That article I linked in the solution tells you what you need to do to implement a custom application settings class.

I'll try to answer any specific question you might have, but I'm not writing code for you.

Much nicer approach to the OP than my solution. :)