Section Controls, NuGet Packages, and Existing Assembly References of .NET Core 3 release notes on Support for Windows Desktop Applications states the following:
Desktop applications often have many dependencies, maybe from a
control vendor, from NuGet or binaries that don’t have source any
more. It’s not like all of that can be updated to .NET Core 3 quickly
or maybe not even at all.
As stated above, we intend to support dependencies as-is. If you are
at the Build conference, you will see Scott Hunter demo a .NET Core 3
desktop application that uses an existing 3rd-party control. We will
continue testing scenarios like that to validate .NET Core 3
compatibility.
I created a WPF application targeting .NET Core 3 in VS 2019 using dotnet new wpf command, and it works fine.
However, when I add a 3rd party WPF control from NuGet (control was built targeting .NET Framework 4.6.1) I get the following error message:
Warning NU1701 Package 'Syncfusion.Shared.WPF 16.4.0.52' was restored
using '.NETFramework,Version=v4.6.1' instead of the project target
framework '.NETCoreApp,Version=v3.0'. This package may not be fully
compatible with your project.
The application still builds successfully but when I attempt to run the application public MainWindow() throws :
System.Windows.Markup.XamlParseException: ''The invocation of the
constructor on type 'Syncfusion.Windows.Tools.Controls.GroupBar' that
matches the specified binding constraints threw an exception.' Line
number '16' and line position '10'.'
Was anyone able to add a reference to a 3rd party WPF control to a WPF application targeting .NET Core 3 and if so what is the trick?
Related
I am trying to build MSIX setup for my WinForms application built on .net6. I want to give auto-update feature when the user clicks the "Update" button. I think originally developer didn't have control over updating MSIX and there was only way it was updated automatically when the application is restarted.
But there is a recent article on taking full control over MSIX updates I tried to follow it but I am facing the exception 'System.InvalidOperationException' while running the below line of code.
Package package = Package.Current;
I am using visual studio 2022 & WinForms application running on .net 6. I have kept other configurations as described in the above article but it is not working as expected. (I have tried in .net core 3.1 and it is working with it)
Package.Current only works in a packaged context, so you need to make sure to actually debug/launch the packaging project. An InvalidOperationException indicates that you are running your project unpackaged.
Make sure to select "Set as Startup Project" on the packaging project, likely named "MyApp (Packaging)" in the Solution Explorer. Then you can launch/debug your project as you normally do.
When working with .Net Framework 4.7 & WPF, we use fody weaver to package up all the project dlls etc... into one dll, so we could then use Wix installer.
This is extremely convenient, and fody worked a treat.
With a .Net Core 3.1 Wpf app I cant get fody to work and they have put it in maintenance mode because of .net core 3's new single- file exe's.
I can create a single file exe but still need to install my app as its code signed and I want the user experience to be familiar with the standard ms installer ui.
At the moment im sure I can create a Wix project and include all the dll's, but there are hundreds of them with .net core & this is an immense amount of work.
Can anyone shed any light on how to install a .net core 3 WPF app using Wix?
I am building a windows presentation form application. The issue I have is that my co-workers have different versions of .net installed on the desktops. If I build it on my machine which has .net version which is 4.6. When another person has a lower version of .net it fails. I can build the application multiple time with different version of .net but I would like to avoid that. So is there a way in Visual Studio to build a WPF that will work on multiple platforms and versions of .net?
You can change your target framework in the project properties (right click the project and select Properties):
Because higher .NET versions are backwards compatible with earlier versions, you can target a lower version that what is on your machine, though it means that you lose out on the newer apis.
So, for example, if you and your colleagues decide that .NET 4.0 is a good target, then having .NET 4.5 or .NET 4.0 will work for building and running the application.
For more information on Framework Targets, see:
What does it really mean to target a framework, and how do I maximize compatibility?
What is the effect of setting a “Target framework” in Visual Studio
I have created a VS2013 solution that contains multiple projects. One of those projects is a portable class library targeting .NET 4.5+, Silverlight 5, Windows Store 8+ and Windows Phone 8 and this project contains a reference to an OData service in an accompanying web application.
The portable class library references Microsoft.Data.Services.Client.Portable (among others), added via nuget (WCF Data Services Client).
I have then added the portable class library to a WPF (.NET 4.5) application, a Windows Store application and a Windows Phone application and written some very basic test code to access the service. This works fine in Windows Store and Windows Phone.
The WPF application however will not compile. The errors are...
The type 'System.Data.Services.Client.DataServiceContext' is defined
in an assembly that is not referenced. You must add a reference to
assembly 'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The type 'System.Data.Services.Client.DataServiceQuery`1' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The thing is, I also added the WCF Data Services Client to the WPF application via nuget, but it does not add a reference to the portable library (packages\Microsoft.Data.Services.Client.5.6.0\lib\portable-net45+sl5+wp8+win8\Microsoft.Data.Services.Client.Portable.dll), instead adding a reference to the full framework 4.0 version (packages\Microsoft.Data.Services.Client.5.6.0\lib\net40\Microsoft.Data.Services.Client.dll) - which in turn is causing the error I am seeing.
Is there something I am doing wrong here or is this an error in the installation package? Note that if I delete the offending reference and add the alternative reference manually then all is well so though I have a work-around I would still like to know if I am the cause of the error.
Looking at the NuGet source code this behaviour seems to be by design.
The WCF Data Services Client contains assemblies for the following frameworks:
.NET Framework, v4.0
.NET Portable, net45, sl5, wp8, win8
Silverlight, v4.0
Installing this NuGet package into a project that targets .NET 4.5 will result in the .NET 4.0 assembly from the NuGet package being referenced. NuGet considers the more specific .NET framework to be a better match for your WPF project which targets .NET 4.5.
There is a comment in the NuGet source code about this when it looks for the best matching assembly in the NuGet package.
// Let's say a package has two framework folders: 'net40' and 'portable-net45+wp8'.
// The package is installed into a net45 project. We want to pick the 'net40' folder, even though
// the 'net45' in portable folder has a matching version with the project's framework.
I have multiple DLLs of a WinForms control targeted for different versions of .NET Framework and need to add them all in a Visual Studio Toolbox while showing only the one which is most suitable for currently selected version of .NET.
The control have different features when compiled against different versions of .NET, this is why it would be best to show the most "native" version only. For example, the control have some features removed in .NET 4.0 Client Profile or makes use of .NET 3.0 features when available (not avaiable in .NET 2.0).
The problem is that the control have same name and is signed with same Strong Name Key (SNK).
I can modify source code, but what to do to enable all versions of the component to reside in VS Toolbox?