CLR Versioning and Side-by-Side Execution – .NET 2.0 to .NET 3.5 and .NET 3.5 to .NET 4.0

Posted by Annie on Sep 16, 2011 in Coding, Technology | 0 comments

The other day at work I spent some time investigating an OutOfMemoryException being thrown by third-party component being used in a .NET 3.5 application. After a closer look and weighing up some options on how to fix it, we realized that the problem went away if the application was recompiled in .NET 4. This ended up causing some discussion among the team – how could simply recompiling the application that the .NET 3.5 third-party library was being used in fix the problem in the library itself?

One of our team members was convinced that if the third-party library had been built using .NET 3.5 and it was then used in an application that targeted .NET 4, that the third-party library would continue to run under the context of .NET 3.5. To that end, he was sure that recompiling the application in .NET 4 couldn’t have actually solved the problem.

Of course this triggered a Google search frenzy which lead us to this article on msdn:

Excerpt #1:

Add-in Problems:

To give all add-ins the best chance of working, we always choose the latest runtime for managed COM activation. Even if you only have older add-ins installed, there is no way for us to know that when that add-in gets activated, so the latest runtime still gets loaded.

An unfortunate side effect of this activation policy is that when a user installs a new application with a new version of the runtime, completely unrelated applications that use managed COM add-ins, built against older versions, suddenly start running on a newer runtime and can fail.

For the .NET Framework 3.0 and 3.5, we solved this problem through an extremely strict policy: each release was additive and only added new 
assemblies to the prior version with the same runtime underneath. This prevented any compatibility issues when installing them on a machine running the .NET Framework 2.0.

This means that when you are running an app on the .NET Framework 3.5, you are really running it on the 2.0 runtime, with a few extra assemblies on top of it.

What the above implies is that the update from .NET 2.0 to .NET 3.5 was only ‘additive’, that is, Microsoft added some new functionality (dlls) but kept existing functionality the same for backwards compatibility. Actually, if you take a look in the v3.5 folder under Microsoft.NET in the Windows directory, you’ll see that there are a handful of new dlls but no new core libraries to replace the .NET 2.0 versions.

Therefore, if the application we were dealing with had been using a .NET 2.0 third-party component and we were rebuilding the whole application in .NET 3.5, all core types would still be exactly the same under the covers and our colleague would have indeed been correct in his conclusion that rebuilding the application couldn’t have solved the problem.

However, this doesn’t seem to be the case from .NET 3.5 to .NET 4… if one reads on:

Excerpt #2:

Add-in Problems:

This means that when you are running an app on the .NET Framework 3.5, you are really running it on the 2.0 runtime, with a few extra assemblies on top of it. However, it also means that we couldn’t innovate in the .NET 2.0 assemblies, which include key functionalities, such as the garbage collector, just in time (JIT) and base class libraries.

With the .NET Framework 4 we have implemented an approach that allows high compatibility, including never breaking existing add-ins, and also lets us innovate in the core. We can now run both .NET 2.0 and .NET 4 add-ins in the same process, at the same time. We call this approach In-Process Side-by-Side, or In-Proc SxS.

So the .NET Framework 4 allowed Microsoft to ‘innovate in the core’ – in other words, there are new versions of the core libraries. Fair enough, Microsoft do need to be able to make improvements to existing code after all, otherwise we’d still be using .NET 1.0 at the core! But hang on, doesn’t this mean that if you re-build your application in .NET 4.0 that you’ll have to regression test the whole lot because who knows what core type implementations may have changed under the covers? Well no, not really, because of this new approach that Microsoft have adopted called In-Process Side-by-Side execution!

This all sounds great, until you read…

What Does In-Process Side-by-Side Mean to You? > Library Developers and Consumers:

In-Proc SxS does not solve the compatibility problems faced by library developers. Any libraries directly loaded by an application—either via a direct reference or an Assembly.Load*—will continue to load directly into the runtime and AppDomain of the application loading it. This means that if an application is recompiled to run against the .NET Framework 4 runtime and still has dependent assemblies built against .NET 2.0, those dependents will load on the .NET 4 runtime as well. Therefore, we still recommend testing your libraries 
against all version of the framework you wish to support.

Yup, that’s right. If you’re either developing or consuming a library (and really, what developer isn’t doing at least one of those two?) and you decide to upgrade your application to .NET 4, Microsoft actually recommend that you test, test, test!

This tweaked my interest – how different could these new core libraries really be?. I installed dotPeek and opened up both the .NET 2.0 and .NET 4.0 mscorlib.dll assemblies. I drilled down to the Dictionary class and found that there were in fact quite a few, albeit minor, differences between the two implementations!

Anyway, the moral of the story is – upgrading from .NET 2.0 to .NET 3.5 really isn’t a big deal – it’s always wise to do some regression testing, just in case, but you really shouldn’t find many issues with this migration. Upgrading from .NET 2.0 or .NET 3.5 to .NET 4.0 is a different story though. If you’re lucky, In-Proc SxS will help you with backwards compatibility, but if you’re developing or consuming libraries then you’d better have some regression test plans up your sleeve for this migration.

So at the end of the day, it seems like our third-party component bug could well be resolved by rebuilding the whole application in .NET 4 – who would’ve thought!

TimeEstimator featured on Gao7.com and SmashApp.com!

Posted by Annie on May 20, 2011 in Coding | 0 comments

Today I got two pretty exciting emails about my little iPhone game, TimeEstimator.

The first was from someone at Gao7.com telling me that they had ‘promoted TimeEstimator’ in the ‘Free for Limited Time’ section of their site. The site is all in Chinese but thanks to Google Chrome and it’s fantastic translating functionality, you can read all about TimeEstimator on Gao7.com even if you can’t speak Chinese!

Then in the afternoon, I received an email from someone at SmashApp telling me that they also had selected TimeEstimator to be showcased on their site! How exciting!

I’m not entirely sure how these two sites have come across TimeEstimator but it is really cool to be noticed – so a big thank you to you both :)

A new year, a new app – CountDown for Windows Phone 7

Posted by Annie on Jan 2, 2011 in Coding | 1 comment

2010 was a busy year for me. I spent a lot of time at mflow, learning lots and working hard. I spent 4 weeks on the back of a motorbike touring 5 countries in Europe and 2 weeks riding the Shinkansen up and down Japan. I saw Billy Connolly live, watched Cirque du Soleil in awe at the Royal Albert Hall, ice skated outside the Natural History Museum.

However, today is 1/1/11 which means I’ve got a whole new year ahead of me to fill up with more fun stuff, and I’m excited :)

This morning, my first ever mobile app was published on the Windows Phone Marketplace! It’s not exactly rocket science, nor is it going to make me rich (it’s free) but I’m just happy to have published something. It’s called CountDown and if you have Zune installed, you can have a wee look here.

If you don’t have Zune installed, here’s an awesome screenshot of it in Zune:

As the descriptions says, this is a simple little app that allows you to keep track of various events and other important dates and counts the time remaining until or since each one. Nothing complicated, but it served it’s purpose as a learning experience. Developing for the mobile form factor is really quite different to developing for web or even desktop because the screens are so much smaller and less ‘usable’ than other mediums. The design, layout and usability of the app has to be very well thought through.

Anyway, this year I hope to develop a few more Windows Phone 7 apps as well as maybe try my hand at Android / iPhone / iPad. I do have a brand new MacBook Pro now so I have no excuses anymore :)

HackCamp @ Google London

Posted by Annie on Jun 23, 2010 in Coding, Technology | 1 comment

A couple of weekends ago, I was lucky enough to be able to go along to HackCamp at the Google offices in London together with the mflow team. It’s the first ‘hack’ day/camp I’ve been to – and although I didn’t stay for the whole weekend nor did I actively participate in the hacking, I got to see what a hack camp is all about. For those of you who have never heard of this term before, a hack day/camp is basically a congregation of hackers, developers, designers (geeks in other words) who get together and spend 24~48 hours building an application using whatever tools they have at their disposal, in small groups or alone.

There were about 10 or so different speakers presenting their APIs at HackCamp, and although you didn’t have to use those APIs in particular, it was certainly very interesting hearing about what others have to offer. One of the APIs that I thought was a great idea was this one – 0870.me. 0870.me is an API that allows you to plug in a standard 08* number (which mobile networks charge a fortune for here in the UK) and it will return to you a matching non-08* number if it can find one in it’s database. How neat is that??

There were speakers from Twitter, Google AppEngine and Buzz to name a few big ones, but also lots of smaller companies. Tum and Demis from mflow gave a talk about the mflow API.

Once all the hacked-up apps had been submitted, I had a quick look and found this little gem: tron. It is very cool to see that someone has used the mflow API in their app!

Anyway, having had a small taste of these ‘hack’ camps, I may just have to keep my eyes out for another that I can go to coz they sure do look like they could be lots of geeky-fun :)

.NET ObjectDataSource ignores culture information when inserting and updating

Posted by Annie on Jun 17, 2010 in Coding | 0 comments

It’s been ages since I last updated my blog and I’m feeling super guilty.

So I thought I’d get stuck into it again and start with a whinge – a whinge about something that had me stumped for way too long this morning.

I have to say that I hardly ever use the out-of-the-box ASP.NET server controls (like asp:DropDownList, asp:TextBox, asp:DataGrid, etc etc) because I prefer to use standard HTML controls, stick runat=”server” tags on them and handle them manually. Call me old-fashioned, tell me I’m doing it the “hard” way… I don’t care. It works and I know how to do it quickly. I always find that when I use the more complete and complex server controls, I get 95% of the work done quickly and then spend hours trying to get the last 5% to work. I don’t like that very much.

Anyway, sometimes I end up having to use a variety of these server controls and today was one such day. Everything was going swimmingly until I tried to insert / update a DateTime property on the type that I had bound my ListView control to, using an ObjectDataSource. I’m in the UK and here, we do not use US-formatted dates. For some reason, no matter where I put localization code to set the locale to “en-GB”, when I hit my “Save” button, my code would throw an exception because it could not convert the string representation of the date into a DateTime object. That’s because it was trying to convert it to an American date. Grr!!!

After a lot of Googling, I came across this article. And there was the answer I was looking for.

Turns out that this is a known bug since ASP.NET 2.0 that Microsoft have decided they “won’t fix”. WTF. They’ve decided not to fix it because ”... the potential fix is relatively dangerous and the workaround is relatively simple…”.

The bug occurs because behind the scenes, .NET is calling ConvertFromInvariantString on all the new values – which is the “en-US” culture. This is clearly a massive assumption on their part but alas, it seems it is “too risky” to fix this.

The “simple workaround” they suggest is to handle the OnItemInserting and OnItemUpdating or OnRowUpdating events and in those handlers, extract the date values from the EventArgs, parse them from strings into DateTime objects and save them back. The following is an example of how one might do this:

1
2
3
4
5
6
7
8
9
10
11

private static void MyList_ItemInserting(object sender, ListViewInsertEventArgs e)
{
	var myDate = e.Values["MyDate"].ToString();
	e.Values["MyDate"] = DateTime.Parse(myDate);
}
 
private static void MyList_ItemUpdating(object sender, ListViewUpdateEventArgs e)
{
	var myDate = e.Values["MyDate"].ToString();
	e.Values["MyDate"] = DateTime.Parse(myDate);
}

I realize this is not a hard fix – but the annoying part was figuring out why it was happening in the first place!!

Anyway, I hope this whinge helps someone else solve this problem… :)

How to make a text string fit your labels in .NET

Posted by Annie on Mar 9, 2009 in Coding | 4 comments

In my chosen career, I solve problems everyday. Sometimes the problems I’m given are small and simple to solve, and sometimes they are most definitely not. That, I can deal with. What annoys me is when a problem seems like it should only take five or so minutes to solve and yet somehow, it takes you all day. It’s not that you’re bad at what you do, it’s just that the thing you’re trying to do wasn’t quite as simple as you or anyone else had thought it would be. Or perhaps the framework you’re working with has some nasty little quirks that you weren’t aware of. Or perhaps the thing you’re trying to do just hasn’t been done before, or at least hasn’t been well documented. Whatever the reason, spending all day on a “simple problem” isn’t good for your sanity and makes you feel like you ought to be doing COMP101 all over again.

One such problem that I’ve come across more than once in the last few weeks is how to make a text string fit inside a label or other similar control. If the string is too long to fit, the end should be truncated and replaced by an ellipsis. Sounds pretty straightforward eh? Nope, think again.

After coming up with a few complicated solutions including but not limited to iterating through every character in the string and measuring the length of the string (yes, highly inefficient, I know!), I finally found a solution which seems to do the trick. I feel this amazing solution needs to be shared with everyone so here it is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

private string textToDraw = "Hello, how are you? Why does this string not fit in the label that I have drawn? Maybe it is because it is too long?";
 
public Form1()
{
    InitializeComponent();
    label1.Text = ShortenString(textToDraw, this.Width - 10, label1.Font);
}
 
public string ShortenString(string myString, int width, Font font)
{
    string result = string.Copy(myString);
    TextRenderer.MeasureText(result, font, new Size(width, 0), TextFormatFlags.EndEllipsis | TextFormatFlags.ModifyString);
 
    return result;
}
 
private void Form1_ResizeEnd(object sender, EventArgs e)
{
    // Set the width to something - I've just set it to the width of the form - 10 to allow for the ellipsis but
    // I guess this would need to depend on which control the label is to be displayed inside of
    int width = this.Width - 10;
    label1.Text = ShortenString(textToDraw, width, label1.Font);
}

The trick to solving this problem was to use the TextRenderer class and calling its MeasureText function. MeasureText doesn’t seem like the most obvious function to use but it seems to work.

Note that this example is for a C# winforms application. The same could be done for a web application although you’d have to use JavaScript to re-calculate the string when the browser or element is resized.

Has anyone else ever had to solve this particular problem? If so, I’m interested to hear how you did it!