So I converted a project at work from Visual Studio 2003 to Visual Studio 2005 today … and ran into several really random and annoying things:
First Thing: Some third-party controls that had to be de-referenced and re-referenced to get the .licx license files to update (I really have no idea what that was about, all I know is removing the reference from the project, and then re-adding it solved the problem).
I have three gripes about this: One: The error messages refered to non existent files like “LC” (and produced suitably confused-sounding error messages when double clicked about how the file where the error was, wasn’t…). Two: Why did the license files need changing? Three and most annoyingly why is it that I knew immediately that the problem could be solved by removing the reference and re-adding it?
I’ll tell you the answer to the last one: I have wasted countless hours of the last two years of my life adding and removing and removing and adding project references from the stupid visual studio solution explorer in a vain and desperate attempt to make some sense of the compile error: I can’t replace the file “blah” because someone is using it. The “someone” is Visual Stupido … just stop using it already! I’ve specified and re-specified my compile order, I’ve tried using makefile projects to compile seperately … nothing works. Hopefully they’ve improved things in VS 2005.
Second Thing: _Warning: ‘System.IO.Path.InvalidPathChars’ is obsolete:
‘Please use GetInvalidPathChars or GetInvalidFileNameChars instead.’_ Huh? After looking a little more closely, and guessing wildly that they meant System.IO.Path.GetInvalidPathChars() ... everything is working fine again. They replaced a perfectly good, working, read-only property with an equivalent method call. As far as I can tell, they did it because they wanted to call attention to the fact that they now have a separate list of InvalidFileNameChars, in case that’s what I really wanted. If I ever get over to Seattle, I’m going to hunt the person who made this decision down and give him 40 lashes with a wet noodle for wasting my time. Seriously, can someone please explain why they felt the need to do what it basically amounts to something like:
public static class Path {
/// Look, we made it a method instead of a property, go us!
public static char[] GetInvalidFileNameChars ()
{
return InvalidPathChars;
}
Is it true that you can have both VS 03 and 05 installed and running on the same windows?
Yes. In fact, you really have to have them both if you want to be able to target .NET 1.1, because the VS2005 IDE won’t let you compile with the old framework, and the VS2005 visual forms editor uses partial classes, which are a C# 2.0 feature.
Thanks what is the plugin which you use which send the commentor an email on reply?
Actually, static readonly array fields are a pretty serious design flaw. For example, try
Path.InvalidPathChars[@0@] = '\\'. After that call, all further uses of Path.InvalidPathChars now get modified data. This is because the reference is readonly, but not the contents. The new GetInvalidPathChars() method returns a clone of the array, so you can’t modify the data intialized in the static constructor. “out of the box” they both return the exact same data.There’s a difference between a static readonly array field and a read only property … a .NET property can contain code, so in C#, there’s nothing stopping them from writing something like …
public char[] InvalidPathChars {
get {
return _InvalidPathChars.Clone();
}
// No “set” accessor means this is “read only”
}
Hi Jaykul,
You’re right about having the clone code in the property, but there is a fairly subtle issue around doing that: unaware users can use
for (i = 0; i < Path.InvalidPathChars.Length; i++)which would cause the array to be cloned each time the code loops. Developers are much less likely to use< Path.GetInvalidPathChars().Lengthbecause it “feels wrong” to use a method in this way. Properties generally should be very light weight – cloning arrays doesn’t really fall under that category.