I try to run my Avalonia app on .net framework. However, when I downgrade targetframework to netstandard2.0, AppBuilder becomes unavailable and I just couldn't figure out, how to fix that problem.
I couldn't find any template, that targets .net framework or netstandard. Documentation contains nothing regarding this issue. The only thing I could find is this Github issue. As I understood, AppBuilder is not supposed to be used in netstandard. Then, what is proper replacement for following code?
public static AppBuilder BuildAvaloniaApp()
=> AppBuilder.Configure<App>()
.UsePlatformDetect()
.LogToTrace()
.UseReactiveUI();
Edit:
As it was pointed out, netstandard can't be used as a target for Avalonia apps, but we can specify multiple targets. So I replaced
<TargetFramework>net7.0</TargetFramework>
with
<TargetFrameworks>net7.0;net48</TargetFrameworks>
And it worked on .NET core and .NET Framework
netstandard2.0 isn't an actual .NET framework version: it's a specification of the common API beteen .NET framework 4.6.1 and .NET core 2.0 (among others). As such netstandard2.0 only makes sense as the target framework for libraries, not applications.
If you want your app to target .NET framework then you need to use a .NET framework version as the target framework, for example net48 for .NET Framework 4.8.
Related
I'm trying to use .net framework 4.8 nuget package (which was written by our team) in my .net standard 2.0 class library.
But when I build the solution I see such kind of warning:
Warning NU1701
Package ... was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
At the same time here it is claimed that .net standard and .net framework 4.8 are compatible.
Why do I see this warning? What am I doing wrong?
Is there way to get rid of this warning?
They're compatible in the sense that you can reference netstandard projects from net48 projects, but not the other way round.
The only thing you can reference from a netstandard project is another netstandard project
Visual Studio provides a "Background Application (IoT)" template which i want to use to create a headless webservice. To persist some data i want to use Entity Framework with SQLite as DB-Engine .
After upgrading UWP to 5.2.2 and installing Sqlite and EFCore.Tools and adding a DbContext i wanted to migrate the first version. It fails:
PM> Add-Migration MyFirstMigration
Project 'BackgroundApplication4' is a Windows Runtime component. The Entity Framework Core Package Manager Console Tools don't support this type of project.
I thinks it's not a problem with EF itself, because it worked for me with a simple "Blank App". Now there are some questions coming up: Is a "Background Application" really a WinRT-Component and has a different (unsupported) handling by EF?
I thought UWP is an extension of WinRT so basically each UWP-App must be a WinRT-Component?
EF in a Windows Runtime component is a no-go; but that is not so bad since WinRT component can depend on class libraries. So move all your EF classes to a own class libary and consume that library from your background task in your Windows Runtime component.
By doing this you can also use the same class library also in the foreground app when needed.
P.s. Check the github page of EFCore and UWP. There are lot of issues especially in combination with .net native. so using EF.core in UWP will cause you lot of headache; but it is possible.
I want to use Mvvmcross to make application for several platforms.
I use Profile 104 for PCL library like Mvvmcross, but this profile target .NET 4.5.
I want to target .NET 4.0 to use my application on Windows XP.
To do that, I add the xml files
MonoAndroid, Version = v1.6 +. Xml
and
VSMonoTouch, Version = v1.0 +. Xml
in the profile 143 which allows me to target. NET framework 4.0.3.
However, I have a compilation error because it can not find the ICommand interface.
This interface is not in the same library between version 4.0 and 4.5, is it why it doesn't work ?
Or should I recompile all Mvvmcross libraries with profile 143?
thanks,
This is a Portable Class Library limitation.
See the table on: http://msdn.microsoft.com/en-us/library/gg597391.aspx
Model-View-View Model (MVVM)
Only 4.5
This means that if anyone wants to use MvvmCross on earlier .Net platforms then someone has to build and maintain a non-PCL version.
Since the maintainer of Mvx (me!) has decided to only maintain PCL versions of MvvmCross, then any non-PCL support will have to be created by the community.
For WPF this shouldn't be too large or difficult a job - but it might be...
Alternatively, somebody might be able to do something funky to get the ICommand working... I've retagged this question with portable-class-library to try to lure in some of the MS experts.
I'm probably not the first to ask but which one should we use now ? As I understand it, it started with a very small System.IdentityModel for WCF. Then came the Microsoft.IdentityModel classes which added a whole lot more. This is the situation as in http://social.technet.microsoft.com/wiki/contents/articles/1898.aspx#v3q10
But now in 4.5, I see that System.IdentityModel has almost all classes from Microsoft.IdentityModel (although there seems to have been some refactoring and the configuration in web.config is slightly different).
Now Microsoft pre-releases a JSON Web Token Handler as a nuget, which depends on Microsoft.IdentityModel AND System.IdentityModel. (JWTSecurityTokenHandler resides in Microsoft.IdentityModel.Tokens.JWT, derives from System.IdentityModel.Tokens.SecurityTokenHandler).
This is getting quite confusing. Does anybody know which one I should use ?
The WIF 1.0 release, which is what you get when you download 'Windows Identity Foundation' from Microsoft, targeted .NET 3.5 (and was compatible with .NET 4.0). Since it was an out-of-band release, all types had to live in non-core namespaces (Microsoft.IdentityModel, etc.) and non-core assemblies.
The current WIF 4.5 release (they jumped in the version numbering if I've understood correctly) has been integrated directly into the core .NET 4.5 Framework. The most extreme example, the IClaimsPrincipal interface has been replaced by a ClaimsPrincipal base class from which all the .NET IPrincipal implementations now derive - this is directly in mscorlib.dll. Hence the System.IdentityModel, etc., namespaces.
The pre-released JWT Handler (nuget) is, of course, an out-of-band release. I wouldn't be at all surprised if it makes it into the core .NET vNext (assuming the JWT standard is finalized by then), but until then the framework naming guidelines require that JWTSecurityTokenHandler etc. reside in Microsoft.IdentityModel.
I can understand your confusion; I'm helped by the fact that I can start from scratch on my project with only .NET 4.5 to worry about - for now. :)
The WIF classes, which were collected under the Microsoft.IdentityModel namespaces in WIF 3.5, are now distributed among the following namespaces: System.Security.Claims, System.ServiceModel.Security, and the System.IdentityModel namespaces in WIF 4.5. In addition some WIF 3.5 namespaces were consolidated or dropped entirely in WIF 4.5.
Reference: https://learn.microsoft.com/en-us/dotnet/framework/security/namespace-mapping-between-wif-3-5-and-wif-4-5
I have a trivial C# windows application with an app.config file. I want to use the SupportedRuntime element to stipulate which version of the .NET framework to use. In my case, I want to use the .NET Framework 3.5 SP1.
Here is the XML I am using to achieve this;
[startup]
[supportedRuntime version="3.5.30729.1"/]
[/startup]
I have Microsoft .NET Framework 3.5 SP1 installed on my PC, but when I run the app, a message box advises me that I need to upgrade to this version of the .NET framework.
I hope this makes sense. Any ideas what the problem is?
(Edit: obviously the above code uses angle brackets rather than square brackets, but I couldnt see how to do that)
The answer is simple.
The .NET framework runtime version does not change with .NET 3.5 or 3.5 SP1, as these releases add additional libraries (Linq for example) but do not change the core runtime.
Hence entering the runtime version "3.5.30729.1" will never work.