I was trying to understand why  I was being told that the implementation of iXMLSerializable in DataTable and DataSet in 2.0 is responsible for all of the xml goodies (readxml/write/etc and of course all the webservices stuff) when DataSet in 1.0 and 1.1 does not even implement iXMLSerializable, yet still manages to do all of these things.

I know about the difference between using the binary formatter and the soap formatter, but I never worried about what was going on deeper down when datasets were “magically” serialized for me by ASMX.

After reassuring myself by looking at the DataSet Class documentation for 1.1 and seeing for sure that it implements iSerializable but not iXMLSerializable, I found this little goodie:

Dataset.iXMLSerializable.ReadXML Method  (This member supports the .NET Framework infrastructure and is not intended to be used directly from your code.)

and realized that it MUST be in there, just buried/hidden. So I kept digging and digging .

I found the answer in the June 2004 MSDN article: “New Features for Web Service Developers in Beta 1 of the .NET Framework 2.0“ by Elliot Rapp,Yasser Shohoud and Matt Tavis.

“The IXmlSerializable interface has been in the .NET Framework since version 1.0, but was not intended for general usage. This interface was designed specifically for System.Data.DataSet to enable custom serialization control and was marked for internal use to discourage its usage. Full support for IXmlSerializable in ASP.NET Web services has been introduced in the .NET Framework 2.0 in direct response to customer feedback for scenarios that require more control of the schema and wire format.”

So it was basically hidden from view.  Now, hopefully I’ll be able to sleep so I’m off to bed.

Since Ian Griffiths doesn’t have comments, I just wanted to make sure I got his attention with that title.

Do you know that VB.NET doesn’t have Data Breakpoints either? And that it won’t in Whidbey, either? (Hmmm that C# book I received today in the mail looks tempting…)

I’m sure many many programmers who came to .NET from VB6 spent hours trying to get it to work in VB.Net. This was the other lost debugging function that I refer to when I say there were two things that we lost when coming to VB.NET. Don’t ask Kathleen Dollard about Data BreakPoints. ANd if you must, be prepared to run….fast! (she misses them too!)

update  okay I was taking it personally, but it’s NOT a VB thing. … I tried every single language option in this drop down and every one gave me the message “[language choice] does not support data breakpoints“. (except when I selected Unknown) I wonder where you can use DataBreak points. As Paul Vick says in the comments…it just can’t be done in managed code because of garbage colletion. So this is just a big tease! 🙂

Nice to see a semi-official list. I did a LOT of digging to pull together my what’s new in BCL talk (and pestered Kit George a lot! 🙂 ) back in February and recently for DevTeach against the May bits

Ian Griffiths couldn’t understand why I was having a party because I could drill all the way into a dataset in VS2005 without having to retype each item in the quick watch window. eg. if I want to see the metadata for each table in a dataset, I currently have to explicilty enter dataset.tables(mytablename) rather than just starting with dataset and continue to open up the collections.

He sent me a screenshot from VS2003 showing the ability to drill a lot further than I have ever seen. I emailed him back and asked if he was pulling my leg. But in fact, he discovered that the debugger shows different information in C# than it does in VB! (This is in 2003). Ian explains further about this in his weblog.

Even though VS2005 now brings more drill-down functionality to both C# and VB, Ian and I both agree (along with Kathleen Dollard) that this is still not what we want to see when we debug a dataset. There is WAY TOO MUCH information in there. This is where the visualizers will come in. Let me look at the dataset or datatable in a way that I can just see metadata (and values) related to the data itself. SHow me the tables, the table names, the columns, the column names, the rows, the data in the rows (by column name please) and then maybe the state of the rows. Things like that. Or I can choose to see every single property exposed by the object. I know there are more default visualizers coming, so maybe this will be one of them. Otherwise, I’ll just have to write one, won’t I?

I had a good chuckle at Ian’s reference to “the VB.NET lifestyle”!

In Scott Nonnenberg’s blog post on how to write debugger visualizers that he wrote  after the March preview of VS2005 was released, he mentioned that the location where you need to place the resulting dll would change in the future releases. That time has come (I noticed today when I tried to use one of my custom visualizers).

Previously you put those files inside Visual Studio’s install directory. Now they go here:

My Documents\Visual Studio\Visualizers

And now back to our regularly scheduled program…(pun intended)

Update – see THIS POST to find out why I added the words “(in VB)” to the title!

In case you missed this in the previous bits (not PDC, but March & May), I am having a repeat episode of the thrill of debugging datasets in Whidbey.

HOORAY!!!!!!!!!!!!!!!!!!!

Hooray Hooray Hip Hip Hooray Whooppee Yeahaw I’m going to Disneyland! (oh scratch that last one.)

The Whidbey Beta1 lets me drill ALL THE WAY INTO DATAOBJECTS in the debug window.

Open the dataset. Open the tables collection. See all the tables listed. OPen a table. See all of it’s objects. See the rows collection. Open that up. View it’s contents. See the columns collection. Open it up. See Spot Run. See the column names all of the properties. There is so much information in there.

If you were never a VB6 programmer you may not understand. This was a normal function of the watch window that disappeared in .Net and has not appeared again until this particular the March preview release (the Beta1) of Whidbey. It was one of my biggest pet peeves (though I accepted that it was just really hard to do in .net) and is now my greatest elation.

Thank you debugger team. Thank you Data Team. Thank you thank you thank you. I don’t know what you did to hook into that (could it be those serializable datatables?) but thank you. (Oh did I already say that?)

Call me crazy. I’m so swamped but just got bit by the curiousity bug and did some very silly perf tests on Beta1. A few months back, Krzysztof Cwalina posted some Design Guidelines for Generics. In it, the BCL team recommends using <nullable> for value types. At that time I was curious about the performance although he did say : “We will work to make these two important generic types as efficient as possible.“  (he was also referring to <EventHandler T>).

Testing against the March bits of Whidbey, HasValue was a LOT slower than just testing, say for an int32, if it is >0 . So I went back and played with this again with the beta. I started with 100 iterations. All tests returned 0 milliseconds! (I also tested a random object just for fun). I pushed the iterations to 1,000, then 10,000. Still 0 milliseconds for everything. Finally at 100,000 I saw a glimmer of difference but not in favor of HasValue. At 500,000, you can see (below) that both functions are finally sweating a little at a whole 2 , 3, 5 and 7 milliseconds – if you can call 3 milliseconds “sweating“. Pretty fast! However, the HasValue is still slower. In my little test case, of course, this is not earth shattering. But obviously in more complex scenarios, stuff like this does matter.

At this point, they are still working to make a real performance case for nullable and hasvalue (remember, this is all in VB where I am playing) and I’m sure they will.

Just for fun, I checked the performance in .Net 1.1. Now that is on a machine with 2GB of ram and 2.8 GHz processor speed. The Whidbey tests are on a machine that is 1.6 GHz with only 512MB of RAM. So, looking at the test of int>0; the whidbey performance compared to 1.1 is even more impressive than what I saw here. THe 1.1 is on the left. Beta1 is on the right.

God only knows why I just wasted all this time thinking about this itty bitty little thing. I certainly have bigger fish to fry this week.

I hadn’t noticed this elsewhere, so just wanted to “log” it. Opening up a VB.NET project built in the May bits in the new Beta1 gives you this warning 3 times:

The “MSBuildVersion” attribute is deprecated. If the project is authored in the MSBuild 2003 format, please remove the attribute from the <Project> tag. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.      

The attribute can be found in the files that define the project (vbproj and vbproj.user).

To fix this, you can open up the actual project file (whatever.vbproj) in notepad.

The first parameter of the <Project> tag (in my situation) is:

MSBuildVersion=”2.0″

delete it.

Do the same in the user file (whatever.vbproj.user)

By deleting that attribute in these two files, I was able to get rid of all three.

I am 99% confident of this (it worked for me) but if I hear any reason why this is bad info, I will modify this post.

Don Kiely’s talk was fantastic at Vermont.NET on Monday night. I think he had everyone on the edge of their seats with all of the great tips & tricks for truly working in Least Privilege mode. Not only why you should do it but how to do it. And not only how, but what to expect because it ain’t easy! There are a few areas of focus for developing under least privelege. One is the hardest – making your “daily driver“ account a non-admin account. Your doing yourself a favor anyway – this offers you some good protection from hacking. But it is going to affect your everyday use of your computer – before you even open up your development tools. (or quickbooks!). Then there are the issues of using your development tools as a non-admin. I had a lot of pain enabling myself to debug in visual studio .net, both windows forms apps and web apps. Don’t even get me started about compiling VB6! Another key area is to think about what actions your code is taking. For example if you are persisting files, WHERE are you doing that? The trickiest part is that end-users of your application will very likely be running as non-admins. If we write our apps with an admin account and then deploy it to a non-admin user, you just don’t know what glitches they might encounter related to their lower priveleges. So by writing your app in the same mode, you can have a lot more confidence in the future of your application.

I was a little startled (and slightly embarrassed) when Don pointed out that running as a Power User is NOT a non-admin setup . It is not much less vulnerable than running as an admin. Ifyou really want to run as a non-admin, you need to be a plain old User. I just went through much pain going from admin to power user and now I realize I’ve barely done the deed. When I come back, I will be squeezing myself into a real non-admin role as a User.

Don left me with his power point deck and a slew of fabulous links to read more. They come from people’s blogs (eg Anil John, Andrew Duthie and others) as well as book chapters from Keith Brown and many other articles from these and other experts on the topic. I put them on the “past meetings“ page of the Vermont.NET website.

I can already see that the powerpoint slides are going to be a well-used resource in my office!

If Don didn’t have so much work to do, I would just have forced him to fix my computer and my applications that I am writing so that I’m running as non-admin. I would definitely consider calling in the big guns (experts like Don and others) to get the job done with this stuff on projects.

That’s because you have intelligent debaters on BOTH sides of the fence. I can’t believe I have missed this thread from being kind of heads down and no time for blog reading for a few days. Surely, the comments are growing by the minute.