Skip to content

Conversation

@DrusTheAxe
Copy link
Member

Add C#/WinRT Projection dlls for Microsoft.Windows.AppLifecycle and Microsoft.Windows.ApplicationModel.DynamicDependency

Modeled after MRT's C#/WinRT projection dll, but accounting for MRT vs SharedProjects/ProjectReunion_DLL deltas.

As previously discussed, structured as 1 projection dll per namespace (which also matches how MRT's structured)

…icrosoft.Windows.ApplicationModel.DynamicDependency (modeled after MRT's C#/WinRT projection dll, but accounting for MRT vs SharedProjects/ProjectReunion_DLL deltas)
@DrusTheAxe DrusTheAxe added area-Projections Request for support of a runtime or language area-Lifecycle Topics related to the AppLifecycle, providing lifecycle management for WindowsAppSDK apps area-DynamicDependencies DynamicDependency for Windows App SDK: enables framework packages for packaged & unpackaged apps labels May 29, 2021
@DrusTheAxe DrusTheAxe added this to the 1.0 (2021 Q4) milestone May 29, 2021
@DrusTheAxe DrusTheAxe self-assigned this May 29, 2021
@ghost ghost added the needs-triage label May 29, 2021
@DrusTheAxe DrusTheAxe requested review from andreww-msft and removed request for andrewleader May 29, 2021 00:37
@DrusTheAxe
Copy link
Member Author

/azp

@azure-pipelines
Copy link

Supported commands
  • help:
    • Get descriptions, examples and documentation about supported commands
    • Example: help "command_name"
  • list:
    • List all pipelines for this repository using a comment.
    • Example: "list"
  • run:
    • Run all pipelines or specific pipelines for this repository using a comment. Use this command by itself to trigger all related pipelines, or specify specific pipelines to run.
    • Example: "run" or "run pipeline_name, pipeline_name, pipeline_name"
  • where:
    • Report back the Azure DevOps orgs that are related to this repository and org
    • Example: "where"

See additional documentation.

<PackageReference Include="Microsoft.Windows.CsWinRT" Version="1.2.2" />
</ItemGroup>

<!-- For consistency across Reunion, explicitly reference .NET 5.0.5 SDK (5.0.202 train for VS 16.9.3) -->
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MRTCore had this which is puzzling AH as I don't see any mention of .NET 5.0.5, 5.0.202 or VS 16.9.3 in the <FrameworkReference>s below.

And this sort of this would be best commonly defined for the repo e.g. in Directory.build.props

...
  <PropertyGroup>
    <ProjectReunion_CsWinRT_Projections_RuntimeFrameworkVersion>10.0.18362.16</>
    <ProjectReunion_CsWinRT_Projections_TargetingPackVersion>10.0.18362.16</>
...

and use the common definitions across the repository

...
<FrameworkReference Update="Microsoft.Windows.SDK.NET.Ref" RuntimeFrameworkVersion="$(ProjectReunion_CsWinRT_Projections_RuntimeFrameworkVersion)"/>
<FrameworkReference Update="Microsoft.Windows.SDK.NET.Ref" TargetingPackVersion="ProjectReunion_CsWinRT_Projections_TargetingPackVersion" />
...

Even better: instead of defining versions in Directory.Build.props, create a new Tools.props in the root with the tool versions (similar to BuildInfo.json generated by the build pipeline) and Directory.Build.props merely includes it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those versions are wrong.
The SDK refs are probably unnecessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Scottj1s can we drop the Microsoft.Windows.SDK.NET.Ref snippets?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove the framework reference overrides in a component - those are needed by an app for a temporary situation to avoid mem leaks that were fixed in the .16 update. That will come to all apps by default in the next .NET5 SDK update

@DrusTheAxe
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

{A3FBA80D-5B35-471F-9A45-DB4B29E195B9}.Release|x86.ActiveCfg = Release|x86
{A3FBA80D-5B35-471F-9A45-DB4B29E195B9}.Release|x86.Build.0 = Release|x86
{A3FBA80D-5B35-471F-9A45-DB4B29E195B9}.Release|x86.Deploy.0 = Release|x86
{4995CCDC-9B83-4A9A-9724-604B09E6AF00}.Debug_test|Any CPU.ActiveCfg = Debug|x64
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Debug_test

remove

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is Debug_test for anyway? Looks like everything's got them but we never use them (that I know of). Delete them all?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uhh, i thought you added that. But it's existing. It does change IsTDPConfiguration to true, although nobody seems to use IsTDPConfiguration. I guess it's ok to leave it alone.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any idea what Debug_test is for? I never saw it before last year in ProjectReunion.sln.

I added the project via VS on a PC which I think doesn't have TDP installed, if that matters

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

related to TAEF testing configurations? if it looks like cruft, I'd drop it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop all of them or just these additions?

…o 10.0.17763.0 (MRT's been overdue for the update)
@DrusTheAxe DrusTheAxe requested a review from astritz June 1, 2021 19:36
<assembly>
<name>Microsoft.Windows.AppLifecycle.Projection</name>
</assembly>
<members>
Copy link
Member

@Scottj1s Scottj1s Jun 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you don't need an Intellisense xml file for the managed projection assembly - VS just uses reflection

EDIT: oops, correction - we do need these for projection assemblies as well. If you have IDL comments, might be able to powershell those into an xml file. The Windows SDK projection assembly contains Microsoft.Windows.SDK.NET.xml, but I could not find where that lives. @manodasanW might know, but would likely still require hand-editing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. I see MRTCore's got one too -- dev\MRTCore\packaging\Intellisense. I'll delete that too (unlesss @huichen123 @axelandrejs squeak otherwise)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove for MRT. Thanks.

Copy link
Member Author

@DrusTheAxe DrusTheAxe Jun 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per @Scottj1s correction these are needed. They should be fleshed out (need content, not just a trivial file as listed). I'll take a stab at it in a future PR per DynamicDependencies: Flesh out Intellisense .xml with doccomments
#906

There's some potential tooling to help. Once I figure it out we should be able to do likewise for AppLifecycle and MRTCore (if when :-) they contain doccomments)

@aeloros @huichen123 do AppLifecycle and MRTCore have tasks for 1.0 to add doccomments?
(I did added them for DynDep when I created the APIspec, easy and self-documenting. But easy enough to add after the fact too)

@Scottj1s
Copy link
Member

Scottj1s commented Jun 3, 2021

The intellisense data might be an issue in its own right - consider opening an IOU and dropping comment pointers to it in each xml file.

@DrusTheAxe
Copy link
Member Author

I created an issue for 1.0 DynamicDependencies: Flesh out Intellisense .xml with doccomments
#906

We can use that as the stalking horse to figure it out as that's already got all the doccomment/content, just a matter of working out process/mechanism to pass that along to Intellisense.

AppLifecycle and MRTCore should add doccomments. Then whatever the process we work out for DynDep we can apply to them too for full coverage

<PropertyGroup>
<TargetFramework>net5.0-windows10.0.18362.0</TargetFramework>
<TargetPlatformMinVersion>10.0.17134.0</TargetPlatformMinVersion>
<TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to set TFM and TPMinV differently for our projections? Shouldn't we just set TFM=17763? I don't believe the projections (or the component itself) does any lightup on 18362?

<TargetFramework>net5.0-windows10.0.18362.0</TargetFramework>
<TargetPlatformMinVersion>10.0.17134.0</TargetPlatformMinVersion>
<TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
<Platforms>x64;x86</Platforms>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

arm64?

@@ -17,8 +17,8 @@
<ApplicationType>Windows Store</ApplicationType>
<ApplicationTypeRevision>10.0</ApplicationTypeRevision>
<WindowsTargetPlatformVersion Condition=" '$(WindowsTargetPlatformVersion)' == '' ">10.0.18362.0</WindowsTargetPlatformVersion>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above - can't all this be 17763 or does the component actually do lightup?

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>net5.0-windows10.0.18362.0</TargetFramework>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

set TFM=17763 and remove the TPMinV

<PropertyGroup>
<TargetFramework>net5.0-windows10.0.18362.0</TargetFramework>
<TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
<Platforms>x64;x86</Platforms>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

arm64

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>net5.0-windows10.0.18362.0</TargetFramework>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

set TFM=17763 unless it requires a newer api, remove TPMinV
add arm64 platform support

</ItemGroup>

<!-- For consistency across Reunion, explicitly reference .NET 5.0.5 SDK (5.0.202 train for VS 16.9.3) -->
<ItemGroup>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove the frameworkreference overrides. this should only be specified by apps and is temporary until the next netsdk update

@DrusTheAxe
Copy link
Member Author

Abandoning due to too old and stale to merge correctly. Replaced by Added C# WinRT projections for DynamicDependency and AppLifecycle WinRT APIs #1208

@DrusTheAxe DrusTheAxe closed this Aug 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-DynamicDependencies DynamicDependency for Windows App SDK: enables framework packages for packaged & unpackaged apps area-Lifecycle Topics related to the AppLifecycle, providing lifecycle management for WindowsAppSDK apps area-Projections Request for support of a runtime or language needs-triage

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants