* Added AddPackageSetOptions. Added tests for AddPackageSetAsync. Fixed bugs
* Fixed typos. Added missing AddPackageAsync in .idl
* Remove dead code
* Update Transport package's manifested inproc servers
* Added new directory
* Added ApplicationData project. Expanded docs. Added missing ApplicationDataCreateDisposition. Added TerminalVelocity support
* Added stub implementations
* Initial implementation
* Implemented ApplicationData
* Tweaked to be smarter about Windows.Storage.ApplicationData's weird limitations
* Fixed ApplicationData.MachinePath to use the right path. Bumped WIL to 1.0.231216.1 (to get access to wil::reg APIs)
* Implemented IsMachinePathSupported()
* Added tests (mostly)
* Fixed machine path test infra (AppDataPaths doesn't work in our scenario)
* Removed method overload per feedback. Added more doc-comments
* More fixes and optimizations
* More test coverage
* Updated MachinePath/etc to only be accessible if a package in the family is registered to the user OR running as SYSTEM
* Removed ClearAllAsync() and ClearMachineAsync(). Use ClearAsync(locality)
* Updated per API Review
* Fixed build error
* Fixed bad merge. Added ApplicationData Projection
* Reapply "PackageDeploymentManager: IsReadyOrNewerAvailable(), FrameworkUdk update, Implement not-implemented functions, Tests! (#4453)" (#4514)
This reverts commit 684fdf1797.
* Added #include sddl.h as WindowsAppRuntime.sln was fine for all users but the WindowsAppRuntimeInstaller.sln wasn't. Better to be self-fulfilling in case code changes again in the future to avoid unknown-symbol pains
This PR does multiple things
* Add Is*ReadyOrNewerAvailable*()
* Add EnsureReadyOptions.RegisterNewerIfAvailable=bool
* Add Is*Provisioned*()
* Fix progress updates when PackageSet.Items.Count>=2 (was (re)set to 0-1.0 for each item, not collectively for the whole operation)
* Update to recent FrameworkUdk
* Implement previously not-implemented functions (Remove, Repair, Reset)
* Expanded test coverage
* Update TAEF to 10.92.240405002
* DevCheck
* Added -InstallWindowsSDK option to install Windows (Platform) SDK if desired
* Fix DevUnlock check on a machine w/o DeveloperMode enabled (last registry access doing registry access the unsafe way error'ing if the value doesn't exist in the registry)
KNOWN ISSUES:
* Need updated Platform SDK to resolve known issues
* Register*Async() errors on 20H2/Vb3.
* Reset*Async() succeeds but ends w/o the package being registered
* RemovePackageByUriAsync() throws E_NOTIMPL
* RemovePackageSetAsync() throws E_NOTIMPL if PackageUri=ms-uup
* Provision*Async() not supported yet
* Deprovision*Async() not supported yet
https://task.ms/49555034https://task.ms/48914090https://task.ms/48964562
Additional changes
* Fixed progress reporting incorrect .progress percentage values
* Added StringToSid() and SidToString()
* Refactored common code into WaitForDeploymentOperation
* Added IsPackageRegistrationPending. Removed dead code. Added Black+Blacker test Main packages.
* Added PackageFamilyName() property to PackageIdentity
* Added IsPackageDeploymentFeatureSupported and initial support for Containment.
* Fixed RemovePackageOptions.FailIfNotFound.
* Improved logging
* Expanded tests.
* Fixed RemovePackageOptions.FailIfNotFound default (was true, supposed to be false). Mostly implemented RemovePackageSetAsync; URI handling is blocked awaiting FrameworkUdk update (imminent).
* Updated to latest FrameworkUdk
* Patched tests to deal with RemovePackage is awaiting updated Platform SDK
* Removed dead code. Updated some not-impl to impl :-)
* Repair!
* Added IsProvisioned
* Added Provisioning tests and support
* Added Deprovision tests (in progress).
* Optimized test code
* Upgraded TAEF to 10.92.240405002
* Tweak build logic to support Windows SDK 10.0.26100.0 but not fail if using 10.0.22621.0
* Tweaked SDK detection
* Fixed some URI handling
* DevCheck:
* Add docs re PackageSet properties
* Added workaround for tests not wired to work on 20H2/Vb
Also
* Manually update DevChcek (awaiting Maestro to automate that thing it's supposed to be doing. Oh, Will...)
* Update TAEF from 10.75.221207001 to 10.82.230714001. Update C++/WinRT from 2.0.221121.5 to 2.0.230706.1
* Something weird's failing in the ARM64 tests. Disabling ARM64 temporarily
**Add support for Google's [Protocol Buffers](https://protobuf.dev/) (aka protobuf)**
Using protobuf requires 3 components:
1. protoc.exe -- 'Compiles' *.proto files generating *.pb.cc and *.pb.h code
2. headers -- Needed to compile generated *.pb.cc
3. libs -- Needed to link compiled bits from 2
Google provides a nuget containing a compiled protoc.exe but doesn't make headers or libs available via nuget. TL;DR we create a nuget for our use (Microsoft.WindowsAppSDK.Protobuf.3.21.12.nupkg). Details of what, why and how are in `tools\nuget\protobuf\README.md`.
TL;DR Developers working in WinAppSDK only need to know there's a nuget providing protobuf support. The messy details how to create that are only relevant to the developer creating the nuget (moi) or future devs if/when a new version is needed.
**Added `KozaniProtocol`** containing Kozani's protobuf messages and related definitions. The purpose of KozaniManageProtocol project is to contain all of Kozani's protobuf definitions and compile them to produce the generated code for use by other projects.
**Updated `KozaniManager`** to consume the protobuf code from KozaniProtocol and added wrappers showing how to use it.
**Updated `KozaniRemoteManager`** to reference to consume the protobuf code from KozaniProtocol.
General structure of our protobuf usage:
1. **Define a message in KozaniProtocol**.
* Split up by functional roles across *.proto files e.g. Kozani.Activation.proto for activation, Kozani.Process.proto for process management (e.g. if TaskManager kills local KozaniHostRuntime.exe we need to send message to server to terminate the associated back end process), etc.
* Any sort of 'synchronous communication' would involve a pair of request+response messages. KozaniManager sends 'request' to server and KozaniRemoteManager sends a related 'response'.
* The 'cookie' field is an example of a correlating id to match a request with a response. A 'conversionid', 'channelid', etc are other examples how to xref 2+ messages together into a larger context.
2. **Define a namespace with functions that internally use protobuf messages**
* Keep all protobuf usage internal to code using them. Protobuf is an implementation detail. Provide appropriate strongly typed functions for callers to drive activity which internally happen to use the protobuf generated code.
* If you need context spanning multiple messages you can create a class with methods which internally use protobuf messages, plus additional attributes for any additional data needed for the context.
3. Serialize messages to `std::string`
* Protobuf can serialize messages to `std::string` or `std::ostream`. NOTE: The serialized data's just bytes, `string` is just a convenient container to pass the data around.
* `std::string` is recommend when serializing a message to bytes.
* `std::string` or `std::istream` is recommended when deserializing a message from bytes. Large messages may be more efficient via `std::istream`; either works well enough for small messages so use whichever is more convenient.
4. Always encode strings as UTF8 before serialization.
* Protobuf expresses message `string` fields as `std::string`. It does not do wide<->narrow conversions for you (unlike, say, SQLite) - that's the developer's responsibility. If you have a wide string (`std::wstring`, `PCWSTR`, `HSTRING`, etc) convert it to a UTF-8 string before assigning it to a protobuf field. Use functions in `\dev\common\Microsoft.Utf8.h` to convert wide->utf8 e.g.
```c++
PCWSTR appUserModelId{ L"LolzCatzVidz" };
const std::string appUserModelIdUtf8{ ::Microsoft::Utf8::ToUtf8(appUserModelId) };
```
* When deserializing wide strings from protobuf serialized bytes don't forget to convert the UTF-8 bytes to a wide string. Use functions in `\dev\common\Microsoft.Utf8.h` to do this e.g.
```
Some::Protobuf::Message::Kitteh kitteh;
kitteh.ParseFromString(stream_containing_serialized_bytes);
const std::wstring name{ kitten.get_name() };
```
5. Avoid making classes inherit from protobuf's generated classes.
* Protobuf docs counsel against against inheriting and extending the generated classes. Treat protobuf's generated classes as structs of data you can access but not extend (use composition esp private composition, not inheritance).
6. We use protobuf as a static library.
* Protobuf can provide support code via libprotobuf.dll but recommends against it as that must have a compatible version as the generated code. To minimize complications we use protobuf as a static lib. This may be revisited in the future.
Everything compiles and links. `dev\Kozani\KozaniManager\main.cpp` has an example serializing a protobuf message to bytes (as a `std::string`). Changing and extending that for all the rest of our functionality and likewise parsing bytes to protobuf messages in KozaniRemoteManager (or vice versa) is left as an exercise for the reader :-)
* Fixed DevCheck -SyncDependencies (wasn't updating files). Updated versions of TAEF and C++/WinRT
* Updated dependencies via DevCheck -SyncDependencies
* Updated DevCheck to treat -SyncDependencies equivalent to -CheckDependencies++ (before was treating -SyncDependencies equivalent to -All -SyncDependencies)
* Added dependency verification to the build pipeline
* Removed reference to non-existent .natvis
* Fix DevCheck -Check/SyncDependencies was only scanning dev; missed test and other dirs
* Newer version of TAEF moved .NET libs from \net45\ to \net452\ directory. Fixed up references
Bob Pulliam
Howard Kapustein
Kyaw Thant
Kyaw Thant