Blog link of the week 18

Sun, May 8, 2005, 05:13 PM under Links
James gives some insight to what it's like preparing MEDC.

David and Scott inform us of their sessions (both of them in my top 3 choices) and provide interesting links.

OT: I just came back from a trip to the Grand Canyon and I'll tell you the obvious: it is massive and as they say round here...awesome! No picture or video can capture it but I'll have photos soon at the usual place.

Leaving for Las Vegas

Fri, May 6, 2005, 09:33 PM under Personal
Leaving in half an hour for the airport to fly to Vegas for MEDC. Back in a week.

Unless something goes horribly wrong, I will be blogging throughout the conference reporting my views, photos or whatever.

Stay tuned!

PS If you are going to be there and wish to hook up and talk geek, this is what I look like:

1. Taken a decade ago but not far from the truth
2. Dancing under the sun in Ios
3. Playing chess
4. Favourite non-tech past time

Attributes in properties of code file

Fri, May 6, 2005, 10:57 AM under Whidbey | VisualStudio
The more I use VS2005 Beta 2 the more I come across (little) new things.

Make sure you have the properties window open/docked (you know, the one where you usually change the properties of controls).

Open a code file (i.e. a class) and place the cursor on the class declaration. Look in the properties window. You can toggle the 3 boolean combobox options to insert/remove the 3 corresponding attributes: COM Class, COM Visible and Serializable.

This appears to be a VB thing only. It's been a while since I said that in a positive way :-)

Now, would the VSD (Visual Studio for Devices) team please remove the Serializable option, as it does not apply to CF?

Marshal.PreLink

Fri, May 6, 2005, 12:19 AM under MobileAndEmbedded
All Compact Framework developers know that without pinvoking you cannot author any serious CF 1.0 application.

We've all been in the situation where we have declared a function from coredll.dll (or some other native dll) and when we called it we got the infamous MissingMethodException (meaning the DllImport declaration was wrong). That is the only way to find out, try it and see.

Well, CF 2.0 gets support for a method that is already in there in the full desktop .net framework version 1.1. The method in question is Marshal.PreLink/PreLinkAll. It basically verifies that your dllimports have been declared properly, e.g.
static void Main() {
// Assuming all your dllimports are in Form1
System.Runtime.InteropServices.Marshal.PrelinkAll(typeof(Form1));
Application.Run(new Form1());
}

My suggestion is to still test the methods explicitly from your code, but I will be using this shortcut when in debug mode; it's a sweet little time saver :-)

SuppressMessage not in CF

Thu, May 5, 2005, 01:52 PM under MobileAndEmbedded
As you may have noticed, in VS2005 you can turn static code analysis on via the project properties ("Enable Code Analysis"). Many of the rules are just guidelines and do not qualify as warnings. There should be a separate category, maybe called *recommendations*. However, that is not the point of this blog post.

Fortunately, you can suppress warnings simply by right clicking on them and choosing "Suppress". What that does is to add an attribute to the line of code that breaks the recommendation so next time you compile/build, the annoying warning will not appear in the error list. The attribute is the System.Diagnostics.CodeAnalysis.SuppressMessageAttribute (it applies only if the compilation constant CODE_ANALYSIS is defined)

Example:
// no comments on the content of the method please
public void SomeMethod(bool b, object o) {
if (b) {
((EventHandler)o).Invoke(null, EventArgs.Empty);
} else {
((EventHandler)o).BeginInvoke(null, EventArgs.Empty, null, null);
}
}
One of the 4 warnings you'll see for the method above is the following:
CA1800 : Microsoft.Performance : 'o', a parameter, is cast to type 'System.EventHandler' multiple times in method Class1.SomeMethod(Boolean, Object):Void. Cache the result of the 'as' operator or direct cast in order to eliminate the redundant castclass instruction.

So, you bring up the contextmenu for the item in the "Error List", select "Suppress message" and life is good again.

So where is the problem? As the title of this entry suggests, the attribute is not supported by the Compact Framework (at least in Beta 2) and doesn't compile:
The type or namespace name 'CodeAnalysis' does not exist in the namespace 'System.Diagnostics' (are you missing an assembly reference?)

There are two issues with that:
1. You cannot suppress those annoying recommendations warnings that shouldn't be there in the first place.
2. If you are sharing code between the full and compact frameworks, you'll get compilation errors.

There is nothing you can do about the 1st one (apart from vote for it).
For the second, as you know, you can use conditional compilation. However, in this case I'd go ahead and define the attribute in code in your CF projects, so at least you get past the compilation problem. Define it like this:
namespace System.Diagnostics.CodeAnalysis {
public class SuppressMessageAttribute : Attribute {
public SuppressMessageAttribute(string category, string checkId) {}
}
}

Note, I tried implementing the attribute fully but the warnings were still not suppressed so the bare minimum skeleton as above is good enough to at least get us past the compilation errors

CLSCompliant now works

Tue, May 3, 2005, 02:02 PM under Whidbey | VisualStudio
VB Class Library projects are marked at the assembly level with CLSCompliant (while in C# you have to add it yourself). The most important reason for turning it on in your C# library projects is so that you don't accidentally expose case sensitive *publics*; not only this is not CLS compliant, but it would render your assembly unusable by VB code.

So, while it is bizarre that the option is not turned on for C# by default and it is for VB, it makes no difference because it has no effect for VB projects! The situation changes with Whidbey, where suddenly it works as expected. I guess it got noticed when VB got support for unsigned types (also not CLS compliant).

How did I find out? Some of my assemblies are exposed to VB6 clients, so I have public interfaces starting with an underscore (representing the default interface) and other starting with double underscore (representing the default events interface). When I upgraded them to VS2005 B2, I got a whole bunch of CLS compliancy errors (no public types may start with _). BTW, my solution was to mark them as CLSCompliant(false) rather than tweak the public interfaces and then have to modify all clients too.

FYI, with Whidbey, the C# team persists with their choice of not marking the C# projects with the CLSCompliant attribute by default... is that arrogance?

Synchronize Class View

Mon, May 2, 2005, 11:59 AM under Whidbey | VisualStudio
When in the code editor of Visual Studio, one of the items I use most on the context menu is the "Synchronize Class View" menu item. As you expect/know, it activates the "Class View" docked window, expanding the tree nodes as appropriate and selecting the item which you have the cursor on in the code. I love this feature, and my jaw dropped when I couldn't find it on the VS2005 context menu!

I quickly went through the top level menus and their children trying to find where this option lives; no joy. Since every action in VS has a keyboard shortcut, I thought I'd go to the Tools->Options->Environment->Keyboard and see if I can find it that way. Lo and behold, it appears as the 5th item in the auto-filtered list as soon as I type "Sync": View.SynchronizeClassView. I cancel the Options dialog with a smile :-)

Armed with this knowledge (i.e. that the option lives under View), I can add the option to the context menu. Here are the steps, if you wish to do the same:
1. Select Tools->Customize
2. On the Toolbars tab, check the "Shortcut Menus" item
3. Observe how 6 drop down menus appear on the toolbar, the first one being "Editor Shortcut Menus"
4. Still in the Customize dialog, select the "Commands" tab, select "View" on the left and locate on the right the "Synchronize Class View" item.
5. You can now drag the item to the "Editor Shortcut Menus" and drop it wherever you want (I placed it on top of "Go to Definition")
6. Close

Editor life is back to normal again...

Blog link of the week 17

Sun, May 1, 2005, 03:28 PM under Links
* The debate that never ends: VB vs C#

* Message to the VB team: Remove the crutches (why do I think that falls on deaf ears?)

* "Hello world" with code coverage

* I didn't know that either! I'll have to revisit those remoting projects, where I needed to debug server and client at the same time!

New Compilation Constants

Sat, April 30, 2005, 05:45 PM under Whidbey | VisualStudio
Dotnet projects have at least two configurations: Debug and Release. Part of the configuration is the definition of two compilation constants: DEBUG and TRACE. For Debug configurations, both constants are on; for Release, only TRACE is on. I always turn TRACE off as well, and I advice you to do the same (however, that is not the point of this blog entry).

You can tweak these in your project properties (they are represented by checkboxes) and you can also add your own in the textbox offered or you can define them in code (#define or #const, depending on your language of choice). An example of why you would add a compilation constant is for cross platform development, as detailed before.

For conditional compilation you use #if. In C#, the code that does not apply gets greyed out. This is really sweet and somehow I thought it was added to the VB2005 IDE, but unfortunaly I realised recently it wasn't :-(
Go vote for it (maybe it will make the Orcas release).

In VS2005 we find a few additional conditional compilation symbols that are not in VS.NET 2003 (applicable or not, based on what project type you chose and what language you are developing in):
DEBUG
TRACE
CODE_ANALYSIS
PocketPC
WindowsCE
Smartphone
TARGET
CONFIG
VBC_VER
_MyType

I'll let you figure out what each one is used for and the potential values they can have ;-)

Tiny (but positive) change

Fri, April 29, 2005, 01:09 PM under Whidbey | VisualStudio
Just noticed a infinitesimal change in VB code with Whidbey that will make copying pasting from C# to VB and vice versa require one less thing to look for.

As you know, code for properties in VB is autogenerated:
Public Property SomeProp As String [hit enter here]

The setter looks like this in VS.NET 2003:
Set(ByVal Value As String)

In VB2005 Beta 2 it looks like this:
Set(ByVal value As String)

Seems like the VB team had their ear pulled by the coding/naming guidelines department :-)