Discussion: Don't add "ProjectReunion" to the Microsoft.WinUI package name

[dotMorten]

In a recent screenshot, it showed that the WinUI package is changing from Microsoft.WinUI to Microsoft.ProjectReunion.WinUI.
https://twitter.com/marbtweeting/status/1367604242748346368/photo/1

I find this naming rather confusing to be in the product name.

Scott Hunter last week during the dotnetconf said "Project Reunion is a code word - it'll change before we actually ship it".
So it seems to me you're putting a temporary project name into the nuget, and I don't really get the value add here either. If anything it just adds a some confusion. In the end it's just a Windows app - how we get there is irrelevant to what you ship. Or to quote the reunion talk from Ignite 2021:

...eventually, the goal there is instead of thinking about desktop apps or UWP apps, we'll bring those worlds together and we'll just be thinking about Windows apps and libraries...

Another issue here is once Project Reunion is complete, you're actually stuck with it. You can't change the name of the nuget, or you'll hose 3rd party libraries that takes a dependency on the nuget, and anyone using those 3rd party libs can't grab a newer version of WinUI without waiting for the 3rd party vendors to re-release. And anything released on Preview 4 is definitely breaking (but since it was preview I guess that can be argued is OK but it's just an example of how it already breaks anything already released)

[riverar]

Project Reunion as of a few hours ago is still forbidden for use in actual Project Reunion code (as a namespace). So I was shocked to learn that WinUI was going forward with this package naming for GA.

Is Windows off-limits? e.g.

Microsoft.Windows (0.5.0-prerelease)
Microsoft.Windows.Foundation (0.1.0-prerelease)
Microsoft.Windows.UI (3.0.0)

If that's confusing or politically impossible, then perhaps chop some letters off whilst keeping the spirit of what all this work does (creates a union of APIs). Reunion is perpetually in progress; Union is timeless.

Microsoft.Union (0.5.0-prerelease)
Microsoft.Union.Foundation (0.1.0-prerelease)
Microsoft.Union.WinUI (3.0.0)

[dotMorten]

If it's mainly a matter of exposing all the Windows SDKs regardless of UWP or Win32, Microsoft.Windows.* makes sense. It's "just windows", but I think most of these can also stand on their own like Microsoft.WinUI, or for DWriteCore instead of Microsoft.ProjectReunion.DWrite, it would be Microsoft.DWriteCore etc.

[StephenLPeters]

@MikeHillberg and @ryandemopoulos

[jonwis]

Hey folks, several different axies (axises? axees?) here - namespace, packaging, and metadata.

We're using namespaces that describe the types within - so Microsoft.UI.Xaml or Microsoft.UI.Composition as examples. It's a UI framework based around XAML, from Microsoft. (Our naming rules use PascalCase for acronyms.) Or it's a UI framework based around Composition, from Microsoft. So @dotMorten has it right - Microsoft.DWriteCore (although maybe Microsoft.UI.DWriteCore...) is the namespace for those types.

The packaging vehicle for WinUI's upcoming releases is Project Reunion. Right now, we're sticking with Microsoft.ProjectReunion as the name of that package. This package has two parts - the metadata packages (see below) and the physical runtime redistributable delivered as a framework package. That framework package will have names like Microsoft.ProjectReunion.0.5, etc. @riverar may be onto something as we probably can't keep calling it ProjectReunion forever. Is the package of the code you use to write great apps for Windows Microsoft.WindowsSDK? Or Microsoft.WindowsAppSDK?

Then there's where you get the metadata. We're delivering the build-time metadata through multiple nuget packages so that adding a ref to DWriteCore doesn't make your build also pull in WinUI3 or MRT. So we end up with NuGet packages named like Microsoft.ProjectReunion.DWriteCore and Microsoft.ProjectReunion.WinUI and Microsoft.ProjectReunion.Foundation.

So yeah, the names are a little confusing.

• There's many different types and chunks of functionality coming via Project Reunion - including WinUI3; the names of these are based on what they do, all under the Microsoft.* root.
• All of Project Reunion has a single physical redist, the Project Reunion Framework Package
• We're (initially) keeping the build metadata separated so you can limit what your build tools pull in

(I'll be the first to admit that I love a good naming discussion, maybe more than I should. Look for a more complete write-up of this under http://github.com/microsoft/projectreunion coming early next week.)

[dotMorten]

Hey folks, several different axies (axises? axees?) here - namespace, packaging, and metadata.

Wrt the issue here, I'm referring to just the package name - I'm aware the namespace isn't getting ProjectReunion added.
But that sort of makes you wonder why there's this difference. If we can't add it to the classes and namespaces, why can we add it to nuget IDs?

Anyway here's a few of the above statements that makes me worried:

Right now, we're sticking with Microsoft.ProjectReunion as the name of that package.
[...] we probably can't keep calling it ProjectReunion forever.

So it sounds temporary/short-term and you might change it later? The thing is you have to keep the same name. Once you ship those nuget packages with go-live, you can't really change them, without hosing the 3rd party libraries out there. Say Library A takes a dependency on v3.0. Then you ship 3.1, and the users can just reference 3.1, and the 3rd party lib will continue to work but now on top of 3.1 (provided you don't make breaking changes of course). Now if you rename the package, that 3rd party library will instead be pulling in the old 3.0, while the developer will try and pull in the newly renamed package, and you'll have a conflict. It just breaks the nuget hierarchy, and the user would be stuck on the older version of WinUI until all his 3rd party libraries have had a chance to move over to the new packages. You can't really afford to constantly be hosing your 3rd party ecosystem.

So yeah, the names are a little confusing.

But why make it confusing?

The packaging vehicle for WinUI's upcoming releases is Project Reunion.

Why does that mean it has to bleed into the names of the nuget packages?

I'll be the first to admit that I love a good naming discussion,

I have a feeling we would get along just fine :-)

[bkaankose]

Anything code related stuff that includes 'ProjectReunion' must be trimmed for better 3rd party compatibility and potentially stop more confusion around 'What exactly Project Reunion is and what is WinUI?' . By code related I mean to namespaces and Nuget packages.

People have been following Project Reunion as just a term. This is just an an effort to 'unify' WinForms, WPF, UWP, basically anything that Windows SDK offers internally to the Microsoft stack developers. WinUI is mostly the UI part of this decoupling. I understand there are more to include then just UI layer like runtimes and metadata to support multiple languages but Project Reunion should not be the term to include these stuff in in the code. For developers, it is just a term that Microsoft puts effort into.

Changing the nuget package name or potentially namespaces will discourage 3rd party library supporters from the platform. They have been doing tremendous amount of work in this painful change with Microsoft.UI.Xaml already, even in the preview days to just support customers faster when the time comes.

So there are 2 main reasons here why things should go the way as they are right now:

• Not to bring more confusion around the terms (that developers are unlikely to know everything about them already) WinUI, MAUI, Project Reunion etc. This is mainly because bad marketing of these terms will potentially discourage developers like in the past with UWP - Lumia times.
• To have better backward compatibility since preview 1 days of WinUI.

[thomasclaudiushuber]

Jep, we all know, naming is hard. 🙂

Everything with "Project Reunion" or just "Union" is in my opinion not a good idea. Why?

1. I think a package name should tell what's in the package. "Project Reunion" does not tell what's in the package (at least not to me). Also think about all those devs who never read/heard about project reunion, they'll have absolutely no idea what that package is.

2. I can tell from my experience that project reunion is for many developers a thing that is not so easy to understand. But many know that WinUI is the latest UI framework you can use. If you now add "ProjectReunion" to the WinUI package, it will definitely confuse a few if they look at the packages.

I think the packages should have names like Microsoft.WindowsApi that makes it clear what's in the package. Look for example at the latest Azure SDK NuGet packages, they did a pretty good job. You find there package names like Azure.Storage.Blobs or Azure.Storage.Queue or Azure.Messaging.EventHubs (even the namespaces are like this). Anyone can tell from the package name what the package is about.

Also interesting is that the Azure NuGet packages are not prefixed with Microsoft, also the namespaces in these packages start directly with Azure. This would mean for windows, that packages like Windows.Foundation and Windows.UI could also be valid package names.

Lastly, I want to mention that I know many developers who expect the namespace to be the same as the package name. I don't want to say add ProjectReunion to the namespaces (please not :-)), but from that point of view, Microsoft.UI would make sense as a name for the WinUI package. But to me, this tells again not enough about what's in the package.

I would prefer the original package name from preview 4, Microsoft.WinUI, or the suggestion from @riverar, Microsoft.Windows.UI, or this shorter name Windows.UI (Imagine even namespaces would start with Windows.UI 😄)

[huoyaoyuan]

Union is OK for a meta package that reference a group of things (Microsoft.Union.SDK?), but not OK for each individual product.

[sylveon]

Why not use the actual root namespace for the package like others do and name it Microsoft.UI.Xaml

[thomasclaudiushuber]

Why not use the actual root namespace for the package like others do and name it Microsoft.UI.Xaml

Hey @sylveon , great suggestion, I like that package name too. I didn't mention it, because I think the problem is that this is not the root namespace. While it might be the most popular namespace in the WinUI NuGet package, there are also other namespaces like Microsoft.UI.Composition and Microsoft.UI.Input. But hmm... if I follow this logic for the package name, Microsoft.UI would also not be an option, as there are also namespaces like Microsfot.System in the WinUI NuGet package

[huoyaoyuan]

Microsoft.UI doesn't indicate it's a Windows-only and native UI.

[dotMorten]

Why not use [...] Microsoft.UI.Xaml

That is already in use by WinUI 2, which is really an entirely different product. If it was reused, people would see it as an update and be in for quite a surprise if they updated. While I agree it would have been a logical place to put it, I don't think that's worth the poor user experience it would create.

[ForerunnerG34]

This may never happen but I honestly would love to have something in my code that says:

Microsoft.FooKit (0.5.0-prerelease)
Microsoft.FooKit.Foundation (0.1.0-prerelease)
Microsoft.FooKit.UI (3.0.0)

Please don't think I'm being disrespectful, there is a reason behind it: people don't fully understand (me included) what "Project Reunion" is, and many, many years in the future this could be quite a story and computer science is full of great stories related to naming things.

[mrlacey]

As I've heard Kevin Gallo say several times: "Projects are temporary experiments and may not turn into shipping products. Projects are not guaranteed to exist in the future or have ongoing support. Products are and do." {paraphrase}
By tying WinUI3 to the ProjectReunion name there is an underlying implication that WinUI3 might not stick around. For something that's supposed to be the future of Windows development this is disturbing and does not build confidence that WinUI3 is a technology to be relied upon in the future.

[thomasclaudiushuber]

I don't know if it belongs to this discussion too, but also concerning is the VSIX name, which is now just "Project Reunion":

Issue 1: The VSIX description is a bit hard to understand:
"The Microsoft Project Reunion Visual Studio extension adds project and item templates to support building Project Reunion apps and components." When you read it, you end up in a Project Reunion recursion. 🙂 I add a break; here, so that you are not caught in the recursion and can read on.

Issue 2: Search for WinUI
When you search for "WinUI" in Visual Studio's Extension dialog, you find only the old VSIX for preview 4, but not the new Project Reunion VSIX

Issue 3: What is a Project Reunion app?
Devs I know know what WinForms, WPF, and WinUI apps are, but Project Reunion app will confuse them a lot. And I have to admit, it confuses me too. It sounds like talking about an abstraction of an abstraction. I would suggest to include here the concrete technologies, so that developers know for what they can use it. And WinUI should be somewhere there, so that a search for "WinUI" in Visual Studio's Extension dialog brings up this new VSIX. It is not clear from the description that this VSIX contains the WinUI project templates. Of course, one can read the docs, but if we can do better, I think we should do better.

Issue 4: No update notification
Note that now also all those devs wtih Preview 4 VSIX won't get an update notification, as it is now a different VSIX.

I think once the templates ship with Visual Studio, we don't care about this VSIX anymore, and my comment here becomes obsolete. But right now, it's not an ideal solution in my opinion. Maybe that's ok for a 0.5 version.

[thomasclaudiushuber]

Another concern is also the package version, as the version relates now to project reunion, and not to WinUI.

The NuGet package version is now 0.5, but we talk about WinUI 3.0. How does a developer know that it's WinUI 3.0? Just by reading the docs? Or do we forget about the WinUI version and we talk about the version of project reunion? That would mean that it would be forever WinUI 3, and just the project reunion package increases the version number in the future?

I mean, when you look at the .csproj file, you see this now, and I would say, yes, it's WinUI 0.5:

<ItemGroup>
  <PackageReference Include="Microsoft.ProjectReunion" Version="0.5.0-prerelease" />
  <PackageReference Include="Microsoft.ProjectReunion.Foundation" Version="0.5.0-prerelease" />
  <PackageReference Include="Microsoft.ProjectReunion.WinUI" Version="0.5.0-prerelease" />
  <Manifest Include="$(ApplicationManifest)" />
</ItemGroup>

Yes, I can hear already people saying WinUI 0.5, including me. So, that's definitely an impact that should be considered if this package is aligned with project reunion's versioning, and if it stays like this.

[dotMorten]

@thomasclaudiushuber I also found that you actually don't need these two packages, and can just remove them:

  <PackageReference Include="Microsoft.ProjectReunion" Version="0.5.0-prerelease" />
  <PackageReference Include="Microsoft.ProjectReunion.Foundation" Version="0.5.0-prerelease" />

It's not clear to me why they need to be there in the project templates.

[mrlacey]

@thomasclaudiushuber I also found that you actually don't need these two packages, and can just remove them:

  <PackageReference Include="Microsoft.ProjectReunion" Version="0.5.0-prerelease" />
  <PackageReference Include="Microsoft.ProjectReunion.Foundation" Version="0.5.0-prerelease" />

It's not clear to me why they need to be there in the project templates.

X-Ref: microsoft/WindowsAppSDK#560
Because I was told discission of templates should go in the PR repo

[Noemata]

I'm hoping this gets a little attention: #4445

It would alleviate a lot of pain points on multiple levels and allow the marketing folks to spin names as desired without affecting real world projects that need a measure of easily derived stability.

[Noemata]

Another concern is also the package version, as the version relates now to project reunion, and not to WinUI.

The NuGet package version is now 0.5, but we talk about WinUI 3.0. How does a developer know that it's WinUI 3.0? Just by reading the docs? Or do we forget about the WinUI version and we talk about the version of project reunion? That would mean that it would be forever WinUI 3, and just the project reunion package increases the version number in the future?

I mean, when you look at the .csproj file, you see this now, and I would say, yes, it's WinUI 0.5:

<ItemGroup>
  <PackageReference Include="Microsoft.ProjectReunion" Version="0.5.0-prerelease" />
  <PackageReference Include="Microsoft.ProjectReunion.Foundation" Version="0.5.0-prerelease" />
  <PackageReference Include="Microsoft.ProjectReunion.WinUI" Version="0.5.0-prerelease" />
  <Manifest Include="$(ApplicationManifest)" />
</ItemGroup>

Yes, I can hear already people saying WinUI 0.5, including me. So, that's definitely an impact that should be considered if this package is aligned with project reunion's versioning, and if it stays like this.

@thomasclaudiushuber , I actually like the fact that WinUI 0.5 now aligns nicely with the realities that have caught up with the WinUI 3.x spin. v 0.5 feels just right! Carl Jung's collective unconscious making it's mark at Microsoft ;-)

[thomasclaudiushuber]

@thomasclaudiushuber , I actually like the fact that WinUI 0.5 now aligns nicely with the realities that have caught up with the WinUI 3.x spin. v 0.5 feels just right! Carl Jung's collective unconscious making it's mark at Microsoft ;-)

Hey @Noemata , I think you got my comment wrong. I'm not saying v0.5 feels right to me. I'm saying it's confusing and developers might use that version number to refer to WinUI 3.0, and that impact should be considered by the team who defines the package name and versioning.

The main issue in my opinion is that WinUI 2.x and WinUI 3.0 are two different things, and by giving the package for WinUI 3.0 now a 0.5 version number, it's getting even harder for developers to understand this. Beside the version number, I think coupling it to ProjectReunion is also not good.

I would prefer something like this:

<ItemGroup>
  <PackageReference Include="Microsoft.ProjectReunion" Version="0.5.0-prerelease" />
  <PackageReference Include="Microsoft.ProjectReunion.Foundation" Version="0.5.0-prerelease" />
  <PackageReference Include="Microsoft.WinUI" Version="3.0.0-prerelease" />
  <Manifest Include="$(ApplicationManifest)" />
</ItemGroup>

[mrlacey]

This issue was started as a discussion on the naming of the package. Keeping issues focused helps the team respond appropriately. It also helps other easily follow the discussion and contribute accordingly. Having issues that expand to cover multiple issues makes it harder to follow discussions and having issues with lots of varied comments can also be off-putting for others who might otherwise contribute useful perspectives.

Separate issue about version numbering at #4508

[Noemata]

@mrlacey , you're absolutely right, but sometimes it makes sense to bundle. I opted to bundle the confusing bits here.

@thomasclaudiushuber , sorry if I coopted your view inappropriately. I should have qualified that you were referring to the potential confusion/implications of the versioning. That said, your observation is correct, the 0.5 moniker will tend to stick.

I'd rather not see a repeat of the Silverlight saga, and WinUI has elements of those mistakes already.

[thomasclaudiushuber]

@Noemata No problem Mario, there's no need to apologize. 👍

[dotMorten]

Closing this, since from the sound of it, it will change