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
Related
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.
So i'm kind of new to programming but i started using Xamarin and i tried to add NHunspell package from NuGet on Xamarin Studio, it downloads it and the .dlls appear in Resources and NHunspell appear in Packets, but it doesn't appear in References and so when i try "using NHunspell" it doesn't work.
I have tried running the "install" script with Power Shell but apparently nothing changed.
How do I add NHunspell to my project?
Not every .NET library is compatible with Xamarin. They generally have to be either built against the appropriate Xamarin Framework, or build using a compatible PCL Profile.
scan.xamarin.com can tell you if a given DLL is compatible or not.
As I answered you already per Email the problem with NHunspell is that it is in fact an wrapper to Hunspell. Hunspell is written in c or C++ so it compiles to a native Dll. At this time the build produces two native DLLs for Windows 32 Bit and 64Bit. It would be necessary to produce native DLLs for ARM / Android or Linux or ... to use it on these platforms. I will do this for X86/X64 Linux in the future. But at the moment I'm snowed under so there is no timeframe. If you or someone else is willing to contribute, you're welcome.
BTW. NHunspell has an resolver for the correct native DLL. If your project has the native DLLs in the output directory, it resolves X86 or x64 in windows. You can do this in Xamarin studio by adding the native DLLs in your project and configure "copy to output directory". But this works only in Windows.
The latest packages (without NuGet) are here:
http://download.crawler-lib.net/NHunspell/
Greetings,
Recently i come cross a problem while developing a cross platform project.
In this project, I have to support android, ios, and wp7, what I did is to create 3 projects for these 3 platforms, and I have another project which can be shared among the 3 target platform.
So I created this project as a "Portable Library", and add reference to this project in the other projects. It worked, I can use Class defined in this shared project in the other 3 projects, but the problem is, in the portable library project, the "References" folder, "System", "System.Core", and "System.Xml" are red, when I unfold it, it says "assembly not available for .NETPortable 4.0 Profile1 Profile (in Mono 2.10.9)". I googled this piece of information, but none gave me the satisfying answer.
http://monotouch.2284126.n4.nabble.com/cross-platform-library-code-td4656600.html
So, how can fix it? What are these "System", "System.Xml", "System.Core" for? Are they files? Or within a file?
You can ignore the references being red for now. That just indicates that you don't have the PCL assemblies on your system (which you won't have unless you are on Windows), however Xamarin is working on generating PCL assemblies and hopes to have them "soon" (by May?).
In the meantime, this is "ok" because when you are targeting Mono for Android or MonoTouch on Mac OS X w/ MonoDevelop, what MonoDevelop does is link with the Mono for Android or MonoTouch frameworks instead, which is good enough for what you want do to.
Things to consider:
You won't be able to share the assembly with your WP7 app (because the assembly built by MonoDevelop won't be a true PCL assembly), but you'll be able to share the Portable Library project - i.e. just make sure to do a fresh build of the project for each platform. (you can share between MonoTouch and Mono for Android, but not with WP7)
Since the referenced assemblies are red, as you've noticed, it means that MonoDevelop won't be able to do proper code-completion. If you're a Windows guy, you could just develop the Portable Library in Visual Studio and then just share it with your iOS and Android projects. Once Mono has real PCL assemblies, this problem will go away.
There are some bugs in the current public releases of MonoDevelop and Xamarin Studio where it doesn't like certain profiles. Both of the following custom builds address this issue, depending on whether you want MonoDevelop or the sexier Xamarin Studio:
https://files.xamarin.com/~jeff/MonoDevelop-3.1.1.dmg
https://files.xamarin.com/~jeff/XamarinStudio-4.0.2442.dmg
Keep in mind that neither of these custom builds have been QA'd. the XamarinStudio link was just sent off to the QA team last night (hot off the press!) for what will become Xamarin Studio 4.0.2 (once any regressions / critical bugs that QA turn up in that build have been fixed).
I am writing an app that would work for both .NET and Mono. However components of it would only be available for one or the other. For example, a modular part of the app use WPF, which is not available in Mono (it would not even build!!!). Another part of the app uses PInvoke on a libpango, which is normally only available on Unix.
Is it possible to target individual platform with Visual Studio with different build parameter for each?
Currently The modular parts are not in their own project file, but I can easily move them to.
#define/#if blocks are one method for doing this. There is also a conditional attribute. You might also want to look into MSBuild targets.
You might also want to think about your class design and whether you can share have shared interfaces that enable more of a provider or "plug-in" model to support different platforms. Microsoft developed a Portable Libraries project type that might help with this.
Conditional compilation can make your code hard to understand and maintain. Personally, I am against it.
My suggestion is that you utilize good design patterns to isolate the platform specific bits,
http://codebetter.com/patricksmacchia/2011/11/07/real-world-feedback-on-a-net-to-mono-migration/
JavaDepend is a Windows Forms project, so its porting experience may help you.
WinForms executable (.exe) -> Platform adapter (.dll) -> Windows (.Windows.dll)
|
--> Other platforms (.Unix.dll)
In this way, you can always compile the whole solution together, package them together. At runtime, the adapter can load correct platform assembly/assemblies after platform detection.
For you case maybe you can use WPF for Windows, then you have to isolate WPF bits from business logic code, and then write UI again for other platforms (GTK# for Linux, MonoMac for OS X). This approach can be visualized as
WinForms/WPF executable (.exe) -> Platform independent biz-logic code (.dll)
^ ^
MonoMac executable ---| |
|
GTK\# executable ------|
In this way, you need to package differently for each platforms, but the core assembly/assemblies can be the same.
I have a program that requires both x64 and x86 dlls (it figures out which ones it needs at run time), but when trying to create a setup, it complains:
File AlphaVSS.WinXP.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
File AlphaVSS.Win2003.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
File AlphaVSS.Win2008.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
How can I make my setup target both platforms like my program does?
The MSI created by the setup project (in Visual Studio) can only target one platform at a time. Your option is to either make 2 MSI's, merge them together and make a custom setup boot strapper that choose between the two.
There are some 3rd party products,like Advanced Installer for example, that can do this for you.
I ran into this too and wrote a blog post about my solution:
deflate the file using deflate.exe, naming it with a different extension (e.g. .x64)
add it to your main project as a content file
add a custom action project to your solution
add the custom action to the setup projects "Install" custom actions
inflate the file inside the custom actions Install method using
System.IO.Compression.DeflateStream (see code above)
do a little dance around your desk, down the hall, and past as many coworkers as you care to annoy :)
The deflate.exe file can be downloaded from its repository on google code.
.Net has an "Any CPU" option. It's tempting to think of it as more of a "generic" option that's going to only use the lesser x86 features, but really it lets the JIT compiler on each machine pick the appropriate cpu type for that machine.
The only time you shouldn't use it is if you know you have dependencies or requirements that aren't good for one architecture or the other. For example: you know you need a lot of ram, you have a dependancy on a 32-bit native dll, or you want to pre-compile the app.
There's a danger here because you have a platform-specific dll dependancy. But you have dlls for both types and it sounds like you know how to pick the right one at runtime. So will the 'Any CPU' option work for you?
Open a deployment project.
In the Solution Explorer, select the deployment project.
In the Properties window, select the TargetPlatform property.
Choose either Itanium for an Intel Itanium 64-bit platform, or x64 for any other 64-bit platform (such as AMD64 and EM64T instruction sets).
At installation time, an error will be raised and installation will be halted if the target computer is not compatible with the specified platform.