Upgrading Projects

Upgrading Projects

Dataverse PowerTools projects age in three different ways, and each has a different fix. Find your scenario below.

Which scenario am I in?

Scenario	How you'll know	Fix
Legacy plugin project (template < v3)	A warning on load: "This plugin project uses the legacy (<v3) template…"	New project + copy your .cs files (below). Legacy support is frozen and will be removed in 0.9.0.
Current template, old config files	Project works but tooling misbehaves (e.g. ts-jest deprecation warnings, Testing-pane oddities, no per-file output option)	Refresh the extension-owned config files (below).
Old settings file	Nothing — dataverse-powertools.json upgrades itself	No action. The migration runner versions and upgrades settings automatically (settingsVersion), including importing a legacy spkl.json and moving pluginModelBuilder out to modelbuilder.json.

---

Legacy plugin projects (template < v3)

The v3 plugin template (introduced 0.7.0-era) is a different world from the legacy one: pac plugin init layout, NuGet plugin packages instead of a raw assembly, no SNK signing, no spkl.exe (so it also works beyond Windows). An in-place auto-upgrade cannot be done safely, so the process is new project + move your code:

1. Add Component → Plugins. If your legacy project is at the workspace root, the wizard offers to move it into a subfolder first, leaving a connection-only root — accept that, then add the new Plugins component alongside.
2. Copy your plugin classes (.cs files) from the old project into the new plugin project folder. Do not copy the old .csproj, .snk, spkl.json, or packages.config.
3. Re-add your NuGet references to the new .csproj (dotnet add package …). The CrmSdk assemblies are already referenced by the template.
4. Your [CrmPluginRegistration] attributes carry across unchanged — Build Package & Deploy registers the steps from them.
5. When everything deploys, delete the legacy folder.

Timeline: legacy projects keep working (frozen — no new features) through the 0.8.x releases and support is removed in 0.9.0.

Refreshing config files in a current project

Projects scaffolded by older extension builds keep working, but their extension-owned config files miss later improvements. Key changes by area:

• webpack.common.js (0.7.4): output-mode support (#88) — reads webresourceOutput from dataverse-powertools.json to build either the single bundled library or one file per web resource (exports merged onto the PREFIX global, so forms still call PREFIX.Class.Function). Old configs only build the bundle, and the Output mode switcher has nothing to act on.
• webpack.dev.js (0.7.2): inline-source-map so breakpoints bind during Debug Web Resources. Old eval-source-map configs produce unbound breakpoints.
• tsconfig.json / tsconfig.build.json (0.7.5): modernised (es2020, bundler-style resolution in the build config, trimmed strictness); the production build compiles against tsconfig.build.json so it never needs @types/jest.
• jest.config.js (0.7.5-era template): ts-jest options under transform instead of the deprecated globals — silences the deprecation warning (which older extension builds could even misparse in the Testing pane).

Recommended process today: create a scratch project of the same type with the current extension, then diff/copy these files into your project (they contain no user code — your sources under webresources_src/ and your package.json dependencies are untouched; re-run Restore Dependencies afterwards). A one-click "Refresh config files" button that does this for you — with an automatic backup — is planned; see the tracking issue in the repo.

Version reference

Type	Current template	Older versions	Notes
Plugins	3 (pac plugin init, NuGet packages)	1–2: legacy spkl/SNK — frozen, removed 0.9.0
Web Resources	1 (config files evolve within the version — see refresh above)	—	webresourceOutput: bundle (default) or perFile
Solution	2 (integer)	1.1 (float) — migrates automatically	spkl.json folds into settings automatically
Portal	1	—