Build native desktop SDK in MSVC conformance mode (/permissive-)#1480
Build native desktop SDK in MSVC conformance mode (/permissive-)#1480bmehta001 wants to merge 3 commits into
Conversation
Enable ConformanceMode (/permissive-) for the native desktop SDK projects via the shared Solutions/build.props, so non-standard MSVC extensions are caught at build time (issue microsoft#255). Two project families are deliberately excluded, gated in the ItemDefinitionGroup condition: * UWP / Windows Store projects (AppContainerApplication=true) compile as C++/CX (/ZW), which MSVC rejects in combination with /permissive-. * C++/CLI managed projects (Keyword=ManagedCProj, e.g. net40) target the managed runtime and are a separate conformance domain. build.props is imported only by the SDK projects (net40, win10-*, win32-*), not by vendored sqlite/zlib or the test projects, so vendored third-party code is unaffected. Validated locally (VS 2026, v145, x64 Release): clean Rebuild of win32-lib (58 files) plus win32-dll / win32-mini-lib / win32-mini-dll all compile with 0 conformance errors and 0 warnings. Confirmed the gate excludes UWP (win10-lib does not receive /permissive-, so its /ZW build is unaffected). Files: Solutions/build.props Resolves microsoft#255. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Bring the net40 managed (C++/CLI) project under /permissive- by dropping
the Keyword=ManagedCProj exclusion from the build.props gate, and fix the
two conformance errors this surfaced in shared CX code:
* lib/shared/EventPropertiesCX.cpp: add `typename` to the dependent
name `map<string,T>::iterator` in StoreEventProperties (C3878/C2065
under two-phase name lookup).
* lib/shared/PlatformHelpers.h: forward-declare FromPlatformString
before the FromPlatformMap templates that call it. Under strict
two-phase lookup the dependent call fell back to ADL (which searches
Platform::, not the SDK namespace) and failed with C3861.
Now only UWP / Windows Store (C++/CX, /ZW) projects are excluded, since
/permissive- is incompatible with /ZW.
Validated (VS 2026, v145, x64 Release): clean Rebuild of the full
non-UWP SDK set -- win32-lib, win32-dll, win32-mini-lib, win32-mini-dll
and net40 -- with 0 conformance errors. (net40 is .NET Framework 4.0
C++/CLI; local builds need the v4.0 reference-assembly targeting pack,
which the SDK CI provides.)
Files: Solutions/build.props, lib/shared/EventPropertiesCX.cpp,
lib/shared/PlatformHelpers.h
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR enables MSVC conformance mode (/permissive-) for native desktop SDK builds (excluding UWP) via a shared Solutions/build.props gate, and updates shared CX/C++/CLI code to compile cleanly under two-phase name lookup.
Changes:
- Enable
/permissive-for non-UWP projects through a conditionalItemDefinitionGroupinSolutions/build.props. - Fix a two-phase lookup issue by forward-declaring
FromPlatformStringbeforeFromPlatformMaptemplates. - Fix a dependent-type iterator declaration by adding
typenamein a templated loop.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| Solutions/build.props | Adds a non-UWP MSBuild gate to compile with MSVC conformance mode (ConformanceMode=true). |
| lib/shared/PlatformHelpers.h | Adds a forward declaration so template name lookup succeeds under /permissive-. |
| lib/shared/EventPropertiesCX.cpp | Adds typename to a dependent map<...,T>::iterator to satisfy standard C++ lookup rules. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <!-- | ||
| Build the SDK projects in MSVC conformance mode (/permissive-) so | ||
| non-standard constructs are caught at build time. UWP / Windows Store | ||
| (AppContainerApplication) projects are excluded because they compile as | ||
| C++/CX (/ZW), which MSVC rejects in combination with /permissive-. | ||
| See issue #255. | ||
| --> | ||
| <ItemDefinitionGroup Condition="'$(AppContainerApplication)' != 'true'"> | ||
| <ClCompile> | ||
| <ConformanceMode>true</ConformanceMode> | ||
| </ClCompile> | ||
| </ItemDefinitionGroup> |
There was a problem hiding this comment.
Good catch — you're right, and my PR description was wrong. Solutions/build.props is imported well beyond the SDK library projects; git grep -l build.props -- '*.vcxproj' confirms sqlite/sqlite.vcxproj, third_party/Solutions/zlib/vc14/zlibvc.vcxproj, and tests/functests/FuncTests.vcxproj / tests/unittests/UnitTests.vcxproj (plus gtest/gmock and samples) all import it. So the gated ItemDefinitionGroup was forcing /permissive- onto vendored deps and the unvalidated test projects too.
Fixed in 1afe1ef: the ConformanceMode block is moved out of build.props into a dedicated Solutions/conformance.props that is imported explicitly only by the five native SDK library projects (win32-lib, win32-dll, win32-mini-lib, win32-mini-dll, net40), right after their build.props import so it still wins ItemDefinitionGroup ordering. build.props is reverted.
Verified locally (VS 2026, v145, x64 Release): /permissive- is present on win32-lib's cl invocations with 0 conformance errors, while a standalone sqlite:Rebuild now shows 0 /permissive- occurrences. Fixed.
…ojects only
Solutions/build.props (Copilot): the ConformanceMode block lived on the
shared build.props, which is ALSO imported by vendored sqlite/zlib, the
test projects (gtest/gmock/UnitTests/FuncTests) and the samples -- so
/permissive- was applied far more broadly than intended, and the PR
description's claim was wrong. Verified with `git grep -l build.props --
'*.vcxproj'`: sqlite/sqlite.vcxproj, third_party/.../zlibvc.vcxproj and
tests/{functests,unittests}/*.vcxproj all import it.
Fix: move ConformanceMode into a dedicated Solutions/conformance.props,
imported explicitly only by the five native SDK library projects
(win32-lib, win32-dll, win32-mini-lib, win32-mini-dll, net40), right
after their build.props import so the setting wins. build.props is
reverted to its original content.
Validated (VS 2026, v145, x64 Release): /permissive- present on
win32-lib's cl invocations (0 conformance errors); a standalone
sqlite:Rebuild now shows 0 /permissive- occurrences; clean Rebuild of
all five SDK library projects.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
What
Enable MSVC conformance mode (
/permissive-) for the SDK's own native library builds, and fix the conformance errors this surfaces.Why
Per #255, MSVC's default (permissive) mode lets non-standard constructs slip into the codebase unnoticed.
/permissive-makes the compiler reject them at build time.Scope and gating
/permissive-is applied via a dedicatedSolutions/conformance.props(a singleConformanceMode=trueItemDefinitionGroup) that is imported explicitly, per-project, by the five native SDK library projects only:win32-lib,win32-dll,win32-mini-lib,win32-mini-dll,net40It is imported right after each project's
build.propsimport, so the setting wins ItemDefinitionGroup ordering.It is deliberately not put on the shared
Solutions/build.props, becausebuild.propsis also imported by vendoredsqlite/zlib, the test projects (gtest/gmock/UnitTests/FuncTests), and the samples — none of which we want to force into conformance mode. The UWPwin10-*SDK projects also do not import it, because/permissive-is incompatible with C++/CX (/ZW); their shared SDK sources are still conformance-checked through thewin32library builds.Conformance fixes (C++/CLI net40)
Enabling
/permissive-on the managednet40project surfaced two two-phase-lookup errors in shared CX code, both fixed here:lib/shared/EventPropertiesCX.cppC3878/C2065—map<string,T>::iteratoris a dependent typetypenamelib/shared/PlatformHelpers.hC3861—FromPlatformStringused byFromPlatformMaptemplates before its declaration; dependent call fell to ADL (Platform::)Validation (VS 2026, PlatformToolset v145, x64 Release)
/permissive-confirmed present onwin32-lib's cl invocations; clean Rebuild of all five SDK library projects → 0 conformance errors.net40(C++/CLI) →Microsoft.Applications.Telemetry.Windows.NET.dll.sqlite:Rebuildshows 0/permissive-occurrences (vendored deps and tests are unaffected).Resolves #255.