The accepted answer doesn’t really answer the question; it just explains why this behavior is occurring.
Some of the other answers propose solid workarounds, but I’ve found that the best solution really is to create a base form that all of the forms in your application inherit from and set this base form’s Font property to SystemFonts.MessageBoxFont in the constructor. This not only ensures that your application picks up the correct font at run-time, based on the user’s environment (heading off the potential problem posed by Hans Passant—an XP without Office 2007 will resort to Microsoft Sans Serif in the absence of Segoe UI), but also gives you design-time support for your current Windows font. Using the correct font at design time solves the problem Josuegomes points out, because any container control that is created on the form will pick up the font used by the form at design-time.
Besides the above advantages, this frees you from having to remember to modify the constructor for each form that you create and ensures consistency across all of the forms in your application, as well as giving you a place to put other common functionality. I use this in a couple of different ways such as p/invoking, etc. to fix bugs in the WinForms implementation.
The only problem that remains with this approach is if you want to set a font style for a particular control, such as bold. The best place to do this is still in that form’s constructor, starting with the form’s font as a base and modifying the style from it:
myControl.Font = New Font(Me.Font, FontStyle.Bold)