C#

Parse and TryParse

Matt Simner .NET Framework, C# , , ,

Like many people I’d mistakenly thought that xxx.Parse was the only way to validate types like ints and DateTimes.  This kindof ‘was’ the case in .NET 1.1, but numeric data could be validated with Double.TryParse then converted to the correct type.


In .NET 2.0 you can happily use the TryParse method on pretty much all the types you’d want to validate – without the nasty overhead of catching an exception.  This post goes into a bit more detail, and links to a tool to benchmark the results for yourself.


I’ll be on the lookout to convert whereever I find int.Parse, as it’s pretty rare you ‘actually’ want an exception to be thrown…

Breaking Changes between .NET 1.1 and 2.0

Matt Simner .NET Framework, C#, Visual Studio ,

I spotted an old post from Brad Abrams on breaking changes for .NET 1.1 apps recompiled with 2.0.  The links had moved but are still relevant…


http://msdn2.microsoft.com/en-au/netframework/Aa570326.aspx


My own observations from converting projects are a little higher level in that I’m also interested in what effort you’re liable for when converting, and also things to watch out for if (like me) you’re having to persist a ‘shared’ code base of 1.1 and 2.0 core libraries (temporarily) while you migrate all your client apps.


ASP.NET Projects.  This includes Web Service projects.  You’ll find that you’ll probably have to reconstruct these projects based on the content files and you’ll also need to make a decision on the model you’re going to use for debugging – i.e. whether to use the new debugging host (removing IIS from the debugging equation) and whether to use a dynamic or static port.  Steer clear of the ‘Web Site’ project too as this could leave you confused for hours wondering why you can’t debug anything – look for the ASP.NET projects.  More info on the ASP.NET side can be found from Peter Laudati’s post.  Microsoft also have an article covering conversion of ASP.NET projects


DataSets.  These have changed in that a ‘designer’ file is now the main source file (apart from the .xsd).  If you’re sharing DataSets across 1.1 and 2.0 projects just share the .xsd file otherwise you’ll be asking for trouble as the other generated files are incompatible.  Any structural changes to a DataSet in one project (say .NET 1.1) will not be reflected in the corresponding 2.0 project.  You’ll need to check out the XSD in both places (assuming you’re using VSS) and build both in order to avoid breaking one of the projects.


Windows Forms.  I’ve had a recent experience where the InitializeComponent() method in a form (edited with VS 2005) places calls that aren’t compatible with .NET 1.1.  The code compiles (as below) but ‘exception thrown by target of an invocation’ gets thrown on the following line…


((System.ComponentModel.ISupportInitialize)(this.validatingProgress)).BeginInit();


This is because the control (a PictureBox in this case) doesn’t implement ISupportInitialize in .NET 1.1 but does in 2.0.  The equivalent in 1.1 is SuspendLayout()


This would just be one example of something that’s syntactically correct, but could fail at runtime.


Cryptography – Using Base64 to encrypt/decrypt Strings rather than Unicode or ASCII – Error – ‘Length of the data to decrypt is invalid’

Matt Simner C#, Security , , , ,

I recently did a conversion from .NET 1.1 to .NET 2.0 for a particular project.  The framework classes were still in 1.1 (where our TripleDES encryption library lives).  Unit Tests still run in 1.1 and all pass.


A production problem then started to show ‘Length of the data to decrypt is invalid’ and I was horribly confused as I’d inherited some of the code and all seemed good…


I thankfully found the following … http://blogs.msdn.com/shawnfa/archive/2005/11/10/491431.aspx that explained why it’s really not a good idea to assume that even though you’re only encrypting ASCII characters, you don’t use 7 or 8 bit encoding to encrypt/decrypt.  The key is in the fact that the overall sequence of bytes isn’t guaranteed to be valid Unicode or ASCII.


(Why do the unit tests pass?) – because the Cryptography classes in .NET framework were revamped for V2.0 and validation tightened up.  As Shawn says – it’s better that it doesn’t successfully decrypt into an invalid string.


This leaves a bit of a tidyup of course as I’ve now got to re-stuff all encrypted data into the database and patch the apps to ensure that the correct encryption is used.  I’ve also got to find a way to support existing files and string encrypted with the class as some code is still happily using this in 1.1-land and some is clearly ‘not’ working in 2.0-land – fun!


I guess it’s a lesson that today’s code won’t necessarily work tomorrow – and you shouldn’t discount breakages from framework changes when you’re investigating issues.