Menu strip is not shown in form designer, even though its code exists

Sometimes a WinForms app gets corrupted, and you can't get the design-time view of a Form, or UserControl, to appear correctly, but you do, as you show here, have what looks like a valid Designer.cs file, and valid code-behind pages.

I've found this strategy useful:

1. immediately make a back-up copy of the whole Application.

2. close the Project/Solution, and try re-opening it: if that doesn't work, quit Visual Studio, re-open it, and reload the Project/Solution: if that doesn't work then:

3. create a new VS Solution, and ... in this case ... drop a MenuStrip on it, then copy the Designer.cs file, and close the Solution, and paste the Designer.cs file copy in a text editor: compare its structure carefully with the structure of the Designer.cs file that you know is not working for you (not giving a proper design-time view). If you're lucky, you just might find some key difference, a difference that can be fixed. But, if that fails:

4. you could try modifying your back-up copy step-by-step until you have a working app, and then try re-creating only those parts of your app that refuse to give you the design-time view you expect. or: if that doesn't work:

5. create a new Project/Solution: re-create the Forms, UserControls, etc. you had in the original Project/Solution: drop the same Controls on the Forms or UserControls. Make sure NameSpaces, Form Names, etc. are all the same as the Project/Solution you are trying to salvage.

Open the Designer.cs files of the Forms or UserControls in the new Project, and paste in the saved code. open the code-behind pages for UserControls, and Forms, and paste in the saved code.

While #5 is an extreme measure, it has worked for me the few times I've had to do it.

Hopefully, if you have Class files (all code, no GUI), those can be left untouched and restored easily.

good luck !

Some addition to the advice by Bill (Solution 2).

• Instead of back-up, it should be a use of some Revision Control System, committing in small steps, to be able to trace back back by any number of steps. These days, not using Revision Control System is a crime against yourself.
  
  Please see:
  Revision control systems, which to choose from?[^],
  Needs some words of wisedom to set up and/or use a server[^]
• Don't overuse the designer. Some add tens of text boxes manually. This is tedious and error-prone. All periodic work should be done in code. For example, if you need and array of text boxed, use array in first place, not individual controls. Then you will be able to use loops.
• Never use auto-generated names. They violate (good) Microsoft naming, which is even good: it tells you what controls you did not put to use yet. When you put then to use, always give them all semantically sensitive names. How do you think, what is the refactoring engine for?
• Add more files with partial declarations of the same form class (or user control, for that matter). There is a problem, though: on click, stupid designer will open a different non-existing "form". It won't hurt much but is confusing. My own trick is: add ".designer" for the name. For example, you have the form file "MyForm.cs". Add a new partial declaration in a file named like "MyForm.Setup.designer.cs", "MyForm.Actions.designer.cs", "MyForm.Threds.designer.cs". It works and is very convenient.
• If you are lost, but just a bit, don't be afraid to go to auto-generated file (do the opposite to what sjelen advices in a comment to the question). For example, this is the easiest way to remove some incorrectly placed control which is hard to find and click in it under the designer.
• Use if (DesignMode) { DoSomethingComplex(); }. It will protect your designer from not showing a form. During development, you can make some mistake, and it will render your form not showing. Do it under the check of DesignMode:
  http://msdn.microsoft.com/en-us/library/system.windows.forms.control.aspx[^].
• And, finally, my very own approach in the style of "don't overuse the designer". Note that some members criticized my approach, so decide by yourself.
  
  My rule is: "never add any event handlers in the designer". Here is why: writing the handler in code is way more maintainable (in a separate partial declaration part, a separate file), if you use anonymous syntax:
  
  C#

  myControl.MouseDown += (sender, eventArgs) => {
      DoSomething(eventArgs.X, eventArgs.Y);
  };
  
  // or, good for C# v.2:
  
  myControl.MouseDown += delegate(object sender, MouseEventArgs eventArgs) {
      DoSomething(eventArgs.X, eventArgs.Y);
  };

  
  
  Among other benefits, it decouples delegate from some "semantic" handler methods, reducing passing of the unused arguments and putting all code under your control.
Good luck,

—SA

thx everybody. I added these lines to Form.Designer.cs file and my problem fixed.

this.menuStrip1 = new System.Windows.Forms.MenuStrip();
 this.menuStrip1.BackColor = System.Drawing.Color.Transparent;
 this.menuStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] 
  { this.Main,this.ReportsTSM });
 this.menuStrip1.Location = new System.Drawing.Point(0, 0);
 this.menuStrip1.Name = "menuStrip1";
 this.menuStrip1.RightToLeft = System.Windows.Forms.RightToLeft.Yes;
 this.menuStrip1.Size = new System.Drawing.Size(589, 24);
 this.menuStrip1.TabIndex = 10;
 this.menuStrip1.Text = "menuStrip1";
 this.menuStrip1.ResumeLayout(false);
 this.menuStrip1.PerformLayout();

 this.Controls.Add(this.menuStrip1);

 private System.Windows.Forms.MenuStrip menuStrip1;