0.2.25 Submitting C# Code to the Feedback System

Submit the Current Version of the Required Artifact

The Feedback System can help you compare your current C# work with the requirements for the activity.

Before submitting anything, identify exactly what the activity asks you to submit.

Depending on the course task, that may be a specific source file or another course-provided project artifact.

Use the submission type named in the current activity.

Do not replace the requested source artifact with a screenshot simply because the code looks correct on screen.

Save Before You Submit

In Visual Studio, save the files you have changed.

Then build the solution.

If the build reports a problem, understand that problem before submitting unless the current activity explicitly asks you to submit a failing state for diagnosis.

A useful sequence is:

Edit → Save → Build → Confirm the required file → Submit

This reduces a common problem: submitting an older version that does not contain the edit you just made.

Choose the File Carefully

Course projects can contain many files.

If the activity asks for a particular C# file, locate that file in Solution Explorer and then find the saved file in the project location specified by the course.

Check the filename before submitting.

Two files can look similar while representing different parts of the project.

The Feedback System can only evaluate the artifact you actually provide.

Read Feedback Before Editing Again

When feedback appears, read the complete message.

Do not immediately make several changes.

First determine which part of the work the feedback is referring to.

For introductory C# work, the difference may involve things such as:

• required object creation;
• an expected value;
• a required field assignment;
• a missing statement;
• a statement in the wrong location;
• or a basic code-quality issue.

Use the current requirement to decide what the code is supposed to express.

The Feedback System identifies evidence about the submitted artifact.

The requirement still defines the intended result.

Connect the Message to the Source

Suppose you intended to create one Player object:

Player player1 = new Player();

and the feedback indicates the expected object creation is missing.

Return to the current source.

Ask:

• Is the statement present in the file I submitted?
• Is the correct type being created?
• Did I save the file before submission?
• Did I accidentally submit another file or older copy?

Those questions are more useful than rewriting unrelated code.

Revise the Source, Not the Feedback

The goal is not to make a message disappear by trial and error.

The goal is to improve the program so the source meets the requirement.

A strong revision cycle is:

Read the requirement → Read the feedback → Locate the related source → Make one focused correction → Save → Build → Submit again

That process keeps each revision connected to evidence.

Preserve Working Code

If the Feedback System identifies one problem, avoid “cleaning up” unrelated parts of the supplied project.

For example, do not:

• rename files because another name seems clearer;
• move code into new files;
• rewrite working statements in a different style;
• or add extra features that are not part of the requirement.

Focused changes make the result easier to understand and reduce the chance of introducing a second problem while fixing the first.

Use Visual Studio and the Feedback System for Different Evidence

Visual Studio can provide evidence about:

• whether the code builds;
• what values exist while the program runs;
• and where execution is paused.

The Feedback System can provide evidence about how the submitted artifact compares with the requirements it is designed to evaluate.

These tools answer different questions.

Use them together rather than treating one tool as a replacement for the other.

Keep the Current File as the Source of Truth for Your Work

After revising:

1. Save the edited source.
2. Build the current solution.
3. Confirm the filename you are submitting.
4. Submit that current file.
5. Read the new feedback as a fresh result.

Working carefully with one current source file makes technical feedback much easier to interpret.