According to a reply by someone apparently from Microsoft in this answer it seems it's an SDK and he says I can use the 16299 Desktop Extensions version for targeting a 14393 machine.
On the other hand, in Visual Studio, it's added as a reference, which seems to indicate that it's a runtime executable that exists on the target computer and therefore I would need to target either 16299 or 14393, but not both.
I think it's more likely that it is an SDK, because if not - we wouldn't be able to target multiple versions of Windows 10 with one app (unless every version of the OS contains the older "runtimes" as well). But I haven't been able to find any source saying this explicitly.
So: Do I need to target the version on the target machine, or can I target the latest version?
It's an extension SDK to the Universal Windows Platform SDK. For your desktop extension SDK you want to pick the same version that you are using for your UWP SDK reference, e.g. if you are using Windows SDK 16299, use the desktop extension SDK 16299. Adding such a reference adds a reference to .winmd files, which contain the metadata for the API surface (those are not runtimes). There is only one UWP runtime on your machine (the one that came with the OS installation).
You can still use the 16299 SDK to build apps that target 14393. See this topic for versioning considerations, and the concepts of minversion, targetversion and version adaptive code:
https://learn.microsoft.com/en-us/windows/uwp/updates-and-versions/choose-a-uwp-version
Related
Is it possible to get a list of versions of vsdbg? Microsoft seems to only provide a shell script to f.g. install it on some Linux host (f.e. Raspberry Pi).
But I would like to know all versions that are available maybe together with release notes or a change log. Does this exist?
Background: GLIBCXX version requirements have been bumped up on the latest version and it doesn't run on my target platform anymore. So the toolchain for linux-arm used for vsdbg is not compatible anymore.
I would like to at least find the latest version that works on the target platform.
Does anybody know a way to get a list of versions for this component?
Having a frustrating issue with something on my windows 10 PC updating my DotNet SDK version from 6.0.102 to 6.0.103. This is a problem as one of the software projects I work on is the hard locked to certain SDK versions.
Does visual studio code automatically update this or is it something else? Either way it would be good to know a way to turn it off.
Visual Studio Code does not update .NET SDK version in your system, since it is a pure code editor with extension support and does not mess up with other components and applications in the computer.
However, these can update your .NET SDK version:
Updating Visual Studio: Unlike VSCode, Visual Studio manages other components in the computer and may update .NET SDK version as you update Visual Studio.
Microsoft Update: .NET Runtime and SDK installations may be updated automatically via Microsoft Update if you use Windows and this switch is On in your Windows Update Advanced Settings:
Fixing SDK Version
There is a way to fix which SDK version is used by the compiler by adding a global.json file on the project or solution directory with the correct SDK version:
{
"sdk": {
"version": "6.0.102"
}
}
If you add the file in the root directory, the file will be taken into consideration for all projects in that directory and also in sub-directories. With this method, you can still use older SDK versions if they exists in your system.
For more info: Select the .NET version to use
.NET SDK Versioning
.NET SDK uses a special versioning. According to that, there should be no difference between version 6.0.102 and 6.0.103 other than bugfixes. Therefore, it would be a nice idea to reconsider the SDK version coupling even in patch versions such as the example versions you provided.
For more info: Overview of how .NET is versioned
It sounds like there is a new way to call Windows API (instead of PInvoke): Calling Windows APIs in .NET5.
Is there a way to get all monitors definition (size++)? Having the main one (the number 1)? And get coordinates (top left and bottom right) of its WorkingArea (the available window space without the taskbar)?
I could be misreading the release, but I don't believe the approach has changed: you still use the same Windows Runtime (WinRT) APIs.
.NET5 applications can now access Windows APIs through a new set of Target Framework Monikers (TFMs), which have been extended to support platform specific APIs. This is the recommended mechanism for .NET going forward. For more information on this change, please refer to the .NET5 Preview 8 announcement.
This change means that applications targeting .NET5 no longer need to reference the Microsoft.Windows.SDK.Contracts NuGet package.
Developers can access this functionality by installing the latest preview for .NET5 (preview 8) and Visual Studio 16.8 (preview 2).
What has changed is the way you add references to these APIs to your project. Instead of including the Microsoft.Windows.SDK.Contracts NuGet package, you specify which operating systems/versions your project supports via Target Framework Monikers (TFMs). Adding a TFM for Windows automatically adds access to the appropriate WinRT APIs for the Windows version you specified.
There's a guide for this in the windows-uwp repo.
Modify a .NET project to use Windows Runtime APIs
There are several options for .NET projects:
Starting in .NET 5, you can add a Target Framework Moniker (TFM) to your project file to access WinRT APIs. This option is supported in projects that target Windows 10, version 1809 or later.
For earlier versions of .NET, you can install the Microsoft.Windows.SDK.Contracts NuGet package to add all necessary references to your project. This option is supported in projects that target Windows 10, version 1803 or later.
If your project multi-targets .NET 5 (or later) and earlier versions of .NET, you can configure the project file to use both options.
.NET 5 and later: Use the Target Framework Moniker option
This option is only supported in projects that use .NET 5 (or a later release) and target Windows 10, version 1809 or a later OS release. For more background info about this scenario, see this blog post.
With your project open in Visual Studio, right-click your project in Solution Explorer and choose Edit Project File. Your project file should look similar to this.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
Replace the value of the TargetFramework element with one of the following strings:
net5.0-windows10.0.17763.0: Use this value if your app targets Windows 10, version 1809.
net5.0-windows10.0.18362.0: Use this value if your app targets Windows 10, version 1903.
net5.0-windows10.0.19041.0: Use this value if your app targets Windows 10, version 2004.
For example, the following element is for a project that targets Windows 10, version 2004.
<TargetFramework>net5.0-windows10.0.19041.0</TargetFramework>
In later versions of .NET, you can replace the value with the relevant version, for example net6.0-windows10.0.19041.0.
Save your changes and close the project file.
I am using VS2017 15.9.6 with an XAF Winforms application and Desktop Bridge.
At one point I was able to create a .appxupload package to upload to the store however now I can only create a .msixupload bundle
The docs dont seem to explain the difference.
I am using Create App Packages, by right clicking the Packages project.
I don't think I changed anything in the manifest.
I tried Release (Any CPU) and Release (x64)
The solution is Framework 4.7.2 I also tried 4.5.1
This MCP Mag article explains that
MSIX is Microsoft's planned replacement for the MSI and AppX formats.
However this does not help me understand why one of my projects has flipped to using it when other projects have not.
Looks like it has to do with the minimum version of Universal Windows.
I had changed the target min version from Creators update 15063 to Windows 10 version 1809 Build 17763
VS2017 15.9 added support for MSIX when targeting Windows SDK 1809 (17763) as described in the release notes
You should not worry about .appxupload vs. .msixupload, since the store accept both and clients running 1809 won't see any difference between one or the other.
I'm adding a framework to an Xamarin project.
Based on the forums, there is a dependency on the iOS SDK / Xcode installed.
If I use 1 framework in iOS SDK 9.0 and another based in iOS SDK 10.1, what is the overall effect on my application?
Are there memory, performance, or any other change that could occur with static or dynamic libraries ?
Majorly there is no effect. But not for those Classes and functions which are deprecated in the 10.1 SDK. And if your application has linked with any non-public APIs of SDK i.e those APIs which are already upgraded to newer ones. Then your app will surely be rejected!
For example: Push notification, we have UNUserNotificationCenter in iOS 10 but we were using UIUserNotificationType and UIUserNotificationSettings to config notifications.