VS2005

Blogging and TechEd 2006

Stefan Barrett — Thu, 15 Jun 2006 18:54:00 GMT

When I went to TechEd, I though I would do a bit of blogging every day, but I had forgotten just how busy you can get here. There's just so much to see. While you do get the DVD's containing all the sessions (except Chalk-Talk ones), it takes at least 8 weeks and nothing beats being there.

Have got a copy of Visual Studio for Database professionals, which will be installed as soon as possible. While I'm not sure about using in production environment yet (if nothing else, it's not the finished version), the assistance it can give in development and testing means its worth looking at now.

Micorsoft needs to tidy up it's marketing regarding WCF, WPF, Link, WF, etc. when it coming to what versions it will be released in (first time I've heard of .Net 3.5). It seems that .Net 3.0 will come out with Vista, but actually .Net 3.0 is more .Net 2.0 + WCF, WPF, WF. So you still use Visual Studio 2005 to work it. Then in 2007 we get Orcas/Visual Studio 2007 with .Net 3.5 which includes Linq. But at the end of the day, apart from bug fixes, we are still talking about .Net 2.0 with extras.

Microsoft seems to have a small problem in classifying the level of some of the sessions, typically rating them slight higher than they warrent.

Having fun with VS2005, XML and partial classes.

Stefan Barrett — Fri, 28 Apr 2006 09:24:00 GMT

Currently working on a data transformation engine (yes I know you can buy things like this, but it takes less time to write it than to get the company to buy it), which involves a lot of xml. First step is to create the schema descriping the transformation which I do in VS2005. Got VS2005 to crash once (just closed down) while editing a complicated bit of schema, but unable to replicate for now. When I restarted it, it did give me a choice of recovering the schema file, but it was a 5 hour old one, however luckely I had saved everything less then 10 minutes beforehand.
Then it's a case of running xsd.exe over the file to generate the class files, using a DOS prompt (through I notice there's a custom tool property to look at later).
I then make good use of the fact that all the classes generated are partial classes, and since I'm also using inheritance (definied through the xml itself) this is getting to be quite powerful.
I then go into a different solution where I'm writing the actual xml and MDI application. I start it up, and it crashes. I look at the stack trace and notice that while I see the start of the stack trace, and the end, there's a section in the middle which I can't see. And it's were the xml generated classes would be. Of course I don't want to look at them, but since they have been extended (via partial classes), there is code I want to see there. It took me a little while to realise that VS2005 was hiding them because the 'Enable just my Code' option was checked (Tools/Options/Debugging/General). Because they were defined in another assembly, they were helpfully hidden by VS.
Ok, so I turn the option off, so I can see my code, except that I still can't see it. It turns out all the auto-generated code had a attribute on it which told VS not to show it. Which I'm sure is very usefull when using fully auto-generated code, but is a real pain if you have extended the classes via partial classes.

Serialization

Stefan Barrett — Sun, 09 Apr 2006 14:41:00 GMT

Still working on my query generator, and thought I would do the load/save logic so that I don't have to rebuild the same queries again and again during testing.
Ok, so I have a class like this:

public class FieldContainer
{
private List<BasicField> fields;

public void Load()
{}

public void Save()
{
...........
}
}

So I figured the fastest way would be to serialize it out to a xml file.
Obvious problem; what the list contains is objects which inherit from BasicField, and during serialization they can't be resolved (because the serialization code only knows about basicField). The exception message says to use XmlInclude or some soap attribute. However, I don't want to use those attributes on my BasicField definition itself (don't want the base class to know about any inherited classes), and unfortunately they can't be used on properties, so I can't put them on the field definition itself.
A bit of further research found XmlArrayItem, which I could apply to the collection:
So, I had:

[XmlArrayItem(typeof(DataField)), .... ]
public List<BasicField> fields;

But this presented another problem. The clue is in the de-serialization code:

XmlSerializer xs = new XmlSerializer(typeof(List<BasicField>));
StreamReader sr = new StreamReader("Fields.xml");
data = (List<BasicField>)xs.Deserialize(sr);
sr.Close();

There's no way to tell the deserialization about the inheriting classes. Ok, so the XmlSerializer does raise events if it does not understand something (e.g. UnknownElement), but that seemed to more extra work. Also, I would be using the attributes for saving and the events for loading, messy.
In the end, I created another class which just has the List in it, and then serialize that class.

public class DataWrapper
{
[XmlArrayItem(Type=typeof(DataField)), .....]
public List<BasicField> AllFields = new List<BasicField>();
}

This way the XmlSerializer can work out all the types. So everything fixed, I ran the code again. Failed again.
When serializing, I got a

System.InvalidOperationException: The type System.String may not be used in this context.

This seems to be generated when the generated serializing assembly tries to serialize the first item in my list.
Used XmlIgnore (to stop the serialization of individual properties) on the properties to 'debug' the situation (since you can't access the code which does the actual serialization, this seems to be the easiest way?), and tracked the problem down to this:

public System.Type FieldType;

A property which returned 'Type'. At first, I had to wonder why the exception mentions string. So I thought, that's odd, I guess that means 'Type' is not serializable. Mmmmm... Ahhh.. Of course, the problem is rather similar to my first problem. Because the actual type stored is not actually Type, but rather a type which inherits from Type.
Wanting a fast answer, I added XmlIgnore to the FieldType property, and added another property:

public string FieldTypeString
{
  get
  {
   return FieldType.ToString();
  }
  set
  {
   FieldType = Type.GetType(value);
  }
}

Since at run-time all the used types are resolable. Through I do wonder if there's any other way of doing it?

It's been to long since I've done serialization, but it tends to be one of those things which you do a lot of, and then don't touch for a year.

While running through the problem, got plenty of exceptions, which allowed me to explore the exception window.. Which is not quite as good as I thought initially, particularly when getting serializing exceptions, it's not really giving me much. I always have to click on Inner Exception.
Also the 'Get general Help for this exception' only does the outer exception, no the inner one.

VS crashing due to bad control

Stefan Barrett — Fri, 31 Mar 2006 23:50:00 GMT

Having more issues with my install of VS2005. I made a small change to my program (has user control which uses another user control, all definied in same project), hit compile, and VS closed down.
I manually re-started it, and re-opened my project, to get a message saying that VS2005 encountered a error and needed to close. Did I want to send a error report now or later. Ok, so I'm sitting on a train with 5% left on the batttery, so I say later. and it spends 5 min generating the dump :(
This time it started up on it's own, and I re-selected the project. This time it told me that it had disabled document something or other..
I think I messed up the inner control, and it's crashing VS. ha ha.
Seem to have several DW20 running, using >90% of CPU. Now, I just need to get to the code of the inner control.. Perhaps notepad
VS is going down again.

Have started to look around for a new PDA, and there seems to be a lot of choice. At least most of them seem to have WFI. Most of them seem to have Windows Mobile 5.0 OS, but at least one had Windows mobile 2003.. mmmm.

Issues with Visual Studio 2005

Stefan Barrett — Wed, 01 Feb 2006 00:13:00 GMT

It's funny in way. I do like .NET 2.0, but some of reports I've been hearing regardings bugs in the Visual Studio do put you off.
I have been working on a some code (part of a data transformation application), and today I finally had enough coded to start debugging it. I then started running into problems, including a slow editor, and finally this message:

ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x1b1ab0 to COM context 0x1b1c20 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Have had this message a couple of times, in slightly different situations, but once it was trying to return from one of my functions (last line of function, hit F10).

Ok, so the computer it is running on has had the betas & CTP's installed on it, but...

I'm assuming this is Visual Studio doing baaad things. The only good thing is that VS does not actually crash but allows me to continue...