Build Postman Clone with Tim Corey

Course Overview and Purpose

Tim starts by explaining that this lesson is about setting up the initial structure needed to build a Postman clone. He clearly states that the focus is not on making API requests or handling JSON responses yet, but rather on creating the projects, configuring them correctly, and getting everything ready to work.

He explains that this course is designed to help users understand how a real-world tool like Postman could be built as a simple Windows application. While the final app will not replace Postman, it will demonstrate core concepts such as REST requests, responses, and UI design. Tim also explains that while this project can inspire portfolio work, users should not copy it directly. Instead, they should enhance and modify it to create something uniquely their own.

Creating the Class Library for the Postman Clone

At this point, Tim opens Visual Studio 2022 and begins the setup process. He explains that he is using the latest version available at the time of recording and starts by creating a new project. For this lesson, he chooses to create the class library first.

Tim explains that this class library will eventually hold shared code that the UI will reference. This approach helps separate concerns and keeps the application organized. He also explains that while the order of project creation does not usually matter, starting with the library allows him to demonstrate a common issue that developers may run into during setup.

He searches for a C# class library and emphasizes that it must be a modern .NET project, not the older .NET Framework. Tim selects a .NET 8 class library, noting that newer versions such as .NET 9 or later can also work. He explains that differences between versions are a normal part of development and that learning how to adapt is an important skill.

Naming the Solution and Projects Correctly

Tim spends time explaining how he names the solution and projects. He names the solution as the Postman clone app and the library as the Postman clone library. He explains that including the word "Library" makes it very clear which project contains shared logic and which project contains the UI.

This naming approach helps when working with references later. Tim explains that references should always flow from the UI to the library, never the other way around. This design choice supports cleaner code and a better long-term development process.

He also explains why he does not place the solution and project in the same directory. Since this app will contain multiple projects, separating them makes navigation easier and avoids confusion as the solution grows.

Adding the Windows Forms UI Project

Once the library is created, Tim adds a second project to the solution. This time, he selects a Windows Forms application. He explains that this project will serve as the UI for the Postman clone and will eventually allow users to enter URLs, query parameters, and view responses.

He names the project Postman clone UI and again confirms that it is using .NET 8. Tim briefly addresses a DPI-related message caused by display scaling. He explains that this is not important for this lesson and that DPI handling can be explored later if needed.

At this stage, the solution now contains two projects: a library and a Windows Forms UI. This structure sets the foundation for building a Postman-style tool on Windows.

Fixing the Startup Project Issue

Tim demonstrates an issue that occurs because the class library was created first. When he tries to run the solution, Visual Studio shows an error stating that a class library cannot be started directly.

Tim explains that this is a common setup problem and emphasizes the importance of reading error messages carefully. He explains that error messages often tell you exactly what is wrong and how to fix it.

He shows two ways to resolve the issue: setting the UI project as the startup project using the context menu, or selecting it from the startup project dropdown near the Run button. Once this is done, the Windows Forms UI launches correctly.

Adding the Project to Git and GitHub

With the solution structure in place, Tim moves on to source control. He opens the Git Changes window and explains that version control has not been enabled yet. He creates a Git repository directly from Visual Studio.

Tim explains the purpose of the .gitignore file, stating that build outputs such as compiled files should not be included in source control. Since these files can be recreated, they do not belong in a GitHub repo.

He also discusses licensing and explains that choosing no license means retaining all rights to the code. Tim adds a README file and explains how important it is for explaining the project, especially if it will be shared or used as part of a portfolio.

Tim names the GitHub repository, adds a clear description explaining that this is a Windows Forms recreation of Postman, and chooses to keep the repository private so users focus on learning rather than copying code.

Understanding Source Control Indicators

After pushing the code to GitHub, Tim explains the lock icons shown in Solution Explorer. These icons indicate that files are tracked by source control and have not been modified.

He explains how these indicators change when files are added or updated, helping developers understand what changes will be committed. This visual feedback becomes very useful as the project grows and more features are added.

Keeping Class1 and Adding a Reference

Tim explains why the default Class1 file is left in the library for now. Without at least one class, the library would not have a namespace, making it impossible to reference from the UI.

He then adds the library as a dependency of the UI project. Tim demonstrates both dragging the library onto the UI dependencies and using the Add Project Reference option. This step allows the UI to access shared code, which is essential for building a structured Postman clone.

Renaming Form1 to Dashboard

Tim renames the default Form1 to Dashboard, explaining that this form represents the main screen of the application. When this form closes, the application closes as well.

He ensures that all references are updated correctly, including the code-behind file and Program.cs. Tim also converts the namespace in Program.cs to a file-scoped namespace, explaining that this provides more space and cleaner formatting for future changes.

Adjusting UI Properties and Font Settings

Tim opens the Dashboard form and focuses on the Properties window. He explains how developers can reposition windows inside Visual Studio to match their workflow.

He changes the form title to clearly identify the application as a Postman clone and increases the default font size from 9 to 18. Tim explains that setting the font size early ensures consistent sizing for all future controls added to the UI.

Committing the Initial Setup

With all setup changes complete, Tim stages the modified files and creates a commit. He explains that the commit message does not need to be perfect but should clearly describe the setup changes.

He commits and synchronizes the code with GitHub, ensuring the repo is fully updated and ready for continued development.

Preparing for the Next Step in Building the Postman Clone

To wrap up the video, Tim explains that the project setup is now complete. In the next lesson, the focus will shift to building the UI and creating a simple way to send GET requests to an API and display responses.

He encourages viewers to attempt the next step on their own before watching the next video. The goal is to create a simple interface that can send requests, receive data, and display formatted JSON responses. This approach helps users better understand the process and prepares them to enhance the application over time.

Tim closes by reminding viewers that this project is meant to grow. Starting with a simple setup allows developers to build confidence, understand the workflow, and gradually turn the project into a meaningful Postman-style tool.