Developing for Windows with the Windows App SDK #1615
Replies: 41 comments 191 replies
-
|
How can we use the Windows App SDK from non-MSBuild projects (for example CMake)? NuGet packages don't work there |
Beta Was this translation helpful? Give feedback.
-
|
Eventually there will be an option to us the Windows App SDK "in-app", meaning that you can package the libraries directly with your app. I'm assuming this will address your scenario? |
Beta Was this translation helpful? Give feedback.
-
|
No, in-app distribution concerns app deployment while my question is for building the app itself before deployment. You can't acquire or consume NuGet packages in other C++ build systems like CMake, makefiles, meson, ninja, etc. Unless in-app distribution would also mean that there is a way to acquire and consume the Windows App SDK during the build that isn't a NuGet package? |
Beta Was this translation helpful? Give feedback.
-
|
I'm also desperate for this option. I've raised two issues here, #1463 and #74. |
Beta Was this translation helpful? Give feedback.
-
|
Go from Win32 => Windows 8, Windows Phone Runtime => UWP => Win32. Great job MS, you make us waste our time. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
What a fool, with such reply I thought this had already been uplifted.
Apparently it is still there across several MSDN GDK docs. |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone. Dear @satyanadella @tfennel After three years, I’ve revisited this discussion with more software experience, but I still find myself confused about Microsoft's current direction. Firstly, many apps are now transitioning to WindowsAppSDK with WinUI 3. Despite this push, some flagship applications like the Microsoft Store and Media Player on Windows 11 are still UWP apps using WinUI 2. Secondly, there are plans to migrate React Native Windows from UWP to WindowsAppSDK with the new Fabric architecture. However, this migration is resource-intensive and is expected to be fully in production only by next year. Current UWP apps using React Native are functioning well like Xbox, so who can guarantee that the migration won’t introduce crashes or hidden bugs? Regarding C++/WinRT, it’s the latest effort to modernize C++ usage, particularly with C++20 features. While C++/CX isn’t compatible with C++20 concurrency, Microsoft should continue updating C++/CX given the extensive code already written. Do you understand the countless cups of coffee it took to implement those features? For C#, .NET 6, 7, and 8 should continue to support UWP for new code. Maintaining a .NET SDK for UWP shouldn’t be that difficult. As for the community, why is there no effort to integrate Vulkan code with UWP like GLES with ANGLE? Why was the UWP version of Flutter removed from the repository? There’s plenty of Java/Kotlin Android code that could be ported to UWP, potentially without needing to run APKs, similar to Project Astoria. Why hasn’t WinObjC been updated? Since the release of the Metal API, why hasn’t Microsoft supported its conversion to run on WinObjC? Why isn’t there a WinSwift to allow Swift to run with MSVC for UWP? Microsoft should provide free Copilot accounts to developers who have heavily invested in Windows development. This would ease the transition to newer projects. Microsoft needs to prioritize developer support; developers are the ones who create magic for the platform. If Microsoft wants everyone to adopt WindowsAppSDK, they need to make the conversion process less painful. Otherwise, in 10 or 20 years, we might see the same cycle: a new platform emerging while the old one becomes obsolete. Even new Qualcomm chips won’t save the situation if this continues. WindowsAppSDK is based on a mix of Win32 and Windows Runtime, yet Microsoft admits that its performance is worse than UWP with version 1.5. Why are we back to square one after three years? Let’s look at what Apple has done with the Mac. The Mac can now run Mac Catalyst, enabling UIKit apps to run on Mac with recompiled code. They even allow iPad-designed apps on Mac. Apple provides developers with choices for the best method on Mac, ensuring smoother transitions, even if it means buying new hardware. |
Beta Was this translation helpful? Give feedback.
-
|
C++/WinRT is in maintenance mode, good luck with anyone caring. Quoting the team,
|
Beta Was this translation helpful? Give feedback.
-
Yeah, I noticed Kenny Kerr, who is an architect behind c++/winrt not showing too much at Build conference. But I need to stick with UWP because some features Win32 never can give to me. |
Beta Was this translation helpful? Give feedback.
-
|
I simply don't understand how you can tell us "if you're happy with your current functionality in UWP" -- we're pretty much 8 years behind any decent advance there has been made. I can't even begin to tell you how many things are wrong with UWP/WinRT, but here are a few of the top of my head
These are stuff you deal with every day as a lucky UWP developer. There's more -- I could write a book. |
Beta Was this translation helpful? Give feedback.
-
@WesleyKhoiVo Yeah, it's beyond sad. And did I mention I'm not using .NET native? (because of their ridiculous restrictions on the libraries I can use). I've said this countless times in the past -- it's clear that Microsoft developers knew what a pile of **** (insert your favorite curse there) WinRT was, and pretty much everyone was avoiding to work on it. No one would optimize anything -- it's always been "it works, leave it alone". Same for the speed of searching for files using We've been promised faster compile times for quite a while now, until MS changes its tune and said "UWP is not the way forward". |
Beta Was this translation helpful? Give feedback.
-
|
The AppInstaller reboot issue is one I debugged yesterday. See here for a workaround: MicrosoftDocs/msix-docs#188 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
@mikehearn Thanks! I did take a look, but I'm afraid to do what you say, since I've seen the comments afterwards, especially from @nbevans -- saying it's still not working. It's beyond sad that MS is not addressing this. Note that they know about this for about 1.5 years -- there's another insanely big thread in another MS forum (I used to have link), which started on May 2020. As I said, I've basically gone around the .appinstaller altogether and it's very likely I'll stay away from this for a looong time. I mean, even if/when they hypothetically fix it, just imagine how long it would take for that update to hit all Windows computers. I'm guessing best case scenario is 6-9 months. This is "bad" at a whole new level. P.S. Just the fact that that issue is STILL CLOSED after several people HAD TO ASK for it to be re-opened, just shows how much Microsoft cares. |
Beta Was this translation helpful? Give feedback.
-
|
@jtorjo I think it is quite clear that WinRT was pushed by COM and ATL folks at Microsoft, that think anything else is a waste of time and we should all be coding in C++. Everytime we on .NET side get some productivity love for Windows APIs. they manage to spoil it with C++ APIs pre-NET programming experience. |
Beta Was this translation helpful? Give feedback.
-
@pjmlp It's possible 😁 And horrible... And I have a few other words to describe it. WinRT has been/was/is/will be a complete disaster, yet they still push it forward... It's impossible for me to understand why... |
Beta Was this translation helpful? Give feedback.
-
|
I asked on the WinUI group, but I'll ask here again: The reason I ask is that I assumed |
Beta Was this translation helpful? Give feedback.
-
|
Windows.Media.Editing.MediaComposition works outside of UWP, so you can call it on WinUI 3. There is no need to port. |
Beta Was this translation helpful? Give feedback.
-
|
In UWP we get native compiling and good speed , I know you can also get encrypted appx packages on UWP that encrypts the binaries on windows to prevent reverse engineering. (never used this feature myself) Switching to WinUI3 / .Net 6 we obviously don't have native compiling but is there an equivalent of eappx (encrypted appx) for WinUI3 / .NET 6 apps ? If we can use encrypted binaries on windows for WinUI3 /.NET 6 apps then the migrations path becomes alot easier especially on those UWP apps where security is important. |
Beta Was this translation helpful? Give feedback.
-
|
@Pinox Yeah, Native on WinUI3 would rock big time. Microsoft? I know there are some plans, but I don't recall seeing anything official |
Beta Was this translation helpful? Give feedback.
-
|
I think native is coming but it's going to take time but in the mean time MS can give us enterprise encryption to bridge the gap. MS enterprise encryption already exist so this is not something new that needs development. It will make a huge difference for those that requires security. |
Beta Was this translation helpful? Give feedback.
-
|
Can developers working with Windows Forms actually port their projects to WinUI 3 or is WinUI 3 pure XAML like UWP/WPF? Will it be possible at all to offer WinUI 3 apps also portable, just an executable file which contains everything needed ? What about the support of WinUI 3 apps on server environments, where there is not even the Microsoft Store to get apps? |
Beta Was this translation helpful? Give feedback.
-
|
No, you can manually create and lay out controls in code. Although there is no designer yet. |
Beta Was this translation helpful? Give feedback.
-
Have a look at Comet, it does just that and WinUI is supported: https://github.com/dotnet/Comet |
Beta Was this translation helpful? Give feedback.
-
No. You cannot develop the UI in code in WinUI 3. I heard they are planning to support it, but that is not coming. So, you cannot write the UI in C#. Those guys love xaml so much that they coupled WinUI with xaml. So, it would be difficult to produce a UI library to write UI using code. But, UNO Platform and Comet .NET Maui are suitable candidate for that. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Apparently it's a work in progress, have a look at Either way, you don't need MAUI to use WinUI from C# without XAML, here's an example from Windows App SDK:
|
Beta Was this translation helpful? Give feedback.
-
|
Is there Map control in WinUI3 now (not some day in the future)? |
Beta Was this translation helpful? Give feedback.
-
|
I can't. There is no offline support. You can't rotate google map with center offset. If you tilt the map street names are laying flat on the surface. |
Beta Was this translation helpful? Give feedback.
-
|
@nesherhh I wouldn't keep high hopes about it: microsoft/microsoft-ui-xaml#3024 |
Beta Was this translation helpful? Give feedback.
-
|
I don't. I have ported XAML Islands to .NET 5 and can use now MapControl with .NET 5/6 (https://github.com/nesherhh/XamlIslandsNET5). |
Beta Was this translation helpful? Give feedback.
-
|
I'm impressed, that's a great reminder of what lengths people must go in order to work around Microsoft's framework failures. |
Beta Was this translation helpful? Give feedback.
-
|
The lack of MapControl is blocking for me as well. It's disappointing how long it's taking for WinUI 3 to reach feature parity with UWP. |
Beta Was this translation helpful? Give feedback.
-
|
What are you guys even doing? Why are you not improving UWP instead of constantly creating new frameworks. Now we are back to WinForm/WPF and Win32 with fancy incompleted WinUI3? Don't you think it's embarrassing that a massive platform like Windows has 0 competent app development platform for years, almost a decade? Windows is one of the olders platforms... Meanwhile you keep running around in circles... truly no words for this. |
Beta Was this translation helpful? Give feedback.
-
No, there's nothing exciting to see here honestly.
Why can't we have .NET 5/6 for UWP App Service projects? This is pitiful investment from a multi-trillion dollar company. Nothing here constitutes a proper migration strategy, since as noted in the post, Windows App SDK is not a strict superset of UWP. There are two options. Magically accelerate the pace of WinAppSDK to become a strict superset of UWP (including target platforms), or provide a route to running .NET 6 on UWP. Otherwise, I might as well jump ship to Flutter, which somehow has a better strategy for targeting Xbox than Microsoft does. Only providing official support for running .NET 5/6/whatever in a UWP App Service project, but not for the UI layer, would still be an acceptable solution. This would allow slowly porting code over from UWP to WinUI 3. Even a "beta" tag that will never be removed on .NET 6 on UWP would be an acceptable solution. |
Beta Was this translation helpful? Give feedback.
-
I don't have an issue whether C++ is first class citizen or second class, or X class citizen. No, C/C++ doesn't have to be the logical choice -- and I'm saying this as having programmed C++ for 13 years. If the .Net port is too slow, then the problem is related to that port, and should be fixed there. There's really no reason why C# code has to be slower than its C++ counterpart. Had MS actually cared about its developers, that's what should have happened. |
Beta Was this translation helpful? Give feedback.
-
|
@sylveon Thanks for making the point and revealing the lack of experience with Apple and Google modern APIs across their OSes for Swift, Java and Kotlin. I suggest comparing that boilerplate with using Metal from Swift. |
Beta Was this translation helpful? Give feedback.
-
Now compare to how it should be: using Windows.ApplicationModel.UserActivities;
using WinRT;
var activity = new UserActivity("test");
var str = "some source host";
activity.SetActivitySourceHost(str);It's 2021 folks. Not 1998. |
Beta Was this translation helpful? Give feedback.
-
|
You can probably fill a GitHub issue on the cswinrt repo so that the interop interface for UserActivity is added, then it'll be very similar to this. |
Beta Was this translation helpful? Give feedback.
-
|
We are just giving examples, there are endless of them, actually WinUI is now topping around 2200 issues and growing, not counting all the little project islands that keep ping-pong between who owns what. Not only we get asked to rewrite the code yet again, using archaic C++ tooling and boilerplate code from the yearly days of .NET and COM integration, we apparently have to point out to Windows team what is missing, and then hope that someday, the feature might be implemented. Spend a couple of weeks using the modern stacks from the competition. I don't need to submit tickets for having OS capabilities exposed to Swift or Java/Kotlin, or writing boilerplate wrappers to manually convert between two Windowing stacks. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Don't worry, there will be something new in 5 years or less. |
Beta Was this translation helpful? Give feedback.
-
|
I have always asked the question who is the executive on MS board level who is driving this process. Either you don't have the right executive driving this process or you don't have enough resources. The fact that MS pays $7.5 billion dollars for Github but are not willing to spend money on a proper cohesive strategy to sort out this mess is evident interacting with MS employees. There is a massive lack of resources and that is always evident because when there is new development then resources needs to be pulled from other projects so the end result is you end up running in circles all the time. The building blocks are all there at Microsoft but they don't have enough resources to finish the job. As someone once said. The last 10% of a new project takes 90% of your time. This has always been the problem at MS , you don't sort this out on MS board level you will never fix the problem. |
Beta Was this translation helpful? Give feedback.
-
|
I mean the filesystem problem and frequency of AOT compiler updates probably makes up about 10%, so yea this checks out. |
Beta Was this translation helpful? Give feedback.
-
|
R.I.P. Xbox apps since they seem to have completely forgotten they exist. |
Beta Was this translation helpful? Give feedback.
-
|
@pjmlp I'm not sure what you mean about Hololens having deprecated UWP. Hololens apps are all UWP. For example, Unity compiles a Hololens app to a Visual Studio UWP project. So, this news about UWP no longer being developed leaves open questions about the future of apps on Hololens. |
Beta Was this translation helpful? Give feedback.
-
|
@binarynate You just have to go read Hololens documentation.
Afterwards you can go read Getting started with OpenXR and the you will land in Native development overview and can follow the link "If you have an existing WinRT project that you'd like to maintain, head over to our main WinRT documentation", which will bring you to.
Clearly WindowsAppSDK/WinUI teams don't talk with Hololens/XBox teams, or for whatever reason, pretend they aren't aware they have long deprecated UWP/WinRT. |
Beta Was this translation helpful? Give feedback.
-
|
@pjmlp My point is that when you build a Hololens app with Unity, the build artifact is a UWP application. You have to set Unity's build platform to UWP because that's what Hololens requires. |
Beta Was this translation helpful? Give feedback.
-
|
HoloLens documentation is quite clear, WinRT is legacy and everyone should move into OpenXR + Win32. Legacy WinRT support is there, and naturally Unity still allows it. I am not a Unity user, so I cannot tell you what they are still missing from OpenXR roadmap. |
Beta Was this translation helpful? Give feedback.
-
|
As far as I know on HoloLens UWP and WinRT are still the way to go, only the Mixed Reality WinRT APIs are legacy (but still work). Your code is still using UWP package with WinRT, just you do not use WinRT API for managing the headset, but you use OpenXR instead. |
Beta Was this translation helpful? Give feedback.
-
|
Once again you abandon a framework. How disappointing! Why there is no place for UWP |
Beta Was this translation helpful? Give feedback.
-
|
Politics and borked execution, sadly. Like the lack of respect to replace C++/CX without providing feature parity in the tooling. Last one please turn off the lights. |
Beta Was this translation helpful? Give feedback.
-
|
Some comments, for what they are worth, from someone who just started migrating an existing UWP/Desktop bridge app (SyncFolder, available on Windows Store) to WinUI 3 Desktop (Packaged). The most important reason for doing this is: Get rid of the The existing app makes use of a win32 full trust process that takes care of copying files and folders from and to various type of storage devices, like: mass storage (internal drives, NAS, USB, ..), MTP devices, FTP(S), SFTP, and OneDrive. Add to that a background scheduling task, a portable USB device watcher task and the need to allow a copy task to start when pressing a button on a toast notification. One could argue why such app (2 years ago) couldn't be better designed using WPF/Forms, but there was a simple reason for that: a UWP/DesktopBridge app can be distributed using the Windows Store. The app is free and the Windows Store makes it visible and available for everyone without me bothering about it. The app is relatively big: +30 Views (Pages and ContentDialogs), 10 ViewModels, +10 nuget packages, +2000 files, multi-language. I started the migration process about a week ago and finished the UI side of the porting. There were a couple of things that needed some attention, but overall migrating the UI goes easy. The following will require your attention:
For me, doing this as a hobby, the effort is not so important (40 hours so far), but I can understand that if you have to do this business wise this will cost you. What I learned though is that by doing this, the whole app gets a much better architecture, I could improve certain implementations here and there, and are convinced that this makes it easier for me to keep on adding features to the app. This is important for me: the current app got 25 updates until now, mostly updates because of user requests, remarks. To be honest, I am waiting for WindowsAppSDK V1.0 to be released in order to be able to publish the migrated app on the Windows Store. That leads me to 1 question: How will this work?
|
Beta Was this translation helpful? Give feedback.
-
|
thanks @JosHuybrighs Many of your points are also relevant to me. Microsoft please put this in a separate github thread where everyone are encouraged to document the issues they faced converting UWP apps to WinUI3 with recommended solutions. This will save everyone an enormous amount of time and reduce the conversion friction in a big way. |
Beta Was this translation helpful? Give feedback.
-
|
@JosHuybrighs - thanks for all the details! To answer your specific question, yes you can simply publish a new version of your existing application under the same identity. Users who have the old version will get updated to the new version. You may want to add some logic to your app to handle that upgrade. There are no additional prompts for updates. |
Beta Was this translation helpful? Give feedback.
-
|
Perfect! |
Beta Was this translation helpful? Give feedback.
-
Just to confirm, is this updating an existing UWP app on the Windows Store with a packaged Win32 app? We were recently told that this scenario is not yet supported. Is there some official documentation on this? |
Beta Was this translation helpful? Give feedback.
-
@jonwis - I hope that this is not the case. My current app on the Store is a DesktopBridge app with 2 apps in the package: a UWP app for the UI and a c# win32 Forms app (without a window) for doing file backup/sync in fulltrust mode. I expect that I can migrate the app to a WinUI Desktop app and that I can update the existing app by simply uploading a new MSIX bundle with a submission update on the current app in Microsoft Partner Center. |
Beta Was this translation helpful? Give feedback.
-
|
We've spent a lot of time and effort producing UWP apps only to be told it is being abandoned. |
Beta Was this translation helpful? Give feedback.
-
|
Your investment is not lost - the Windows App SDK API closely matches the UWP API in most cases. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, good to know. I do hope it has less bugs than UWP, sometimes it seems that as soon as Microsoft has fixed the issues with one platform they depreciate it to move on a new quagmire! |
Beta Was this translation helpful? Give feedback.
-
|
@sylveon Most cases is not all of them. We are getting asked to still believe, while going through yet another rewrite. On top of that we get thrown into stone age of Windows development when Windows team, with straight face, proposes that having to deal with raw IDL files without any kind of tooling is a modern development experience! If we need to rewrite, at least we go to platforms that are actually modern. |
Beta Was this translation helpful? Give feedback.
-
I think Microsoft always like to change the commercial name of Windows Runtime, from Modern/Metro to UWP, and to Windows App SDK. It's really confused for developers because they think Microsoft always abandons frameworks. But in the current situation, I don't think Windows App SDK is more stable than the old UWP XAML with XAML Islands because most of current Microsoft products still use the WinUI 2, the extended wrapper for UWP XAML. For example, the Windows Terminal. Kenji Mouri |
Beta Was this translation helpful? Give feedback.
-
|
How can you bring out a first version in which the MediaElement and InkCanves are not supported? |
Beta Was this translation helpful? Give feedback.
-
|
While I greatly appreciate that the limitations of XAML islands from the original UWP XAML are fixed here for the desktop I have a number of problems or at least questions as well, mostly about future direction, which I think is very important to be clear. Currently the WindowsAppSDK is not nearly complete compared to UWP and it does not support HoloLens and Xbox. For one there is no information on what will happen on those devices going forward on the long term, only that they remain UWP for now. I am lucky since I only use C++ with UWP, and that seems to get all the latest features still. But it is a question will Windows App SDK get an UWP like limited API mode to target these systems without the legacy Windows components (which is basically UWP with rebranding)? Will the legacy stuff packaged as well (this would be bad IMHO)? The other question is that will Windows App SDK offer UWP like features, like the containerization, the removal of ancient APIs which makes it safer, faster to compile, the application access rights (capabilities, like access to the camera, filesystem etc.) and allow leaner versions of Windows later. I understand that the Win32 projects need the love more now. But it is a question: will you undo all this good stuff and go back 10 years? Or will you add support later? I already ported over an existing packaged non-UWP XAML Islands C# project to Windows App SDK, and it was fairly quick after I figured out the project configurations, most of the time was spent on updating some custom control UI styles to match the new built-in control styles (I was using the original WinUI). In my opinion UWP should be an API profile in the new SDK, so the developer can select the right scope for device reach and API availability as required. If he needs Xbox or HL, or some upcoming no legacy shell Windows option he can select an UWP like scope or select a wide desktop only scope, with a simple project setting. Also my strong suggestion to the MS SDK teams: never ever declare something legacy until the next thing is complete. That makes zero sense. In practical terms I feel that UWP only became usable in the last few years, ideally it should not had been released as 1.0 until this. You can still announce where you go forward, but do not ask devs to use unfinished frameworks just because those are "the future". As in my observation no new technology in this area is really the future at Microsoft, since as soon as it becomes near usable it is already legacy. This happened with so many things that it is not even funny. I used to be sarcastically saying to myself, if Microsoft declared something legacy it is now ready to be used, but that is basically the truth at this point. I am guilty as well, jumping to newest stuff, but I no longer suggest that to others. In fact right now I would suggest them to wait until all this new shiny SDK is declared legacy and start using it at that time, as by that time by the past trends: it will be feature complete, it will have many examples and documentation, it will have vastly more features than whatever new thing comes after it, it will no longer change significantly, its future will be entirely clear etc-etc. |
Beta Was this translation helpful? Give feedback.
-
|
One more thing: while I agree with providing a nuget version of WinUI, which allows us to use the latest features independently of Windows, I also think you should keep updating Windows.UI.Xaml as well to provide a baseline, and do away with this Microsoft.Ui.Xaml namespace stuff. So apps can use the version shipping with Windows as well and do not require a different namespace. This would make it much more like a continuation and make the switch easier as well, in fact it would require no switch at all, old Windows would pull the additional dependency package, and new one would have it installed. Having that obsolete API there makes zero sense, when you actually keep developing it, it is a very ugly solution. |
Beta Was this translation helpful? Give feedback.
-
|
everyone was waiting for , net 6 and this is what we got...after 3 years :(
such a shame.... Thanks GOD I only learned FLUTTER and it is so powerful
let's me make apps for win32 and UWP as well!
[image: Mailtrack]
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
Sender
notified by
Mailtrack
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
12/01/21,
07:33:33 PM
…On Mon, Nov 29, 2021 at 1:20 PM Péter Major ***@***.***> wrote:
One more thing: while I agree with providing a nuget version of WinUI,
which allows us to use the latest features independently of Windows, I also
think you should keep updating Windows.UI.Xaml as well to provide a
baseline, and do away with this Microsoft.Ui.Xaml namespace stuff. So apps
can use the version shipping with Windows as well and do not require a
different namespace. This would make it much more like a continuation and
make the switch easier as well, in fact it would require no switch at all,
old Windows would pull the additional dependency package, and new one would
have it installed. Having that obsolete API there makes zero sense, when
you actually keep developing it, it is a very ugly solution.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1615 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRXJSDSPTILG4QLI7WZVZDUOMZWTANCNFSM5GH5XQBA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
|
Is this going to work for Assigned Access single-app kiosks, since the Set up a single-app kiosk doc shows that Win 10 Pro only supports UWP apps for Assigned Access? |
Beta Was this translation helpful? Give feedback.
-
|
Hi folks, please vote on the portal card here if you need single-app kiosk: https://portal.productboard.com/winappsdk/1-windows-app-sdk/c/62-support-single-app-kiosk I've found the feature team that owns this and they're evaluating business justification to add support for desktop apps, so voting via the portal link above is the best way to help with that! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@andrewleader, any updates on whether WindowsAppSDK will ever work for Assigned Access single-app kiosks? |
Beta Was this translation helpful? Give feedback.
-
|
@ppena-LiveData the team is currently all off on holiday, but the single-app kiosk team will be looking at the customer requests when they're back. To set some context, our releases and planning cycles are usually on a 6-month cadence, and we're just finishing a planning cycle, so hopefully we'll know soon if support will be part of the next release. The team will share updates on single-app kiosk through the productboard portal card, so vote there to keep updated! |
Beta Was this translation helpful? Give feedback.
-
|
@andrewleader is there any update on this? We're really struggling with UWP and desperately need to plan a migration path forward. |
Beta Was this translation helpful? Give feedback.
-
|
maybe for new people .net 6 would be better.... But still cant
understand, if .net 6 can make phone,web and desktop...then why do we need
blazor and other tons of options??? also better yet why not use UNO
platform? Why no one talks about UNO platform.
[image: Mailtrack]
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
Sender
notified by
Mailtrack
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
12/11/21,
03:02:34 PM
…On Sat, Dec 11, 2021 at 2:25 PM Carlo ***@***.***> wrote:
Lack of AOT for code obfuscation is blocking me since I started with C# 12
years ago 😆 (except for UWP which was discontinued).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1615 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRXJSBQ3JQE2EKULWE4VXDUQMKHNANCNFSM5GH5XQBA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
|
Well, if I want a well documented easy to use toolset to start building a new app, I'm not sure this is where I'd start. And after the many abandoned efforts to modernize Windows application development, and the amount of outdated MS documentation about the subject, I'm very very skeptical of your efforts. I hope you get the hint and invest heavily on modernizing Windows development, and commit to it. And hopefully, you'll make it accessible for developers too. You are behind the curve, as a dev, I'd rather spend my days building Android apps, iOS apps or macOS apps. For the love of all that is holy, get your sh!t together and make something that people are legitimately excited to use. People are already excited about C# and .NET 6, capitalize on that, please. |
Beta Was this translation helpful? Give feedback.
-
I'm aways on the 'win32' road 。 |
Beta Was this translation helpful? Give feedback.
-
|
I think if you do graphics then native C++ and COM with the C++/WinRT base.h helper classes is a good choice, and it results in clean code most of the time. From C++ you get direct, full speed access to the DirectX framework, whichis very powerful. On the other hand you need to learn C++, and most C++ code samples are very old and ugly with WinAPI. However if you use modern C++ 17 or later, and you utilize the standard library well and if needed use C++/WinRT (or even Win32 for threading and other simple low level stuff) you get a decent experience. This is subjective of course, I developed in C# for 15 years or so (started early in highschool), and then C++ also for 5+ years. It was harder at start, but I enjoy its precision compared to C#, however I do computer vision and 3D graphics so not LOB apps. |
Beta Was this translation helpful? Give feedback.
-
@jtorjo Please do make a port to Mac. I read all you messages and feel your pain - you need to break from the suffering, evolve and use the platform which gives you what you want. |
Beta Was this translation helpful? Give feedback.
-
|
@jtorjo Apparently there is an official WinUI3 version of Win2D called Microsoft.Graphics.Win2D, it is on nuget, but I have not used it before. |
Beta Was this translation helpful? Give feedback.
-
@Torquerrr Thanks! Well, that is the plan. I have a lot of things to do before that, but yeah, that's the next step. I can't even begin to tell you how many hours I've wasted on the joke that is UWP. |
Beta Was this translation helpful? Give feedback.
-
Yeah, known about it for quite a while. That's, obviously, not a complete port by far. Pretty much everything important is not ported yet. |
Beta Was this translation helpful? Give feedback.
-
|
kepp chirping..... MICROSOFT has failed once again!!! and will do same....
until they fix .net 7
[image: Mailtrack]
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
Sender
notified by
Mailtrack
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
12/24/21,
11:05:53 PM
…On Thu, Dec 23, 2021 at 9:20 PM pjmlp ***@***.***> wrote:
I don't care if C++/WinRT is ISO compliant when it requires one to be
masochistic enough to travel back in time to the glory days of Visual C++
6.0 IDE tooling.
The beauty of Qt and C++ Builder, is that not only I don't have to deal
with UWP any longer, my code is also cross platform.
I bet I am not the only burned one that C++/WinRT team has managed to push
away with their lack of vision on how C++ GUI tooling is supposed to look
like in the 21st century.
—
Reply to this email directly, view it on GitHub
<#1615 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRXJSEYSMTCIDQV4NW3EBTUSND3JANCNFSM5GH5XQBA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for posting this. Couple of questions/suggestions.
|
Beta Was this translation helpful? Give feedback.
-
|
@Torquerrr QT is C++, and last time I worked with it, it was pretty bad (but yeah, that was more than 10 years ago). I moved away from C++ for a good reason -- the legacy of C is achile's heel here. No matter how much C++ advances, is simply snail steps compared to any other language. That being said, my code is not open source. And it's huge -- my plan is to use UNO. But for the rendering module, I guess I'll have to use Metal. |
Beta Was this translation helpful? Give feedback.
-
|
My solution:
Using abstract layer library is great idea to keep your app or game not depend so much on OS provider. Keep in mind that Apple is also do something same idea with Microsoft, they deprecated OpenGL/GLES to create Metal, they never implement Vulkan on their OS. This mean if they deprecated Metal to make something new, you must be update your code. |
Beta Was this translation helpful? Give feedback.
-
That will be current CEO the chutiaNadella . Windows died the day he(chutiaNadella) started Microsoft❤Lunatix (Lunatix = Religion of Atheist's Liberalism sect's "Everything Must be Open Sourcism" subsect crowd, name of their bible is the Gospel of Linux) All of that started in 2014, too. Situation won't change until he is kicked off. it's been almost 2 year since WindowsAppSDK is being developed on ShitHub, wait for another 2 years to get the most basic feature like Elevation support 😂 It is a fact the development speed of WindowsAppSDK is simply crap Now, Since WindowsAppSDK exists in Open Source. you may ask Why?
Dont ignoramously repeatedly equate UWP shit = WinRT, WinRT is sugercoat over COM , Everytime you try to do that it sucks. Nice try though In fact, It is expected that the .NET_crap devs to have "the COM is shit" assumption, since .NET was created in the first place to please small the small brain devs who couldn't understand or cook COM well or at all. |
Beta Was this translation helpful? Give feedback.
-
|
@WesleyKhoiVo Thanks! I will look into ANGLE - the thing is I need insane speed, otherwise it's not worth it for me. My app's first 3 iterations were: use controls to do animations - WPF (pre-MVP), then use DirectVisual (WPF), then had to switch to Direct2D (win2d/uwp). So the idea is -- if ANGLE is not fast enough, I can't use it. |
Beta Was this translation helpful? Give feedback.
-
|
@jtorjo You are welcome 😁. But remember: ANGLE performance is not excellent, is just very good (it not fast as OS graphic API because this need translate shader and mapping OS graphic API). You can see the most popular project use ANGLE is Chromium (original of this project is convert WebGL content to DirectX because in that time 2010-2012, IE is not support GLES) simple and medium scene can run smoothly, but I can't confirm it run smooth with very complex scene. One another thing is ANGLE is still keep as GLES 3.2 when Khronos move to Vulkan so some latest graphic effects are not available. But overall, behind ANGLE is Google and Khronos, so it still keep improve performance in future and API is not quickly deprecated like DirectX/Metal. Microsoft also support ANGLE for Win32, UWP so use this library is good idea for official support. So I RECOMMEND use this library than other solution.
Other solution use Vulkan with MoltenVK. With Windows PC, Linux, Android it will give you 100% performance. But Mac, iOS doesn't have Vulkan so we must use library MoltenVK for translate to Metal, so it will meet same scenario like ANGLE - performance is just very good, not excellent. Another bad thing of Vulkan is it need newer hardware device from 2015-2016, if you target some older devices, looking ANGLE instead. If you want 100% performance for all device, you may be want looking BGFX (because this just abstract API). But the bad of this project is there isn't stable release or tag, just use master branch (that why I don't like it). 😑 |
Beta Was this translation helpful? Give feedback.
-
|
Will someone talk about UNO platform????
[image: Mailtrack]
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
Sender
notified by
Mailtrack
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
12/26/21,
08:23:23 PM
…On Sun, Dec 26, 2021 at 3:57 PM John Torjo ***@***.***> wrote:
@jtorjo <https://github.com/jtorjo> I don't want to say A or B but since
2014 (current administration), msft had done basically nothing for the
desktop developers. Recently it changed but it took quite too long and I
see a dead end on this... It is funny how years of career focus on
something can go down the hole when the administration changes...
Yeah, I know... Things went downhill before that, with the coming of
Windows 8, and their whole WinRT "revolutionary" thingy. And WinRT creeped
up pretty much in every (Windows) place imaginable. I'm not sure the top
heads at MS realize just how bad this is, and obviously, they will NEVER
admit that publicly.
—
Reply to this email directly, view it on GitHub
<#1615 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRXJSGWPAVMTSYSHTRY2JTUS3YKJANCNFSM5GH5XQBA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
I can't help but think of how monumental an achievement lifting the UI out of the kernel is. It must also represent a deep dive into some pretty old and hoary code. It's quite a milestone. With WinUI3 as a base, I firmly believe only good things will come our way rapidly. |
Beta Was this translation helpful? Give feedback.
-
|
The only thing I see rapidly increasing are the number of Github issues, exponentially. If they keep burning the few of us that still believed, the only developers left using WinUI are the Windows dev team themselves. |
Beta Was this translation helpful? Give feedback.
-
here comes another nonsense. the whole UI stack is usermode in NT Kernel. WinUI 1 is usermode code, WinUI 2 or 3 is just another regular library.
slogan-ing like the same UWP crowd that used to slogan, MiCroSoFT sHoUlD MaKe eVeRy ApP UwP |
Beta Was this translation helpful? Give feedback.
-
UWP does not run on Win32 according to official statements, it runs on WinRT layer which runs directly on the kernel layer just like Win32. |
Beta Was this translation helpful? Give feedback.
-
WinRT is NOT a subsystem. it is Sugercoat(abstraction layer) over COM, COM itself runs on win32 subsystem.
without win32 subsystem , your so called "UWP apps" (which itself is just another win32 app) wouldn't even exist. see #1942 (comment)
that's the 2011 Build Narrative, pushed further by some Blogs. That's what marketing does for you. |
Beta Was this translation helpful? Give feedback.
-
|
@EP012014 Think UWP mainly as a Win32 API subset, which does not contain many legacy components like GDI. Other stuff, like Win32 multi-threading APIs (e.g. CreateThread) and COM (e.g. DirectX) is still included. You can also use WinUI which is a UI framework and application model. And UWP also includes MSIX packaging. However almost all of these UWP features could have been used in desktop apps for a while now, WinUI 3 (when it will be feature complete) will make desktop use more convenient. In turn the new SDK will likely offer an UWP like API subset as target under some new name, so it can target Xbox, HoloLens and other non-full desktop Windows based systems. |
Beta Was this translation helpful? Give feedback.
-
|
The increasing number of Github issues could be construed as a sign of progress (from the right angle.) |
Beta Was this translation helpful? Give feedback.
-
|
It is emerging since Windows 8 was released and already went through 5 rewrites. |
Beta Was this translation helpful? Give feedback.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
-
|
I think MAUI .net 6 is the only (really) supported platform with inovation
and new things coming etc u can target any thing ith fluent Ui in it
[image: Mailtrack]
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
Sender
notified by
Mailtrack
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&>
01/08/22,
05:19:10 PM
…On Mon, Jan 3, 2022 at 4:15 PM Péter Major ***@***.***> wrote:
@EP012014 <https://github.com/EP012014> Think UWP mainly as a Win32 API
subset, which does not contain many legacy components like GDI. Other
stuff, like Win32 multi-threading APIs (e.g. CreateThread) and COM (e.g.
DirectX) is still included. You can also use WinUI which is a UI framework
and application model. And UWP also includes MSIX packaging. However almost
all of these UWP features could have been used in desktop apps for a while
now, WinUI 3 (when it will be feature complete) will make desktop use more
convenient. In turn the new SDK will likely offer an UWP like API subset as
target under some new name, so it can target Xbox, HoloLens and other
non-full desktop Windows based systems.
—
Reply to this email directly, view it on GitHub
<#1615 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRXJSEUSNQQX2TCAPUMPYLUUGAOFANCNFSM5GH5XQBA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
As long as the anything set doesn't include GNU/Linux. |
Beta Was this translation helpful? Give feedback.
-
|
I have many questions; here are some of them. Our UWP app consists of about 150,000 lines of code to port from UWP, written in C# & C++.
I hope this will not cause significant technical debt for us and porting these items over will be fairly simple. |
Beta Was this translation helpful? Give feedback.
-
|
To put it simple, good luck. Pen isn't supported, https://stackoverflow.com/questions/76402872/is-inktoolbar-available-in-winui-3 If you are still using C++/CX for UWP, you will need to rewrite everything into C++/WinRT, and Visual Studio provides zero support for editing the IDL files required by C++/WinRT for XAML integration. XAML WinUI 3 and XAML UWP aren't exactly the same 1:1, plenty of capabilities still missing. You're better off using the standard DirectX COM API. On the plus side, you can use Python, Windows Services for the background tasks, and as long as you package the application as MSIX you're gold for the Store. |
Beta Was this translation helpful? Give feedback.
-
This is one of those difficult things where the UWP inking functionality is fully available for desktop applications. So while the UWP Xaml inking controls aren't available, the pointer functionality is available and the custom inking is available too. The ComplexInk UWP sample has a portion of the sample that is using the InkD2DRenderer targeting a Direct2D device context. It also uses the Windows.UI.Xaml.Media.Imaging.VirtualSurfaceImageSource to place the ink content into the Xaml image tree. |
Beta Was this translation helpful? Give feedback.
-
|
Please read and act accordingly!
The link again: Oh! And SPREAD THE WORD! |
Beta Was this translation helpful? Give feedback.
and others
-
We hope you're excited about the new features in the Windows App SDK and WinUI 3! 🥳 To help you determine when and how you should use the Windows App SDK, we’ve put together a few frequently asked questions.
What is the focus of the Windows App SDK?
The Windows App SDK is focused on empowering developers to build the most productive apps on Windows. To achieve this, we are using the existing desktop project types as the foundation of the Windows App SDK, due to the vast amount of existing desktop APIs and compatibility that desktop project types provide. Additionally, we are making our existing UWP platform investments easier to consume by desktop project types and enabling new capabilities like AI & Fluent Design. As we enable these new capabilities, we are lifting more libraries from the OS into the Windows App SDK, so we can deliver on the agility and backwards-compatibility developers need to reach across the entire Windows ecosystem.
What does the Windows App SDK mean for UWP and desktop developers?
For developers using the Universal Windows Platform (UWP) project types, if you are happy with your current functionality in UWP, there is no need to migrate your project type. WinUI 2.x and the Windows SDK will continue to support UWP project types, including bug, reliability, and security fixes. In Windows, we use UWP project types for several of our own Windows apps. If you want to use the Windows App SDK or .NET 5 in your existing app, you can migrate your project to a desktop project type as described in the migration section further below.
For developers using a desktop project type (WPF, Windows, or .NET 5+), you can simply add the Windows App SDK as a NuGet package and get access to all the new APIs.
Our goal is to make the Windows App SDK the superset of the capabilities of both desktop and UWP – which would give developers a single path forward. We are using desktop project types as the foundation of our convergence.
How should I think about the future of app development on Windows?
We are making it easier and faster to build great desktop apps via the Windows App SDK and WinUI 3, and continuing to make it easier to empower your UWP app with desktop functionality by improving the migration experience. There are many excellent choices to consider when building a new Windows app. For native Windows desktop apps, we recommend investigating WinUI 3 first and seeing if WinUI 3 meets your needs. See our roadmap and the WinUI 3 roadmap to get an idea of what’s available now and what’s coming. Please continue to engage with us and let us know what's blocking you so we can plan and prioritize your most critical features!
What if I have a UWP app and need .NET 5/6?
If you need to use .NET 5/6 in your UWP project type, we recommend you migrate your project to a WinUI 3 desktop project, since .NET 5/6 will not be coming to UWP project types. See the migration section further below for more info.
What if I want to develop an app with web content?
WebView2 provides the best way to use web content in your native Windows app. It is currently available for WinUI 3, WPF, and WinForms. WebView2 is in the process of being added to WinUI 2, and will become stable soon.
What would migrating project types from UWP to desktop look like?
If you are happy with your current functionality in UWP, there is no need to migrate your project type. WinUI 2.x and the Windows SDK will continue to support UWP project types, including bug, reliability, and security fixes.
If you’ve decided to migrate, you should first be aware of some functionality that is not yet supported in WinUI 3 and the Windows App SDK. If your app needs any of these features/libraries, you should consider waiting to migrate. UWP project types are still supported by WinUI 2.x and the Windows SDK.
When migrating, in most cases, your UI code just needs a few namespace changes. Much of your platform code will stay the same. You will need to tweak or change some code based on different functionality/availability in desktop apps vs UWP apps. We expect migrating most apps to be in the order of days rather than weeks.
At a high level, to migrate your app, you would...
See the migration docs to learn more about how to migrate! For those of you who have migrated, please share your feedback with us so we make improvements and include issues you ran into in our documentation. Please continue to engage with us and let us know what's blocking you so we can plan and prioritize your most critical features!
Beta Was this translation helpful? Give feedback.
All reactions