Just passing on the word that VSTS should be available for download to MSDN subscribers starting tonight. I for one am super psyched to get my hands on these bits since I will finally have support for all the team based tasks I do on a daily basis baked right into my favorite development environment.

Update: It's there, go get it... all 3.5gigs of it. :)

Ok, so we all know by now that Longhorn is undergoing some changes in order to deliver the product in a timely fashion. Basically what it seems to boil down to is that we're going to get two out of the three major pillars of the Longhorn vision delivered to us on top of the existing XP/Windows 2003 kernels: Indigo and Avalon. The only major pillar being dropped is the elusive database oriented storage system: WinFS.

Indigo is a no brainer. It's been common knowledge (google cached link here, since Don's permalink seems to be broken) for some time now that it was going to work on older platforms anyway. I can't see Indigo suffering in any way, shape or form as a result of this announcement.

Avalon on the other hand was based on some features of the new display driver model that was going to be introduced in Longhorn. Avalon counts on leveraging the machine's GPU to it's fullest extent to do a lot of its rendering. The problem with today's model is that for things like DirectX applications to get the maximum performance while rendering, they must take over the whole GPU. Avalon requires scheduling and sharing of the GPU. As a result of this difference, I can see some (hopefully minor) cutbacks in Avalon features as a result of the underlying platform not being able to provide all of the support it needs to work its magic. It will definitely be interesting to see how Microsoft solves this particular problem.

As for WinFS, yeah it definitely sucks that we're losing it, but I'd rather they get it right before they unleash it into the wild. I really like where they're going with it and the existing design/feature set is good, but still needs some work. I think it will be the storage system of the future, but if it was going to hold up the delivery of the rest of the pillars then this was a wise decision on Microsoft's part and I believe it's in the best interest of everyone who develops for or uses Windows.

In all, I think this decision was a wise one and that we are going to get a lot of technology advancements that are important to building better applications in a more timely fashion as a result.

I was reading Don's blog this morning and he links to Aaron's post about designing web services with the "contract first" mentality. Here's my two cents:

To answer question #1: Yes, I absolutely believe in contract first. Defining web service should be no different than defining any other API. You define your interfaces first using the interop standard and then use whatever technology you can find to provide the underlying implementation. If you ever find fragments of your underlying technology bubbling up the contract level, you know you've done something wrong.

Therefore I suppose the answer to question #2 is obvious: Yes, I believe it will lead to better interop. If we all design contract first we can be relatively sure that someone, somewhere is writing tools to support standards based development in our favorite language/dev-environment. If you start using your language/dev-environment's special tools that don't follow the standards, then interop support becomes an in house problem as you'll probably need to invest time in researching how other languages/dev-environments may handle your semi-proprietary contract just so that you can support others as they try and develop against it.

As with the previous question, #3's answer shouldn't be too hard to figure out: Yes, I fight against VS and parts of the System.Web.Services API everytime I develop a web service. I design my contracts using the built in XML and XML Schema editor's, but ultimately end up stiching the WSDL file together by hand. As for supporting the latest web service standards, I'm really looking forward to Indigo, but for now nothing beats WSE 2.0.

Hmmm, just came across this. I'll wait 'til I get the official word from Microsoft on exactly what made the cut and what didn't, but it doesn't sound like any of the major pillars are being completely dropped.... just scaled back.

Looks like it shouldn't be too much longer before we can get our hands on a build of Visual Studio 2005 Team System. This is great news. Lots of people have been concerned that it wouldn't receive the same level of testing before it is released since it hasn't been part of previous community releases. While they are new features and will certainly need some testing to get the bugs out, they are more like extensions to the shell than anything else. The core of the Visual Studio 2005 product, not to mention .NET 2.0 runtime/framework, has been in the community's hands for some time and that's more important the way I see it.

I'm sure a lot of people have read about the Microsoft interview process before, but here's a inside look courtesy of Channel 9. I totally realize it was a mock session, but am I the only one that found the interviewee's implementation of the palendrome detection algorithm painful? His thought process where he came up with all the logic was great, but when it came time to turn it into code it got really rough. I wanted to grab the marker and bang out the code for the guy. :)

How many people work with someone like that? I've encountered a few in my short career and I just have the hardest time dealing with them. Is this lack of patience a trait common to most geeks or is it just me?

I was just doing my morning reading when I came across this post. I for one am really looking forward to this being baked right into VS. We've used ACT in the past, but Orcacoke seems like it's really stepping it up in terms of features and integration. Like most people, I can't wait to get my hands on a VSTS build.

I was catching up on my blog reading during lunch and came across this post from Mikhail Arkhipov who works for Microsoft. Apparently he is on the ASP.NET 2.0 team and is looking for suggestions on how to solve the problem of declaring instances of generic typesin "code-in-front".

My suggestion is to strive for 100% XML comformity so that things can be parsed/generated more easily. Therefore, I would go with a custom attribute which is scoped to the ASP.NET schema namespace, like so:

<myNs:MyGenericControl asp:genericParameters="TypeName1, TypeName2+SubTypeName" someTextProperty="Hello World!"/>

Whatcha think? If you've got other suggestions, head over there and state your case in his comments section.

We're doing some work right now with persistance of object graphs into a SQL server image field using the BinaryFormatter. We're using “simple” serialization, meaning we're just marking our types with the SerializableAttribute and whatever transient fields shouldn't be serialized we're marking with NonSerializedAttribute. I realize that this problem could be solved if we go and implement ISerializable ourselves, but... I'd rather talk about the issue at hand first.

For starters, everything works 100% as advertised until you rebuild the assembly of the types that have been persisted. After a rebuild, upon deserialization of those objects you'll end up with a nice little SerializationException with the message: “Insufficient state to deserialize the object. More information is needed.”.

Now, at first I realized that we were not specifying a FormatterAssemblyStyle at all. Therefore, I knew the versioning information was being included in the serialized stream and when the BinaryFormatter went to deserialize the stream it couldn't find the older version and, well... kaboom. Ok, “no problem”, I thought. Let's just throw the FormatterAssemblyStyle.Simple on there and go with it. After all, we're not making changes to the structure of the objects, just implementing more functionality and/or fixing bugs, so the serializer should have no problem. Well, I was wrong. What's happening is either a bug or is a very strange design decision that I don't quite understand.

The first step I took while debugging this problem was figuring out how see what the BinaryFormatter was writing into the stream. The way I did this was to serialize the root object into a MemoryStream and then take those bytes and Debug.WriteLine them out using a StreamReader with UTF8Encoding. Now, the root object of our graph is composed of other custom types from the same assembly as well as basic framework types (String, Int32, ArrayList, etc.). Without specifying the FormatterAssemblyStyle.Simple, I could clearly see the AQN being written out for each and every type. Then, we set FormatterAssemblyStyle.Simple, but what I saw next was very strange. As expected, the only thing being specified for the root object was its partial name. The same went for all the framework types, no matter where they appeared in the object graph. However, it looks like at least one of the instances of a custom types contained by the root object (which, if you recall are also from the same exact assembly) was still being serialized with a full AQN!

So I just have a few questions:

1. What the...?
2. How the...?
3. Why the...?

For anyone interested, here's the text output from the process that I mentioned earlier. Maybe someone out there (from MS?) can make sense out of it. You can clearly see on the fourth line (assuming you're viewing with Notepad without wrapping turned on) that there's all of a sudden a full assembly name written out in the form of:

[CustomAssembly, Version=0.1.1690.30673, Culture=neutral, PublicKeyToken=821ded9c8ea11544

Hello everyone! Welcome to the new home for my blog. I haven't posted up in quite some time, but I've been lurking in the comments of other people's posts and more recently I've been frequenting Channel9. My old weblog was hosted on weblogs.asp.net. I'd like to thank Scott for inviting me as one of the first lucky candidates to use .Text when he first started rolling it out.

I am still working on the custom skin for my weblog so it looks a little more original. I started by leveraging an existing skin called LuxInteriorLight which I picked up over here. If you're a fan of a darker look, there's also a LuxInteriorDark version of the theme. Kudos to the author for such a nice job on both. By the time I'm finished the whole site should be 100% XHTML 1.1 + CSS2 compliant. In the meantime, if you notice any rendering errors with the skin, please feel free to drop me a line and lemme know.