When you open a new C# Windows Forms Application project in Visual Studio 2008, you get a lot of autogenerated code (AssemblyInfo.cs, Resources.Designer.cs, Settings.Designe
The auto-generated files:
AssemblyInfo.cs : the attributes inside it are set by Project + Properties, Application Tab, Assembly Information button. Editing the file directly is okay, the IDE doesn't easily get confused by it.
Settings.Designer.cs : auto-generated from the Settings.settings file which in turn is generated from the Settings designer. Any edits to this file will be lost quickly.
Resources.Designer.cs : auto-generated from the Resources.resx file which in turn is generated from the Resources designer. Any edits to this file will be lost quickly.
Form.Designer.cs : auto-generated by the form designer. Editing this file is possible, there is no independent file that stores the form layout. The design view is generated by running this code at design time and using Reflection to recover the form and control properties. And saved again when you close the designer, it re-generates the InitializeComponent method and the control variables. Getting your code changes to survive this process requires writing the code exactly the way the designer itself would. Which is fairly untrivial when you make changes beyond simple property value changes. There's also considerable risk, an unwise change can easily cause an exception. When that happens at design time, you get the infamous WSOD (White Screen Of Darn) which displays an often very cryptic exception and tells you that you cannot design your form anymore.
You can learn more about the way the designer generates code by observing the changes it makes to InitializeComponent when you modify the form in the designer. Getting this right is certainly not beginner material, you are probably have more pressing things to learn while you get up to speed on .NET programming. The designers are there to make your life easier and to minimize the risk of getting it wrong.