2023-01-06 02:18:25 +03:00
|
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
|
|
|
<!-- Rules for Dependency Management:
|
|
|
|
|
1. Dependencies in Version.Details.xml are automagically propogated via Maestro
|
|
|
|
|
e.g. if B depends on A v1 and A v2 is published, Maestro updates B's Version.Details.xml to A v2
|
|
|
|
|
2. Dependencies in Version.Dependencies.xml are only changed by explicit (manual) developer action
|
|
|
|
|
e.g. if B depends on A v1 and A v2 is published, B is unchanged
|
2023-02-01 00:10:02 +03:00
|
|
|
3. Dependencies' versions in Version.Details.xml and Version.Dependencies.xml are TheMasterSourceOfTruth(TM).
|
2023-01-06 02:18:25 +03:00
|
|
|
These are literal values. No macro expansion or magic substitution will occur
|
|
|
|
|
4. <ProductDependencies><Dependency> are listed in sorted order (alphabetically, case-insensitive)
|
|
|
|
|
5. <ToolsetDependencies><Dependency> are listed in sorted order (alphabetically, case-insensitive)
|
|
|
|
|
6. <ProductDependencies> appears before <ToolsetDependencies> (aka sorted order, alphabetically, case-insensitive)
|
|
|
|
|
7. Dependencies are made available to MSBuild + VisualStudio via Version.Dependencies.props
|
|
|
|
|
8. ProductDependencies are made available to MSBuild + VisualStudio as macros in the form name.Replace(".", "").Append("PackageVersion")
|
|
|
|
|
9. ToolsetDependencies are made available to MSBuild + VisualStudio as macros in the form name.Replace(".", "").Append("Version")
|
|
|
|
|
10. DevCheck.cmd/ps1 -SyncDependencies generates Version.Dependencies.props from Version.Details.xml (if necessary)
|
|
|
|
|
11. DevCheck.cmd/ps1 -SyncDependencies updates versions in packages.config to match Version.Details.xml (if necessary)
|
|
|
|
|
12. DevCheck.cmd/ps1 -SyncDependencies updates versions in *proj to match Version.Details.xml (if necessary)
|
|
|
|
|
13. DevCheck.cmd/ps1 -CheckDependencies verifies Version.Dependencies.props matches Version.Details.xml
|
|
|
|
|
14. DevCheck.cmd/ps1 -CheckDependencies verifies packages and versions in packages.config match Version.Details.xml
|
|
|
|
|
15. DevCheck.cmd/ps1 -CheckDependencies verifies packages and versions in packages.config match Version.Details.xml
|
|
|
|
|
16. DevCheck.cmd/ps1 -CheckDependencies verifies versions in *proj match Version.Details.xml
|
|
|
|
|
17. Version.Dependencies.props is a generated file. DO NOT EDIT. Use DevCheck -SyncDependencies
|
|
|
|
|
18. POLICY: Dependencies on Transport Packages are expressed as <ProductDependencies> in Version.Details.xml
|
|
|
|
|
19. POLICY: Dependencies on non-Transport Packages are expressed as <ToolsetDependencies> in Version.Dependencies.xml
|
2023-02-01 00:10:02 +03:00
|
|
|
20. POLICY: Update Version.Dependencies.props via "DevCheck -CheckDependencies -SyncDependencies".
|
2023-01-06 02:18:25 +03:00
|
|
|
NOTE: This is required when adding or removing a dependency
|
|
|
|
|
-->
|
|
|
|
|
<Dependencies>
|
|
|
|
|
<Dependency Name="Microsoft.Build.Tasks.Git" Version="1.1.1"/>
|
|
|
|
|
<Dependency Name="Microsoft.SourceLink.Common" Version="1.1.1"/>
|
|
|
|
|
<Dependency Name="Microsoft.SourceLink.GitHub" Version="1.1.1"/>
|
2024-08-17 01:25:55 +03:00
|
|
|
<Dependency Name="Microsoft.Taef" Version="10.94.240624002"/>
|
2023-01-06 02:18:25 +03:00
|
|
|
<Dependency Name="Microsoft.Telemetry.Inbox.Native" Version="10.0.19041.1-191206-1406.vb-release.x86fre" />
|
2023-09-05 03:01:12 +03:00
|
|
|
<Dependency Name="Microsoft.Windows.CppWinRT" Version="2.0.230706.1"/>
|
2024-08-17 01:25:55 +03:00
|
|
|
<Dependency Name="Microsoft.Windows.ImplementationLibrary" Version="1.0.240803.1"/>
|
Add initial Protobuf support (#3448)
**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 :-)
2023-02-18 02:38:25 +03:00
|
|
|
<Dependency Name="Microsoft.WindowsAppSDK.Protobuf" Version="3.21.12"/>
|
2023-01-06 02:18:25 +03:00
|
|
|
</Dependencies>
|
