Wow, it's been about a year and a half since I posted on this blog and I've recently been pinged a few times by folks wondering what I've been up to so I figured it was worth checking in.
About a month or so after my previous post (soon after shipping Whidbey), my time on the C# Compiler team came to an end when I moved over to the Deployment Technology Group as the Test Manager. We're working on several projects all focusing on--surprise, surprise--deployment. We've got a team focusing on the Setup Project in Visual Studio, another working on the internal toolset used to author the various VS and .NET Framework SKUs (it's based on WiX), and a team working on the actual VS/NetFX installer. It's been a lot of fun and quite challenging and we've got some pretty big plans for the future.
Anyway, though I haven't been blogging on this site for a while I have actually been reasonably active on my personal blog: http://blog.gusperez.com. I've been thinking about bringing this blog back from the dead if I find some time to start posting about some more work related items but I won't promise anything as that's something I've fell short on in the past (just look down about five or six posts and you'll see what I'm talking about). My other blog is mostly on the geek side though so it may still be of interest to the folks who've still somehow remained subscribed to this one all this time.
That's all for now. Just wanted to pop back in with an update that I originally planned on posting over a year ago. Better late than never I guess...
Vijay has started blogging. Note that he's had a blog for a while now (Jan 2004) but he's now actually adding entries. :) Head over to his blog and read up on some of his great work and background testing Whidbey's C# Edit-N-Continue feature. Good stuff.
You can get the latest version of
Snippy from
GotDotNet. There is a beta 2 version as well as one based on the latest RTM RC so most people should be covered.
Turns out Snippy has had a growing set of users over time which have been emailing me quite a bit recently inquiring about future updates. I haven't been able to work on it for a while but I have now found it a new home. Some of the good folks on the VSEditor team (including my wife :)) have taken my code, updated it, and are in the process of getting out to the community again. So Snippy should be back soon; sorry for the delay.
Got a chance to code some today and I finally got around to getting Hovervue all packaged up and usable by anyone who's interested. You can get the full scoop on my personal blog. You can also see screenshots here which are pretty self-explanatory as to what the app does. If you decide to try it out (note it's a Whidbey beta 2 app, so the beta2 redist is required) I'd love to hear any feedback/ideas/bug reports you may have.
For those who might remember, this is actually an app I wrote during the beta 2 appweek. The other members of the team created a bunch of tiles for it (e.g. Outlook mail/calendar tiles, RSS readers, our internal bug database tiles, etc.) but I've only included the ones I've creted myself so far. More tiles should come in time including some of those created by others on that appweek team (I'd like to check with them before posting their stuff). Eventually, I'll also write up a quick document to describe how anyone can create their own tiles as well.
Lots happened with Nullable pretty late in the game and it sure was a big effort by a bunch of people across several teams to make it happen. Check out Soma's
post about the Nullable DCR and get a quick summary of how things are changing...
This one came up today in an internal discussion alias and reminded me of how many times I've seen people get stumped on this one and end up working around it. A lot of users have used verbatim string literals as they ease writing multi-line strings literals or for specifying paths and not having to escape the backslashes (as Andrew pointed out in the comments for this post). Here's an example:
string s = @"First line
Second line.";
string path = @"c:\windows\system";
The trick with verbatim string literals is that everything between the delimiters (the double quotes that start and end the literal) is interpreted verbatim. So a the following line of code:
Console.WriteLine(@"First line\nSecond line.");
will actually output:
First line\nSecond line.
So that's easy to understand and comes in handy but some have trouble figuring out how to include an actual double-quote character in these literals. The answer is to use the quote-escape-sequence (two consecutive double-quote characters). Trying to escape the double-quote using a backslash (e.g. \") will not work. The following line of code:
Console.WriteLine(@"Foo ""Bar"" Baz ""Quux""");
will output the following:
Foo "Bar" Baz "Quux"
As always, you can find all the details in the C# language spec.
We've got another C# language chat coming up tomorrow at 1pm (PACIFIC time).
Scott has posted all the relevant links and schedules but here's a
direct link to the actual entry for tomorrow's session. I won't be there but there will be plenty of team members chatting away...
One of today's questions had to do with how static fields work in generic types in the upcoming C# 2.0. For example, what would the output be from the following code?
using System;
class Gen<T> {
public static int X = 0;
}
class Test {
static void Main() {
Console.Write(Gen<int>.X);
Console.Write(Gen<string>.X);
Gen<int>.X = 5;
Console.Write(Gen<int>.X);
Console.Write(Gen<string>.X);
}
}
The correct answer is: 0050. The details can be found in section 25.1.4 of the ECMA C# Language specification:
A static variable in a generic class declaration is shared amongst all instances of the same closed constructed type (ยง26.5.2), but is not shared amongst instances of different closed constructed types. These rules apply regardless of whether the type of the static variable involves any type parameters or not.
We once again saw a few reports of folks running into the CS1668 warning every time they used the C# compiler when we released Beta 2. For those who use the /warnaserror+ compiler option, it blocks compilation as it gets promoted to an error.
To some users, this diagnostic comes as a surprise. We added it very early in the Whidbey (C# 2.0/VS 8.0) product cycle to help those who made a simple typo when modifying their LIB environment variable (or when using the /lib compiler option) but it's still a new thing to deal with for those trying out Whidbey for the first time. Tons of customers have yet to try Whidbey and their first experience with it will be with the final released version. So, I'm sure there will be some more who hit this in the future.
The unfortunate thing about this is that we've realized that uninstalling Visual Studio 2002 (v7.0) or Visual Studio 2003 (v7.1) will remove certain directories that were added to the LIB environment variable at install time. This leaves your LIB environment variable in a state that will cause the Whidbey compiler to warn you about it using the CS1668 diagnostic. Plenty of developers are familiar with environment variables in Windows and it shouldn't cost them more than a few seconds to get rid of the warning forever, but I've run into a few who weren't as familiar with it and it caused them some grief. The good news is that Whidbey no longer seems to modify these environment variables at install time, so we shouldn't run into a similar situation with future releases.
The warning looks as follows:
warning CS1668: Invalid search path 'foo' specified in 'LIB environment variable' -- 'The system cannot find the path specified.'
To fix this, one must remove the path that no longer exists on the machine from the LIB environment variable. Here are a couple of links to some online Windows documentation that cover the specifics for making these changes:
Today, I realized it had been a lot longer than I thought since I last posted on this blog. It's actually been over three months which just isn't all that cool. I haven't even been posting much on my personal blog which I used to keep at least somewhat active. I thought about it a bit and decided to try to post more often by just sharing a lot of the answers to C#/.NET related questions I answer every week from people internally and those in the community. Hopefully, that'll be something I get into a bit of a rhythm with and the answers will be useful to at least those using search engines. So that's my goal, we'll see over time if I can make it happen.
Another source I'll use for questions to answer are some of the questions that come in through the C# FAQ blog. From a quick look at the last few weeks worth of emails we've received through that site it looks like we're getting about 20-30 per week. Some have very little, if anything at all, to do with C# but there are definitely enough to use as seeds for future blog posts.
Also, I wanted to point to Peter's blog who has been pretty active lately and providing a bunch of really informative posts on C#. He definitely knows C# inside and out...
Rusty, my manager, seems to have started blogging again and I'd missed it so far. He's got some interesting posts so far. Here's a link to
his latest on how it's going with the MSDN Feedback site and how the community bug reports and suggestions compare to what happens internally...
Pete, our "box" QA guy, has started a blog where he plans on covering C#, testing, and plane-building. His first work-related post talks about QA signoffs and has plenty of info on how things get done. His first plane-building post is also very interesting. Recommended.
I also went ahead and updated my list of C# team bloggers post...
Spreading the word... Next C# Chat is on 4/21 at 1pm Pacific Time.
You can read all the details on Scott's post.
If you haven't already, be sure to check out the new MSDN forums site that just went up recently. It's got a ton of different message boards and there's already plenty of activity going on.
If you want to jump straight into the C# related forums, head over here.
Also note that each forum even has an RSS feed you can subscribe to to stay up to date. For example, here's the C# language feed.
