From the developer to the customer
The application starts without trouble on its developer's computer. On a new workstation, something is suddenly missing. Perhaps a different runtime is installed; perhaps a required directory exists only on the original machine. That distinction offers little comfort to the customer: the software does not work as expected.
I would therefore ask not only whether the program runs, but whether its build and prerequisites can be handed over clearly. A working environment configured once is not yet a dependable delivery process.
The current prompt: dotnetup
On 15 October 2026, Microsoft introduced the public preview of dotnetup. It manages .NET SDKs and runtimes in the user account, particularly on macOS and Linux, and respects project-specific version requirements. It is neither a mandatory development standard nor a recommendation to change existing installations without assessment. [1]
It provides a useful prompt for a broader issue: the environment, not just the source code, must be describable.
Three versions, three different questions
In .NET, distinguish the development tools, the application's target and the runtime used at startup. Microsoft documents their selection separately. A global.json can influence SDK selection; it does not describe every product dependency. [2]
For a handover, I would therefore write more than “requires .NET”. Record the actual prerequisites, supported operating systems and intended installation method. The same principle applies beyond .NET.
A clean environment is the more honest test
My most important test location would be an appropriate separate system without the development machine's accidental conveniences. Use the intended delivery package there, not files collected and repaired by hand afterwards.
I would check installation, first launch and essential workflows under the intended user permissions. Required configuration needs explanation. Personal credentials, local file paths and test passwords must not silently become product prerequisites.
Specifying versions does not mean freezing them forever
Traceable versions help recreate a development state. To me, that does not mean keeping every dependency unchanged indefinitely. Specifying versions also requires a plan for security fixes and compatibility.
I would assess related changes together and record which versions the delivered package contains. An automated build can help perform recurring steps consistently. Its success alone does not prove that the application works on a customer's machine under the intended conditions.
Updating the developer's computer does not patch shipped copies
Microsoft explicitly notes in its dotnetup announcement that self-contained applications carrying their own runtime need to be republished and redeployed with the updated runtime. Updating the developer's machine does not patch copies already shipped. [1]
For me, that creates a straightforward organisational requirement: identify the product version delivered and how a corrected package will reach its users. Changing a local version without delivering a new package does not solve that problem.
What belongs in a handover?
I would expect an identifiable delivery package, its prerequisites, concise operating instructions and a defined support route. Server-backed software also needs configuration, required counterpart services and responsibilities. Secrets should be handed over separately and securely, not published in general instructions.
My conclusion
“It works on my machine” is a starting point, not completion. Professional development makes the route from source version to usable product traceable and checks the result where it is expected to operate.
This article discusses design and handover. It does not authorise installing preview software or establish that a particular customer product has already passed such checks.
Sources and context
Research date: 23 October 2026. Vendor publications are not independent product tests. Examples and recommendations are identified as such in the article.
[1] Microsoft: dotnetup public preview, 15 October 2026
Read source ↗
[2] Microsoft Learn: SDK, target and runtime version selection
Read source ↗