Rob Villahermosa's WebLog

Beta 1 Breaking Change List Publicly Available on GotDotNet!

robvi — Wed, 07 Jul 2004 21:01:00 GMT

It's been a long while coming, and I lot have people have been asking for it. The compatibility breaking change list for Version 2.0 (Beta1) has now been published up on GotDotNet publicly. See the default page at http://www.gotdotnet.com/team/changeinfo/default.aspx for further details.

There is a lot of good information up on this page. First is a list of all the API's that were obsoleted in V2.0. Second is a list of known breaking changes that you might encounter when running or transitioning your apps from V1.1 to V2.0 that we worked on as a team. Third is a list of API Changes made between the two versions.

I hope this information is useful, don't hesitate to comment on what you feel we need more of, are missing, etc. Looking forward to some good feedback.

Configuring your V1.1 apps to run against V1.0

robvi — Thu, 22 Apr 2004 04:48:00 GMT

A friend of mine was trying to get his V1.1 app to run against V1.0 without much luck. His config file had a startup section that looked like this:

</startup>

This will NOT work on V1.0!

In V1.0, the V1.0 shim has no support for <supportedRuntime> tags so actually does not know what they mean.

Now, here is where it gets unintuitive:

In V1.1, they started worrying about backwards/forwards compatibility and decided that perhaps the <requiredRuntime> tag was not the best thing to use and introduced the <supportedRuntime> tag.

The V1.1 shim actually checks for the <supportedRuntime> tag first, and if it finds it ignores the <requiredRuntime>.

So, in V1.1 even if you have something like:

<?xml version=”1.0”>

</startup>

</configuration>

The V1.1 app will still run on V1.1 because the V1.1 shim reads the <supportedRuntime> tags first.

The V1.1 app WILL NOT run on V1.1 though, if you don’t include the <supportedRuntime> tags and only have the <requiredRuntime> tag.

<?xml version=”1.0”>

</startup>

</configuration>

In this case, the V1.1 shim sees the <requiredRuntime> tag since there are no <supportedRuntime> tags.

BlackBox Testing

robvi — Fri, 05 Mar 2004 03:46:00 GMT

Today I attended the Microsoft Research Group's Techfest. It's like a giant science fair for the folk over in MS Research to strut their stuff and show us blue badges the latest and greatest in the world of technology. Anyways, I can't say much other than I was VERY impressed.

In particular, a lecture by Colin Campbell from the Foundations of Software Engineering group was particularly interesting.(http://research.microsoft.com/foundations/) One of the often forgotten areas of research is that of formal software testing practices. I'm sure that everyone out there who's been through Electrical Engineering/Digital Electronics 101 courses knows about finite state machines and how you can model event driven scenarios as as set of transitions between various states. In fact, I remember an interview question somewhere in which I was asked to model a Pop machine as an FSM in order to test it. Anyways, the basis of using this model for testing comes from a language called ASML (Abstract State Machine Language). The idea is that ASML provides a way to communicate a design non-ambiguosly, and that you can identify the behaviours of your component and generate tests from this specification.

Check out the free download: http://research.microsoft.com/fse/asml/ Cool stuff, eh?

This post is stated “as is” and confers no warrantees and guarantees no rights.

XML and my heartrate monitor info...

robvi — Fri, 27 Feb 2004 08:51:00 GMT

So, one of my passions in life outside of work is riding bicycles. I currently have 2 bikes - one is a 2002 Cannondale 900 SL, and the other is a 2000 LiteSpeed Ultimate. The Cannondale 900 SL is actually a replacement for my beloved Killer V 900 which I raced on through college but was unfortunately stolen from my balcony last year :(

Anyways, to get down to the technical part of this post... I started training with a heartrate monitor about 2 years ago. It's a Polar 710. It kinda sucks that I have to use the Polar Software to do everything, because I think it'd be pretty cool to be able to store that data to Pocket PC's, watch computers, and other electronic toys that don't exactly run the Polar Software. Well, .I took a look at the format they're using to store data. It's pretty much straight text - there are the recording parameters at the beginning of the file, but then after that it's the periodic data that the monitor takes every time it does a reading.

I'm going to munge all this into a nice XML file so I can then feed it to other programs for consumption. Hehe, isn't technology great? It can make you faster biker...

Help Us Help You

robvi — Tue, 24 Feb 2004 03:43:00 GMT

All too often I notice that we're slammed by the media as the “evil empire” who doesn't care tenderly for its customers. I agree that we've made our share of mistakes in the past, but we're really trying very hard to change that misconception.

Here's your chance to help us help all you devs out there with compatibility issues. We want your feedback! I know a lot of you have PDC bits and have had a chance to upgrade from V1.0 and V1.1, and I've personally met quite a few of you out there who've come to Redmond for DevLabs or ISV labs. Just today I got a lot of comments about a quick talk on some of our CLR compatibility efforts I gave at the VSIP Summit. I'd love more, you know how to contact me :) I also have a question - how would you folk like to be able to discuss compatibility issues you run into with us? Would a newsgroup dedicated to CLR Compatibility be something you'd like to see?

This post is provided “as is” and provides no warranties and confers no rights.

Breaking Changes: past, present, and I can't speak about the future

robvi — Sat, 21 Feb 2004 04:36:00 GMT

Ok, so a large part of my job is finding breaking changes and helping make sure that they get fixed. These changes are classified as backward or forward compatibility breakers. Backward compatibility means a newer version of the .NET FX can run older apps and forward compatibility means an older version of the .NET FX can run newer apps. There are currently two released versions of the .NET FX out there (excluding service packs) these are 1.0.3705 and 1.1.4322 or V1.0 and V1.1 for short.

There are a bunch of apps out there built on V1.0 that people are upgrading to V1.1. Keep in mind that you have to be aware of the breaking changes between these two versions! http://www.gotdotnet.com/team/upgrade/apiChanges.aspx gives you a list of API changes. To read the list after you've downloaded it, the left hand column represents removed API's and the right hand column represents added API's. Breaking changes are highlighted in Red. If you find an API has changed, you likely can get around the problem by updating your

http://www.gotdotnet.com/team/changeinfo/default.aspx gives a list of other breaking changes in both forward and backward directions. If you've upgraded to V1.1 and are encountering problems, check here. This is a great resource as it shows workarounds for a lot of common problems that I've seen being asked.

Obviously, our focus is predominantly on maintaining backwards compatibility. This makes sense, as you can't expect to take advantages of new features and expect your code to run fine on an older version of the FX where these features did not exist. At the same time, the line is tough to make - what about improvements?

Sometimes fit and finish and improvements to the overall quality of FX are somewhat hindered because of the requirement to maintain compatibility. A great example of this is making additions to enums. Trust me, there are a ton of extremely intelligent folks here who debate the issue of moving forward and making something great vs keeping things compatible to no end. In the end, rest assured we're doing our best to satisfy as many needs out there as possible.

This posting is posted “as is” and guarantees no warranties and confers no rights.

Why Compat, when there's Side by Side?

robvi — Fri, 20 Feb 2004 06:11:00 GMT

I used to (and still do) play computer games. I remember playing this flight simulator game as a kid on Windows 3.x which I totally loved. I used to think about playing it at school and couldn't wait to get home just so I could sit my arse down and shoot down attacking cat-alien beings. Anyways, I installed some poker game one day and it apparently copied over some newer .dll's that my beloved flight sim needed and everything broke. That stunk. Well, side by side seems to be a solution to this - just allow multiple versions of libraries to exist simultaneously and you'll never hit this “.dll hell” problem.

This is a great idea, but we often forget that there are drawbacks. First, what if a new FX version has significant perf improvements? It would suck if your app couldn't take advantage of this especially if there were no changes that would break its functionality. Second, if you want to run against one and only one version of the FX what happens if someone doesn't have that version and doesn't want to install it? Here's a scenario - you have this managed app that doesn't ship with the redist on its CD, but your laptop has a newer FX version installed. You're sitting in a hotel room in TimBuk2 and they only happen to have dial-up 'net access that's sporadic at best. It would smell like old cheese to have to download the redist before running the app. Wouldn't it be great to just have it work on the newer FX?

I could go on and on about this, but the truth is simple. Though side-by-side is an important concept and can be a solution in some scenarios, the need for compatibility going forward is great. I'm glad I can be part of this, it's a huge problem and we're on the forefront of trying to solve it.

Anyways, that's it for today's rant. I'm going to eat sushi over in Redmond Town Center now as it's my friend's bday and on your bday you get to eat free. They have lots of tuna there everytime I go and it's always pink and fresh. Mmmmm... tuna ;)

This posting is provided "AS IS" with no warranties, and confers no rights.

How do I detect what .NET Framework version is installed on a machine?

robvi — Wed, 18 Feb 2004 06:15:00 GMT

I see this question asked again and again on various newsgroups. After picking some of the BIG brains I work with here are two methods you may want to consider:

Method 1:

1.) Under HKLM\SOFTWARE\Microsoft\.NETFramework\policy\ check to see if the version you want is installed (for example, look for the v1.1 folder and 4322 for the version number to detect the released version of V1.1)

2.) Under HKLM\Software\Microsoft\.NETFramework\InstallRoot get the path where the Framework is installed. Create a directory string by concatenating the install root and the version under policy. E.g. "C:\WINDOWS\Microsoft.NET\Framework\" + "v1.1" + "." + "4322"

3.) Look at the directory, if mscorlib.dll (or another critical .dll to the .NET framework is there) the runtime is installed.

Method 2:

There's a caveat to this method in that the shim gets left behind when we uninstall if there is more than one version of the CLR on the machine, but it still can be useful depending on what version you're looking for:

LoadLibrary(“mscoree.dll“); - if this fails then there's no runtime installed

GetProcAddress(“CorBindToRuntime“); - if this fails there's no runtime installed

CorBindToRuntime(“GetRequestedRuntimeInfo“);

GetRequestedRuntimeInfo(xxxx); where xxxx is the build number.

This posting is provided "AS IS" with no warranties, and confers no rights.