Project folder

graph TD
  P[Project folder] --> A[name.acproj]
  P --> S[source: database sources]
  P --> D[delivery: delivery settings]
  P --> B[build: output, not versioned]
  P --> O[obj: working state, not versioned]
  S --> BC[build: configuration with ACCDB and ACCDE]
  D --> BD[build: Delivery and mode with starter and deploy]
  B --> BC
  B --> BD

A WKL Office SDK project is a folder that contains a project file. This page shows which files live in it, which of them belong under version control, and which command writes each one. Each file's details are on its own reference page.

• Sources, not a database. You version the project file, source\, and delivery\. Every build creates the database again from the sources.
• Output and working state stay local. build\ and obj\ are listed in the .gitignore that new creates.
• Shared items live outside. Shared templates and release packages are found through the SDK settings or environment variables, not copied into the project.
• Your own folder names. source\, build\ and delivery\ are defaults; the project file can name other folders (SourceRoot, BaseOutputPath, DeliveryRoot), and for new projects you choose them in the SDK settings.
• No secrets in the folder. Certificates are referred to only by their thumbprint.

<project folder>\
  <name>.acproj                    project file
  .gitignore                       build/ and obj/
  .vscode\tasks.json               tasks for Visual Studio Code
  source\                          sources of the database (folder set by SourceRoot)
    references.json
    ...
  delivery\                        delivery settings, versioned (folder set by DeliveryRoot)
    delivery-settings.json
    <profile>.profile.json
    <profile>.bootstrapper.json
  build\                           results, not versioned (folder set by BaseOutputPath)
    <configuration>\
      <name>.accdb
      <name>.accde
    Delivery\<profile>\
      Wkl.Bootstrapper.exe
      bootstrapper.json
      deploy\
  obj\                             state of this workstation, not versioned
    wkl-state.json
    wkl-sdk.lock

• The original database does not go into the repository. Export an existing ACCDB once, with export -d, from where it lives now into the sources (tutorial), or with New project from this database… in the add-in. migrate creates a new project in an empty folder. From then on, the database is a build output.
• build\ and obj\ are never versioned. deliver rewrites the delivery folder on every run. If you want to keep an installer package, copy it somewhere else before the next deliver.
• Commit delivery\ with git. commit covers only the project file, its .gitignore, and the source folder.
• Certificates only by thumbprint. msi --sign takes the thumbprint of a certificate in the Windows certificate store. Neither the certificate nor a password is stored in the project.
• Keep shared items outside the project. delivery-settings.json names release packages by a path that can use %WKL_PACKAGES%. The SDK finds shared templates through WKL_ACCESS_TEMPLATES (templates).
• Other folders are up to you. The SDK doesn't read folders such as tests\, tools\, or docs\. Version them with git.

The project folder doesn't have to be the root of the repository. The SDK uses the git or Subversion working copy nearest above the project file, and commit commits only the project file, its .gitignore, and the source folder, even when other files of the repository are staged. A test project with a project file of its own can live inside the project folder: build\, obj\, and the lock always belong to the folder of their own project file.

<repository>\
  client\                          other parts, not read by the SDK
  installer\
  docs\
    images\                        source images of the manual
  access-admin\                    project folder of the application
    DbGwAdmin.acproj
    .gitignore
    source\
      resources\images\            shared images of the database
    delivery\
    assets\                        files of the application that are not part of the database
    tests\                         test project, a project folder of its own
      DbGwAcceptance.acproj        <Template>..\DbGwAdmin.acproj</Template>
      .gitignore
      source\
      build\                       results of the test project, not versioned
      obj\                         state and lock of the test project, not versioned
    build\
    obj\

• One project file per folder. A template named by its folder is found only when that folder holds exactly one .acproj, and the add-in looks for the project of the open database in the database's folder and up to three levels above it. Give a test project its own subfolder. With a second .acproj beside the main project, check reports the template .. as not found.
• A test project is a project of its own. It builds into tests\build\, keeps its state and lock in tests\obj\, and is committed by its own commit. The main project doesn't read tests\. Name the main project as the template by a relative path, most clearly with the file: <Template>..\DbGwAdmin.acproj</Template>. Its sources then join the test project's (templates).
• source\ holds only sources of the database. Every file in source\resources\images\ becomes a shared image of the database (the Access image gallery) on build, and export deletes every file there that the database doesn't hold. check reports other files in the object folders as a warning and doesn't load them.
• Other files go where they are used. Files that belong to the application but not to the database, such as logos for the installer or the original files of its images, go into a folder of your choice in the project folder, for example assets\. Images of a manual go with the manual. The SDK doesn't read these folders; version them with git.

• Project file reference – properties, configurations, and templates of the .acproj
• Build configurations and delivery profiles – what a configuration and a profile decide
• Source layout and formats – contents of source\ and how a build runs
• delivery-settings.json – the version and release packages all profiles share, and the profiles
• Command-line reference – exactly what new, commit, deliver, and msi do
• Deliver an application from the SDK – a delivery step by step