WGU C969: Software II – Advanced C#
C969 Software II – Advanced C# is not a multiple-choice exam. You build and submit a working desktop scheduling application backed by a MySQL database, with login, customer and appointment management, time zone handling, and reports. This guide covers what the assessment asks for, how long it realistically takes, and what gets submissions returned.
What C969 Actually Is — and Why It Feels Different
Software II – Advanced C# (C969) is the course where WGU stops asking you to answer questions about programming and starts asking you to ship software. It sits in the Software Engineering and Software Development C# tracks, normally right after Software I (C968), and it is where object-oriented C# collides with a real relational database, real user authentication, and real-world messiness like time zones and localization. If you are staring at this course wondering why it feels heavier than everything before it, that instinct is correct — it is a build, not a test.
Direct answer: You pass C969 by building the scheduling application exactly to the written requirements and submitting it, not by studying for a test. Work the requirements document as a literal checklist, implement one lettered requirement at a time, and verify each one by actually clicking through your app before you move on.
The scenario is consistent across public descriptions of the assessment: you are contracted to build a desktop scheduling user interface for a global consulting organization that conducts business in multiple languages and has main offices in Phoenix, Arizona; New York, New York; and London, England. The organization supplies a MySQL database that your application reads from and writes to — and whose structure you are not permitted to change. Users log in. Customer records get created, updated, and deleted. Appointments get scheduled, checked against business hours, and displayed in the user's local time. The system warns a user about an appointment starting soon, produces a handful of reports, and quietly logs every login attempt to a text file.
That combination is the point. C969 is the first course in the track where the evaluator is not checking whether you understand a concept in isolation — they are checking whether you can hold a dozen small requirements in your head at once and satisfy every one of them in a single working program. That is genuinely what junior developer work looks like, which is why the course matters even though it is stressful.
What the Performance Assessment Asks You to Build
C969 is assessed entirely by performance assessment. There is no proctored multiple-choice exam to schedule. You submit source code and supporting evidence that the application runs. The requirement areas that appear consistently in public descriptions of the project are:
- Log-in form — authenticates a user against database credentials and determines the user's location so the interface can respond appropriately.
- Localization — the log-in interface adapts to the user's language or region setting rather than being hard-coded to one locale.
- Customer record management — full create, read, update, and delete behavior against the supplied MySQL customer tables, with validated input and no schema changes.
- Appointment scheduling — add, edit, and remove appointments, with calendar views that can be filtered by month and by week.
- Time zone handling — appointment times stored consistently but displayed in the viewing user's local zone, with business-hours rules enforced against the correct zone.
- Overlap and validation rules — preventing appointments that collide with existing ones or fall outside allowed business hours.
- Alerts and reminders — notifying the logged-in user, on log-in, of an appointment starting within roughly the next fifteen minutes.
- Exception handling — graceful, user-readable handling of bad input and database problems instead of crashes.
- Reports — generating several summary views from your data using collection classes and querying.
- Log-in activity file — appending a timestamped record of each log-in attempt to a plain text file.
Verify the exact wording, including the alert window and the required report list, in your own course materials before you build. Requirement documents get revised, and the version on your WGU course page is the only one that counts.
How Hard It Is, and How Long to Budget
Many students report that C969 is one of the harder courses in the C# track — not because any single piece is conceptually difficult, but because the requirement list is long and unforgiving. If you came out of C968 comfortable with Windows Forms, classes, and exception handling, the genuinely new material here is mostly the database layer and date/time conversion.
Students commonly describe finishing in a few weeks of steady evening work, with the range widening sharply based on prior experience. If you have written C# professionally, it can move fast. If C968 was a struggle, plan for longer and do not treat that as failure — this course punishes rushing far more than it punishes slowness. The two time sinks students mention most often are getting the MySQL connection configured correctly at the start, and untangling UTC-versus-local time near the end.
Budget deliberately: a weekend to get the database connected and a login working, about a week for customer and appointment CRUD, several days for time zones and validation rules, and a final pass for alerts, reports, logging, and cleanup. Building in that order means every later piece has something working to sit on top of.
A Build Plan That Actually Works
Studying for a build course looks different from studying for an objective assessment, but the same learning science applies — you just apply it to code instead of flashcards.
Turn the requirements into a literal checklist. Copy each lettered requirement into a document or issue tracker. Nothing gets checked off until you have run the app and watched that behavior happen. This single habit prevents most returned submissions.
Practice retrieval on the pieces you keep re-searching. If you look up parameterized query syntax or DateTime conversion three times, write it once from memory the next day without looking. The parts of C969 you have to re-derive under pressure are the parts you have not learned yet.
Build vertical slices, not layers. Get one customer record all the way from a database row to a form field and back to the database before you build the appointment side. A thin working path end to end teaches you more than three half-finished layers.
Test as you go, in small deliberate passes. After each requirement, try to break it: empty fields, absurd dates, an appointment at 3 a.m., a duplicate booking. Spaced re-testing of earlier features catches the regressions you introduce later.
Store times in UTC and convert only at the edges. Decide this on day one. Retrofitting time zone correctness into an app that stored local times is the single most common source of late-course pain.
Explain your own code out loud. If you cannot narrate what a method does and why, you do not own it yet — and you may be asked to demonstrate understanding of what you submitted.
If your programming footing feels shaky, reviewing fundamentals helps here; many students revisit D278 Scripting and Programming material before starting. Those continuing in the track will meet similar rigor in D385 Software Security and Testing, and version control habits from D197 Version Control pay off directly on a project this size. You can browse the full School of Technology hub or the complete guide index for related courses.
Where C969 Submissions Go Wrong
- Skipping a requirement entirely. Usually the log-in text file or one of the reports — small, easy, and forgotten because it is not visually obvious.
- Treating time zones as a display problem only. Business-hours validation must respect the correct zone, not just the label shown on screen.
- Swallowing exceptions silently. Empty catch blocks technically prevent crashes but fail the intent of the requirement, which is a clear message to the user.
- Weak input validation. Blank names, malformed phone numbers, and end times before start times all need to be caught and explained.
- Altering the supplied database. The schema is given to you deliberately; work with it rather than reshaping it to suit your code.
- Hard-coded connection strings scattered through forms. Centralize your data access; it makes the code readable and reduces breakage.
- Copying someone else's project. Public repositories of past student work are everywhere, and submitting from them is an academic integrity violation with serious consequences. WGU expects original work and checks for it. Read a repository to understand an approach if you must, then close the tab and write your own.
- Submitting without a clean run. If it does not build from a fresh checkout on your machine, it will not build on the evaluator's.
C969 Readiness Checklist
- Can you launch the application, log in with database credentials, and see both failed and successful attempts appended to your log file?
- Can you show the log-in interface responding to a different language or locale setting?
- Can you add, edit, and delete a customer and confirm the change persisted in MySQL, not just on screen?
- Can you schedule an appointment, then view it correctly in both a month view and a week view?
- Can you demonstrate that an appointment created in one time zone displays properly for a user in another?
- Can you attempt an overlapping appointment and an out-of-business-hours appointment and get a clear rejection message for each?
- Can you trigger the upcoming-appointment alert on log-in with a test record timed just ahead of you?
- Can you generate every required report and explain which collection or query produced it?
- Can you walk through your requirements checklist and point to the exact code satisfying each line?
C969 FAQ
Is C969 an OA or a PA?
It is a performance assessment. You build and submit a working C# desktop application rather than sitting a proctored objective exam, so there is nothing to schedule with a proctor.
How hard is C969 compared to C968?
Many students describe it as a clear step up. The C# skills carry over from Software I, but the added database layer, authentication, and time zone requirements make it a longer and more detail-sensitive project.
How long does C969 usually take?
Reported times vary widely with prior programming experience. Steady daily work over a few weeks is a common pattern; students new to databases should plan for more, especially for the initial MySQL setup.
Do I need to know SQL before starting?
Basic SQL helps a great deal. You do not need advanced database design, but you should be comfortable with select, insert, update, and delete statements and with connecting an application to a database.
What causes a C969 submission to be returned?
Most commonly a missed requirement, incomplete validation or exception handling, or time zone behavior that does not hold up under testing. Working the requirements as a literal checklist prevents nearly all of it.
Can I use a different framework or language?
No. Follow the technology stack your course requirements specify. Substituting frameworks is one of the fastest ways to get a submission sent back, regardless of how well the app works.
For official course details, always confirm against your program materials on wgu.edu. This guide is an independent study resource and is not affiliated with or endorsed by Western Governors University.
Want a human in your corner for C969?
Book 1-on-1 OA prep coaching, a tutoring session or a study-plan review with our team.