I'm looking for a device that can be used to create a C++17 desktop program with the WinRT/C++ library (XAML Island), from typing code to compiling it in Visual Studio 2022. I'm also using the WinUI 2.8 prerelease (Microsoft.UI.Xaml.Controls), which might use up more resources. Usually, in one solution there are 2 projects, namely Win32 (App) and UWP (UI) projects. For a UWP project, usually there are about 10 WinRT/C++ Pages in it.
Therefore, what is the minimum hardware requirement that fits such a case, so that the programming process can run smoothly or even quickly? And also what about the target hardware requirements?
Note: sometimes Visual Studio 2022 and Microsoft Edge (2-3 tabs, AdBlocker extension) run at the same time.
Related
I have been trying to use Blend for Visual Studio with Uno Platform but it only works well with UWP. There is a trick or support for the other platforms?
Blend itself only allows you to launch the UWP head of an Uno Platform app. At the moment Blend doesn't load Android, iOS, or WebAssembly projects.
Most of the time this should be enough. It's encouraged to use a 'Windows first dev loop' with Uno. I.e, iterate and test your app on UWP, taking advantage of faster compile times and advanced support for tools like XAML Hot Reload, and switch to iOS/Android/WASM for testing platform-specific features (and bugs).
You can edit XAML from Blend, test it on UWP, then switch to Visual Studio proper and run the same XAML on other platforms. Uno aims to match the UWP visuals pixel-for-pixel on other platforms by default. (Of course they can also be customised per platform, if desired.)
I am developing a VB.Net based Windows8.1(10) Store application.
After published, I've found out that my App crashes on Windows8.1 while it works fine on Windows10.
So, I want to debug my App on the Windows8.1. However, I cannot find how to do so.
When I [Run] the App to [Simulator], it runs on clone of my computer, but I want to run it on other version of Windows.
Visual Studio 2015 is now installed on Windows10.
Thanks.
Disclaimer: I work on Visual Studio, though not on the Universal/Modern App area.
This is not a supported scenario and there is no feature present in Windows that emulates or simulates previous versions of the "Modern" runtime environment.
The Simulator feature is actually a local-loopback Remote Desktop (Terminal Services) session and existed to make it easier to debug Modern applications given that they could only run in a fullscreen mode, however as this is no-longer the case (as apps are now floating windows) the utility of the Simulator is limited, and as you're discovering is not relevant to your problem.
The only solution I can recommend is to use Hyper-V (or another desktop virtualisation product, such as VirtualBox or VMWare if you don't want a hypervisor installed) to install a dedicated Windows 8.1 environment followed by installing the Visual Studio Remote Debugger.
Given the rapid adoption of Windows 10 (as it is provided as a recommended update to the majority of Windows 8.1 users) I don't personally recommend explicitly targeting the Windows 8.x "Modern" app environment unless you know you will have users or if it's a contract requirement.
Windows 8.1 is the update to Windows 8.0. Right now, using Visual Studio 2012 I can target my Store App to Windows 8.0. But with Visual Studio 2013 I can target Windows 8.1. There are new APIs available, some changes to the framework, and new XAML controls I can use - the date picker control alone will remove third party libraries from my solution.
Knowing the benefits of Windows 8.1's APIs and controls over Windows 8.0, is it worth targeting my app to Windows 8.1 as quickly as it is available (basically, now), or should I wait?
Please, this is an honest question that many developers are asking right now. The changes are significant, but the answer to this question is not apparent. Though I can have a Windows 8.0 and a Windows 8.1 app in the store, my goal is have a great app with a single code base.
Is targeting Windows 8.1 worth it (at all)?
Is "early" a valuable-enough quality of an app?
Is there some "trigger metric" for adoption?
What's the rule of thumb on other platforms?
How should serious developers answer this?
I don't have "the" answer, but I could share my approach when Windows 8.1 is not a requirement :
Maintaining two versions of an app (W8 & W8.1) costs. Measure that cost.
If your application is not already published and is not likely to reach the store before the end of the year go for W8.1.
If you already have a version of application live on Store, update it as quickly as possible to integrate an analytics solution and gather OSVersion (http://bit.ly/15X2B3K). Decide when you have enough users using W8.1 to justify the migration cost. Plan the drop of W8 support.
Hope this helps
Background
We're using System Center 2012 to deploy a Windows 8 Metro-style application to Samsung slates in the field running Windows 8 Enterprise x64. The slates are joined to the domain and have a persistent DirectAccess connection back to it, allowing System Center to push applications and updates to the devices.
We have to deploy our application to potentially hundreds of devices in the field, which is why we went the System Center route. The code signing cert is installed on every device using Group Policy. To deploy the application, you simply provide the package output and specify the collection of devices to install it on. The app just shows up on the device in a few minutes.
The problem we're having is that when System Center deploys our application, the SQLite dependency is lost and none of our data access works.
About our project
Our application is a WinJS application that uses SQLite as a backend. However, all our data access code is in a C# WinMD project which the WinJS project references. We're using the sqlite-net library to talk to SQLite - we included the source for that in our C# project.
In Visual Studio, we installed the SQLite for Windows Runtime extension as described in Tim Heuer's article. The Metro application references this.
Testing using other deployment methods
SQLite data access from the application works fine when you debug or run it locally - in both Debug/Release and x86/x64.
The app packaging process provides a PowerShell script that you can use to install the application and a developer license if necessary. When installing our app using the PowerShell script, SQLite data access also works fine. Verified this by packaging and installing both Debug/Release and x86/x64 versions of the app.
Troubleshooting
When the application first tries to use SQLite, we see an exception about it not being able to find the sqlite3.dll.
We've tried/verified the following:
Confirm that we're deploying a Release/x64 build
Examine the appx in WinRAR and verify that it contains the sqlite3.dll
Reference the "SQLite for Windows Runtime" extension from the C# project instead of the WinJS project
Also reference the C++ runtime, this caused System Center to fail when deploying the app. Don't know why yet, but looking into it.
UPDATE
The issue is that System Center is having trouble deploying the Visual C++ Runtime Library dependency that the SQLite library needs. So unfortunately this isn't a programming question anymore. We're getting some help on this and I'll post the fix.
I wanted to post the details of a temporary fix that we're going with. We've also gotten closer to the root of the problem, so I wanted to provide those details as well.
Recap of Issue
When referencing the Visual C++ Runtime Package from our Metro project, System Center is unable to deploy the application to the devices because there is a problem deploying the proper version of the dependency for the appropriate architecture and build flavor.
Our development machines running Visual Studio 2012 (and packaging the project for deployment) are using a newer version of the Visual C++ Runtime (50727) than what is available in a fresh installation of Windows 8 (50712).
Worked with the System Center team and confirmed that this was a bug in the version we were using and has already been addressed in future builds. We're going to work on upgrading the environment but that will take a couple of weeks.
Workaround
I confirmed and tested the following workaround:
Remove the reference to the Microsoft Visual C++ Runtime Package from the Metro project
Install the x64 version of the Visual C++ Redistributable for Visual Studio 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=3
Deploy the application
Works like a charm because the correct version of the dependency is there already. Obviously not a long term solution if we choose to also target x86 and ARM, but will get us over this hump.
Is there some kind of SDK out for WinRT.? Can we develop applications for it now?
Is VS2010 usable for developing or will some other IDE be shipped? Also, is C++ necessary to develop performance-oriented apps in WinRT, or will the C# applications give equivalent performance? Can development be done on Win7?
I am curious about this because I missed out when WPF was released and I don't want to miss out on this.
Take a look at the Windows Dev Center where you can download a copy of Windows 8, complete with all the new tools for developing for it.
Visual Studio 11 Developer Preview is also available on Subscriber Downloads if you do have a subscription, and it includes the WinRT SDK and runs on Windows 7 and other operating systems. So you can build it and debug it, but you still have to run your code on a Windows 8 machine.
Performance-wise, WinRT doesn't change the guidance for whether to use native code. The APIs will behave near identically regardless of what language you choose, so make the decision between C++ and C# just as you would today.