I've been excited about Uno but at the end of the day, I'm a diehard Windows 10 M supporter and would like to publish an app for the platform before it's completely buried and impossible to target.
To get fun new controls in Windows 10 15063, I need WinUI 2.3, but I'd like to use Uno.UI alongside it.
If I use the guide for WinUI installation, my Windows build works just fine. The issue TwoPaneView with Uno Platform seemed promising but the only answer falsely asserts that not using a namespace with TwoPaneView will build on Windows 10 -- maybe with 1903 minimum but not with 15063 minimum in release mode.
How do I properly juggle the namespaces? I'm okay with splitting out a few per-project files if I have to but I would rather not.
Ahem... In point of fact, I didn't "falsely assert" anything!
WinUI and Uno.UI will build just find in a UWP head project targetting the Windows 10 Creators Update (Build 15063) however you can't use the ".NET Native tool chain" with such an old SDK.
You can check this by changing the min targetting version of my "TwoPainView" project (from here) and compiling (in debug or release without "Compile with .NET Native tool chain") which will result in no errors but a couple of (entirely sensible) warnings along the lines of:
Type 'Windows.UI.Xaml.Controls.TwoPaneView' is defined under contract 'Windows.Foundation.UniversalApiContract' version '8.0.0.0', but the contract version for the targeted min version is '4.0.0.0'!
And this is correct. It is unlikely you will be able to use the TwoPaneView on such an old SDK.
Related
I'm trying to use Windows UI library in my WPF app, and whenever I install Microsoft.UI.Xaml I get the following error.
Microsoft.UI.Xaml nuget package requires TargetPlatformMinVersion >= 10.0.15063.0 (current project is -1)
How to resolve this issue?
My windows SDK version is the latest version downloaded from here.
My OS version is 20H2 and the build number is 19042.685
I tried changing the targeted framework from .NET Core 3, 3.1, and .NET 5.
[If you think the title of this question is not appropriate, feel free to suggest an edit.]
I had the same problem transferring my project from .NET Framework 4.8 to .NET 6 (needed to have "using declarations").
Here's how I fixed mine:
Go to the affected project's settings.
Go to General and Target OS version.
Choose 1.0.19041.0 (or at the very least it must be 10.0.18362.0)
In the Supported OS version, choose any version except 7.0 or 8.0.
Build the project.
I think (I'm not sure) the issue here is UI.Xaml doesn't support Win 7 or Win 8.
I'm working on a UWP application that has both a UWP app and a small Win32 program, linked from a UWP packaging project. My solution looks something like this:
OneLocker (UWP)
OneLocker.AutoTyper (Win32, WinForms in particular)
OneLocker.Package (with references to the two above)
This all works fine, and if I try to create an app package just for the UWP application, I see all the various ARM/ARM64/x86/x64 options (enter image screen here), as I've followed the guide here to add the new ARM64 configuration.
The problem is that when I try to build the whole Package, including both the UWP app and the Win32 program, I only see the x86/x64 options (enter image screen here). Here is the complete .csproj file for the Win32 program in the package.
Now, I'm not 100% sure here, but from what I understand it should be possible to also build a UWP package project for ARM64 now, so that it'll run on devices with Windows on ARM without the need for the x86 to ARM emulation, right?
If so, is there something specific I need to add to my projects, or something to configure, in order to enable the ARM64 build configuration for the packaging project as well? Or, is this even supported already at the moment?
The only blog post I found about this (this one) only mentiones C++ UWP/Win32 applications, and not UWP packaging projects.
Thanks!
EDIT: here's some clarification on what I'm trying to do. The main point for me is: I want to be able to build the app package (UWP + Win32) for ARM64 as well, so that users running Windows on ARM can use that instead of either the x86 package (which would be slower, as it'd be emulated), or the standalone UWP app in ARM64 (which would run fine, but lack the additional features of the package).
As I've mentioned earlier, this is what I see from the build window for the packaging project. I'm aware that WinForms doesn't support ARM64, and in fact I'd be perfectly fine having just the UWP app in the package built for ARM64, and the Win32 part in Any CPU. The thing is that if I pick the Neutral/ARM64 combo from the first line (see the linked image), I then can't also pick the x86/x64 targets, as VS tells me I can't mix specific and neutral architectures in the same package.
To recap, here's what I'd want, in theory:
x86 package (x86 UWP and WinForms) ✔
x64 package (x64 UWP and WinForms) ✔
ARM64 package (ARM64 UWP and Any CPU WinForms) ❌
ARM standalone UWP app ✔
Is there any way to achieve this?
The Windows Packaging Project will produce ARM64 packages if the referenced projects support this architecture. Actually WinForms, or any other .NET Framework, do not support ARM64.
You can produce a bundle supporting different architectures that will optimize your UWP components and use the AnyCPU version for the WinForms.
Can you describe your application requirements and which architectures would you like to support in your packages?
Thanks,
Rido
I am doing maintenance work on a VS2010 C# project built against .net v3.5.
I recently changed the project Target Framework properties to the latest version listed (v4) - due to an expectation of using a version of .net that is actually included in Win10 by default - and rebuilt without any apparent issues.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5.
Using MS VS2010 v10.0.40219.1 SP1Rel.
Unfortunately upgrading the build tools isn't an option (building the program with VS2015 works just fine).
I have gone googling but don't seem to have found any similar reports.
Based on some of the comments already posted, I seem to have not made myself entirely clear - hopefully the following will help.
1) the intention/requirement is to be able to install this app on a clean install of Win10 without needing any further downloads. (installing .net 3.5 is easy to do, just not what is wanted)
2) the ultimate build environment for this is automated, visualized and not in my control and therefore upgrading the tool chain is a major pain that I'd like to avoid if possible.
3) AFAIK there are no third party libraries involved. All of the listed references (dll's) are v4.0.30319.
4) this is a XAML-based development, one part of three projects in the solution - the other entries are the installer and a C# custom installation library. As far as I can tell everything is set for .net v4.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5
So there is some dependency in your project that targets that version of .NET. It could just be that you need to Build > Clean Solution and with a Build > Rebuild Solution the problem is solved.
Otherwise, assuming some library does require some .NET 3.x library, the installation request is entirely correct. Windows 10 does not have an option for installing .NET 2.0 and another for installing .NET 3.5. If you search for Turn Windows features on or off you will see this:
Any dependency on a .NET 2.x-3.x library will trigger the activation/installation of the first feature in the dialog.
As far as I can see, you have 2 options:
Move everything to a framework supported by Microsoft, most preferably .NET 4.7.2 given support and security.
Deal with the installation process and understand that Microsoft does not install these versions of .NET in purpose. You can, however, add these installers as a prerequisite and even bundle them with your installation, but that won't help much.
Thanks to all who have tried to help me!
The issue has been resolved.
There appear to have been two causes for this issue and my confusion:
it turns out that the blank install of Win10 that the testing was being performed on was not entirely clean - the pre-installed network drivers/utilities from intel also had a .Net v3.5 dependency...
one of the embedded resources in the project was effectively a uncompressed tar-ball containing a number of files; including an executable that had the dependency on .net v3.5 - this was a binary blob stored in svn so the content was had not been updated for several years (ie well before my involvement) ...
With both of these issues addressed it would appear that my problem is solved, so once again thank you for your feedback, suggestions and patience,
PeterT :->
since I'm trying to get gstreamer-sharp 0.99 to run with my application, I heard, that gtk-3 is needed for gstreamer. Has anybody tried to build gtk-sharp 3.0 for monodevelop? I'm running fedora and tried, but all I could do, is link the dll manually to my project and the application didn't start. Is gtk-sharp still beta?
Thanks for your help.
Currently is possible to use gtk-sharp3 in MonoDevelop (at least in Linux). In Linux Mint 17 Quiana is necessary to install gtk-sharp3 package (no need to build) and add (in extension manager, install from file button) to MonoDevelop MonoDevelop GTK#3 Project Template extension.
This requires a MonoDevelop version >= 5 (see extension addin.xml file) - based on Xamarin packages (again, in my system). Installation guide for debian based systems.
GUI must be edited in an external program, Glade (a glade package) - see Gtk#3 project template descriprion.
Maybe required step is use the latest Mono release (see this) and probably required step is install Gtk3 first (libgtk-3-dev package and his dependencies). I have installed Gtk2 and Gtk3 as well as gtk-sharp2 and gtk-sharp3 simultaneously.
After creating GTK#3.0 project using template is (for my) necessarily add reference to gio-sharp v3.0 and regenerate MainWindow.ui with the use glade!
I hope that's all!
since I'm trying to get gstreamer-sharp 0.99 to run with my application, I heard, that gtk-3 is needed for gstreamer.
gstreamer-sharp 0.99 doesn't depend on gtk-sharp 3, it depends on glib-sharp 3, which, as of today, is hosted in the same repo as gtk-sharp 3, but that will change soonish.
Has anybody tried to build gtk-sharp 3.0 for monodevelop?
MonoDevelop only works with gtk+ 2.x versions. If you install gtk-sharp 3, you will not break or override gtk-sharp 2.x, as they can be installed in parallel.
I'm running fedora and tried, but all I could do, is link the dll manually to my project and the application didn't start.
Tried...? And what...? What happened? I'm assuming you failed? How did you fail, what error did you get?
Is gtk-sharp still beta?
gtk# 3 yes, gtk# 2.x is very mature though.
The "change target framework" dialog in the portable class library properties has a link pointing to this page:
http://msdn.microsoft.com/en-us/hh487282.aspx
Said page indicates that there is a silverlight 5 'targeting pack' included in 'Silverlight 5 RC Tools Visual Studio 2010 SP1'.
My assumption is that the RC tools are replaced by the release Silverlight 5 tools - and I definitely don't have the option to choose silverlight 5 despite having these tools.
Thinking they may have left the targeting pack out of the release tools, I tried uninstalling them and installing the RC tools to see if the option to target silverlight 5 would show up - however that didn't seem to work either.
How can I target Silverlight 5 with my portable class library?
Also I should add, I know that silverlight 4 assemblies are compatible with silverlight 5, however referencing silverlight 4 libraries from within a silverlight 5 application has other side affects (such as code analysis / metrics not working) which I'm trying to resolve ("could not unify the platforms") So a fix to that would be equally appreciated :)
Portable Class Libraries supports Silverlight 5 out-of-the-box, choosing Silverlight 4 will enable you to run on Silverlight 5. The Visual Studio 11 Beta out next week adds full support for Silverlight 5 (if you install it on a box with Visual Studio 2010, it will also add Siverlight 5 support to it)
The Code Analysis issue is a known issue (the same problem occurs if you reference RIA Services and attempt to run Code Analysis), unfortunately, there's no known workaround. Sadly, we could not get the fix into time to make it into the Visual Studio 11 Beta. It will, however, be fixed by the time we ship.
David Kean (BCL Team)