I have a .NET 6.0 C# class library project that contains platform-independent code (let's call this BusinessLogic). In my same solution, I would like to create a project for a WinUI 3 app that references this class library (let's call this WindowsApp). I would also like to create a class library specific to the Windows platform (so I can access the Windows.Storage namespace from within that class library, for example... let's call this WindowsOS).
I get an error when attempting to set this up. I have tried two techniques:
First technique
Create a .NET 6.0 C# class library WindowsOS.
In WindowsOS project, add reference to BusinessLogic. No problem.
In WindowsOS project, install NuGet packages Microsoft.Windows.SDK.BuildTools and Microsoft.WindowsAppSDK. This gives me an error about numeric comparisons on the target platform, similar to the one described in this GitHub issue. Afterwards, the project becomes unloadable in Visual Studio.
Second technique
Create a Class Library (Universal Windows) project WindowsOS.
In WindowsOS project, add reference to BusinessLogic. This gives me an error immediately, simply refusing to allow the reference to be added.
I suspect there appears to be some compatibility issue going on. I reviewed the Microsoft docs on .NET Standard versions, as well as this helpful StackOverflow question about .NET Core vs .NET Standard class libraries, and from what I can tell UWP may not be capable of referencing .NET class libraries.
My end goal is to create a WinUI 3 desktop app that references these cross-platform class libraries. My common code is contained in these libraries, and I may make an Android app or other platform app in a separate project that also references these same cross-platform class libraries. How do I do this?
EDIT: Here is a screenshot of the error from technique #1:
I figured out the answer. In the Visual Studio project properties (screenshot below), there is a Target OS property. That property defaults to (None).
Given the names of the projects in the question, set the property accordingly:
Set the property value to Windows in the WindowsOS project. This will give access to Windows-platform specific namespaces (such as Windows.Storage). WindowsOS can still have a project reference to BusinessLogic (and any .NET 6.0 C# library) as before.
No change necessary to the BusinessLogic project properties.
The WindowsApp (WinUI 3) project also requires no changes, and can reference BOTH the WindowsOS project (which now has a Target OS of Windows) AND the BusinessLogic project (which still has a Target OS property of (None).
Something to keep in mind: the WindowsApp project and the WindowsOS project will now both have Target OS version and Supported OS version properties. If you set these to different values in each project, you will get compiler warnings about a potential conflict (a user could install the app with a lower version of Windows, but that app then references the library which may require a higher version of Windows than the user has, for example). This does not matter if you are only using APIs supported in BOTH versions of Windows, but to be safe make sure these are consistent between your projects.
Related
I have a Solution with .NET Framework Project A which builds a winforms application containing a class, MyPlayer which requires LibVLCSharp. In order for the application to build and run correctly I had to add the following Nuget packages:
LibVLCSharp
LibVLCSharp.WinForms
VideoLAN.LibVLC.Windows
Now I want to move class MyPlayer to a separate .NET Standard class library, Project B, to separate out function from UI and so that it can be used by multiple other projects targeted to different platforms. In order for B to compile I only had to add the LibVLCSharp Nuget package. Then I set B as a Reference for A.
Obviously, Project A is going to require the other two Nuget packages somehow, but I am unsure to which project it is most appropriate to add them. What makes the most sense in this situation? Or is there really only one way it would work?
that's a good question, and I don't know if it is properly documented on LibVLCSharp.
Short Answer:
LibVLC must always be referenced on the executable project (A)
WinForms isn't compatible with .net standard, so you can't reference it in B if you keep using netstandard.
LibVLCSharp can be moved "up" in project B if you need it there.
Long answer:
Let's see the packages in detail:
VideoLAN.LibVLC.Windows : This package contains the required dlls files that are required to make libvlc work on Windows. It also contains msbuild files that are used to copy the DLLs to the output directory of your project. You need those files in your application, so you need to reference this package in A. (They won't be transitively copied by a Project reference)
LibVLCSharp.WinForms : As stated here, this package only support .NET framework 4.0 and above, and .net core 3.0 and above. You will not be able to add this package in B, unless you replace your netstandard constraint and use multi-targetting instead. It will only work where WinForms is available.
LibVLCSharp can be referenced in project B without any issue. Since you're using .net standard, chances are you are also using the "SDK-style" csproj format and PackageReference. The dependency will then transitively be available in project A without adding it there.
If your point was having a player Form available in both .net framework and .net core, I'd recommend that you use multi targetting, by putting this in your B project:
<TargetFrameworks>net40;netcoreapp3.0</TargetFrameworks>
otherwise, if it's just for sharing non-ui code, you don't need the LibVLCSharp.WinForms dependency in B
I have several .NET dll projects for .NETv4.x. I changed version to 4.6.1 and rebuilded without problems. When I try to add referene to them from my UWP project I get error:
The project targets '.NETCore' while the file reference targets
'.NETFramework'. This is not a supported scenario.
I can't also reference .NET projects from 'Add reference...'->'Projects':
Unable to add a reference to project
But in project settings I can't see anything to change it's target to '.NETCore'.
Is it possible to reference .NET4.x project from UWP project or convert it to UWP project type?
UWP project can reference Universal Windows Class Library, Portable Library or Windows Runtime Component. Your classic .NET projects are none of those.
If you're planning to continue to develop and use those libraries in both classic .NET projects and UWP, I suggest you try Portable Library in which you can choose target platforms, but beware that this approach can be somewhat limiting because it takes lowest common denominator for available namespaces and classes.
Another approach would be to create two different projects targeting classic .NET and UWP, and share the code between them either adding files as links or using Shared Project. Then resolve all problems with conditional compilation, build them and use appropriate output .dll's for both cases.
In visual Studio 2015, in my solution, I have a Logic tier (class library) project that is added to the references of a WinForm project.
No, I am going to add a new Windows Universal project and added the same logic tier (class library) into it.
However, visual studio doesn't allow me to add the class library as a reference to the universal app, I get an error message.
The question is, What kind of class library that can be added to the references of Universal project as well as to the Winform projects withen the same solution?
Update: the message is "Enable to add a reference to project 'project-name' ."
You need to use the Class Library (Portable) choice for the class library project:
Once you add that, you'll have to pick your target platforms:
To be able to use it with WinForms, select the .NET framework matching the target framework you have selected in your WinForms project. If your WinForms targets .NET 4.5, make sure you select that; if you changed it to target .NET 4.6, you are able to select that as the target for your portable library, and so on. Otherwise, you'll get an error saying:
Unable to add a reference to project 'Your library name'. The current
project's target is not one of or compatible with the targets of
Portable Library project 'Your library name'.
Note that you can change these options later, by going into project properties, under Library tab.
I'm working with compiling the google apps API and I haven't seen it where I'm missing.
.net and windows 8/8.1 are both listed but nothing else. I'm running VS 2013 on a Windows 7 computer.
Because of this, when I go into references to the project, I'm missing all of the original microsoft references (even if I go to add them, there's nothing to select from).
For example, the error I'm getting is: Warning 2 The primary reference "System.IO", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETPortable,Version=v4.0,Profile=Profile5". To resolve this problem, either remove the reference "System.IO" or retarget your application to a framework version which contains "System.IO". Google.Apis.Admin.Directory.directory_v1
I'm not sure why that and all the other microsoft API's are not showing up when I go to select them (or not allowing me to compile). I assume it's because of the .netportable and the fact I'm not on a Windows 8.x computer.
Anyone know how to change the target? I don't see anyway of doing that.
What you have there is a Portable Class Library. It's lacking many namespaces and functions that are native to Windows only; basically, a PCL is reduced to the minimum feature set of .NET that can run on all target platforms.
For many missing namespaces there are replacement PCLs; if none is available, you can define interfaces in the PCL (and implement them in platform-specific code) that serve as a "bridge" between the PCL and e.g. the System.IO namespace on Win32.
Simple example: You define IFileIO with WriteFile(...) and ReadFile(...) in the PCL; then every project that uses the PCL (ex.: WindowsIO Windows) has a class that implements IFileIO and executes the System.IO calls within the respective functions.
Then you combine the Windows-specific implementation with the PCL interface; imagine you have a ImageConverter class that reads, modifies and writes images. Its constructor accepts an IFileIO, where you can pass a WindowsIO instance (or Win8IO, or AndroidIO, or ...). The ImageConverter only uses the interface and doesn't care about the implementation.
Hi there I am new to the windows phone development and I am trying to build a data driven application in which I have Created my BLL and EL and DAL ,which are all of windows phone class library type project.
I have also an extra project of type class library in my solution in which I have added the Reference to "MyGeneration.dOOdads.dll" file .
Now I want this project to be referenced in the windows phone app project.But when I try to add a reference ,The VS 2010 says...."Unable to add the selected project refernce.The project reference must be another silver light for windows phone project that is the same or the lower version ".
.
.
.
Kindly help me in this scenario. Thanks
That can't and won't work. The phone runtime only has access to a timy subset (well, sort-of) of the full .NET libraries, so any non-phone-7 library is extremely unlikely to operate at all. To stop this surprising people, only libraries built against that runtime are allowed to be referenced.
If possible, create a new project with the same c# files, targeting the phone 7 framework. Now reference this project. It is quite likely that some bits will fail to compile (demonstrating the fact that it also wouldn't have run), which can be rectified in a number if ways (#if blocks, alternative .cs files, etc).
You might also have some luck by making the existing project a "portable class library" - this, however, is the most restrictive subset of all the common frameworks, and is even less likely to still compile (without changes).
Using the Portable Class Library project, you can build portable assemblies that work without modification on the .NET Framework, Silverlight, Windows Phone 7, or Xbox 360 platforms.
(from MSDN)