Open a GitHub issue with:
- The IOViewer version (
ioviewer --versionor the package version). - The command line or API call used, with confidential values and personal paths removed.
- A minimal description of how to reproduce the problem.
- Expected and actual results, including relevant error messages.
Do not attach models if they contain confidential or customer data. A minimal description is better than sharing a confidential model.
Report security issues through GitHub private vulnerability reporting in the Security tab. Do not open public issues for security vulnerabilities.
Open an issue first for larger changes so the scope and approach can be discussed before implementation. Keep changes focused on the agreed problem.
Install the .NET SDK specified by global.json. It currently specifies
10.0.100, allows roll-forward to the latest feature band, and excludes
prerelease SDKs. Tests run on .NET 8 and .NET 10, so both runtimes are needed.
From the repository root, run:
dotnet build IOViewer.slnx -c Release
dotnet test IOViewer.slnx -c ReleaseThe library is in src/IOViewer, the CLI in src/IOViewer.Cli, and tests in
tests/IOViewer.Tests. Tests use small synthetic models built in code.
The repository ships no customer models.
The model data comes from the IOScene package. Directory.Packages.props
references it with a range such as [0.1.0-preview.1, 0.2.0-0): a patch of
IOScene is additive and a minor is breaking. NuGet restores the lowest version
in the range that it finds.
To build against an IOScene version that is not on nuget.org yet (an IOScene preview, or the lower bound itself before it is published), pack IOScene into a local folder and pass that folder:
dotnet build IOViewer.slnx -c Release -p:RestoreAdditionalProjectSources=<local-feed>
dotnet test IOViewer.slnx -c Release --no-buildFor a newer preview, also raise the lower bound of the range to it. Once a
restore has put the package in the NuGet global packages folder, later
restores, dotnet run of the tools and npm run e2e find it there. Do not
commit a nuget.config that points to a local feed, and commit a lower bound
only when that version is on nuget.org: until then, restoring the solution
fails in the CI build job, the Docs workflow and release.yml, so do not tag
a release before then.
The HTML viewer is a JavaScript project in src/IOViewer/Viewer (three.js,
bundled with esbuild). Its built script dist/viewer.js is committed and
embedded in the library, so .NET work does not need Node.js. To change the
viewer, install Node.js 24 and run from src/IOViewer/Viewer:
npm ci # exact versions from package-lock.json
npm run build # rebuilds dist/viewer.js
npm test # unit tests (node --test)
npm run e2e # builds, exports the fixtures with the CLI and runs Playwright (Chromium)Commit dist/viewer.js together with the source change: CI rebuilds it and
fails when it differs from the committed file. The end-to-end tests need the
.NET SDK and a Chromium for Playwright (npx playwright install chromium).
Fixtures are in tests/fixtures/viewer.
npm run perf runs the manual performance harness in a visible Chromium
window (for example PERF_LADDER=25000,200000 measures synthetic models made
by tools/SyntheticModel); its settings are described at the top of
test/perf/orbit.perf.js. It is not part of CI; include its numbers in the
pull request when a change can affect rendering speed. npm dependencies are
pinned to exact versions. When updating three.js (for example a Dependabot pull
request), also rebuild and commit dist/viewer.js and update the version in
THIRD-PARTY-NOTICES.md.
- Write all code independently. Do not use decompiled or leaked source code, proprietary headers, vendor SDKs or code copied from other viewers.
- The only third-party JavaScript in the generated HTML is three.js (MIT),
listed in
THIRD-PARTY-NOTICES.md. Discuss any other runtime dependency first and add its license there. The page must stay self-contained and work offline: no CDN, web fonts or network requests. - Do not add customer models, confidential data, vendor files or binaries to the repository. Keep private test files outside version control.
- Do not put personal data in code, documentation, test data or commit metadata. Use your GitHub noreply address as the commit email.
- Follow the surrounding code and repository formatting settings.
- Keep nullable reference types enabled.
- Warnings are treated as errors.
- Write short English comments that explain why.
- Document new and changed public APIs with XML documentation comments.
- Do not write console output from the library. Only the CLI writes to the console, with diagnostics on standard error.
- Do not add runtime dependencies to the library without discussing it first.
Include:
- A description of the problem and the change.
- Tests for behavior changes, including relevant errors and edge cases.
- The build and test commands run, their results, and any skipped checks.
- A note on how the generated HTML changes when the viewer template is affected.
Write commit messages in the imperative mood, for example, "Fix section box clipping on rotated models".
Push a tag matching the package version, such as v0.2.0, to run release.yml.
The workflow builds and tests the solution, publishes the NuGet packages through Trusted Publishing, and then attaches
packages, symbols, source and checksums to a GitHub release, marked as a prerelease when the version has a hyphen
(v0.3.0-preview.1). The release notes are the section of CHANGELOG.md for the version, so add that section before
the tag; the workflow stops before publishing when it is missing.
The NuGet policy must name this repository, release.yml, the configured NuGet profile and the IOViewer* package pattern.
Contributions are licensed under the MIT license. By submitting a contribution, you confirm that you have the right to contribute it under that license.
Ask questions in GitHub Discussions or repository issues.