I'm porting a WPF app over to Windows Store app. I have some view models that I would like to put into a Portable Class Library. That code uses reactiveui framework. I created the library and I use nuget package manager to add reactiveui to the project. I get this:
Could not install package 'reactiveui-platforms 5.4.0'. You are trying to install this package into a project that targets 'portable-net45+wp80+win', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Is this really an unsupported configuration or am I doing it wrong?
ReactiveUI-Platforms is specifically only the platform-specific code. You need to just reference ReactiveUI-Core in your PCL and reference ReactiveUI-Platforms in your WPF and Windows Store apps, and everything should work.
Related
This is my first time programming for windows platforms and I'm trying to do a UI/UX fluent and modern app. So, I've heard that the best over-platform way to do it is with vector animation and therefor with bodymotion and lottie, because the good design, soft movement and I could get the animations from a professional designer.
The problem is that I tried to install multiple times the nuget package for lottie animations in my WPF project as I read in the official web: https://learn.microsoft.com/en-au/windows/communitytoolkit/animations/lottie-scenarios/getting_started_json and I only obtained errors related to the framework version:
Could not install package 'Microsoft.Toolkit.Uwp.UI.Lottie'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.8', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Initially I thought that the problem was the .NET framework so I migrate the project to .NET Core. And then I've tried again and got:
Package Microsoft.Toolkit.Uwp.UI.Lottie 7.0.0-preview4 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package Microsoft.Toolkit.Uwp.UI.Lottie 7.0.0-preview4 supports: uap10.0.16299 (UAP,Version=v10.0.16299)
Microsoft.UI.Xaml nuget package requires TargetPlatformMinVersion >= 10.0.15063.0 (current project is -1)
Investigating I understood that the packages were created for UWP and not for WPF. Consequently I investigate about XAML Islands, that brings UWP functions to WPF, but they only work with xaml map, I could't use to install nuget packages.
I don't find more information and don't know what I'm doing wrong.
I wonder:
What alternatives I have to add some soft and good looking animated buttons? Preferably with a complete documentation
There is a way to use lottie in WPF? Or it is unnecessarily complicate?
Which is the traditional way to animate and work with natively in WP?
Adding MVVM Light reference to a WPF projects adds a large number of system assemblies to the list of dependencies in the accompanying MSI Setup project. These assemblies (50+ in number) are then copied to the application folder when the app is installed. Why is it so? Why can't it reference it from GAC directly?
Note: Copy Local option is set to True for MVVMLight.dll. I obviously can't set it to False.
Reproducing it is extremely simple. I'm using VS2015 Community.
Create a new WPF Application project.
Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
Add an MSI Setup project to the solution (must have the extension installed).
Add Primary Project Output of WPF application to the setup project.
There you go. A long list of System.X.Y will be added to the list. If you build and install the setup project, you'll see all these DLLs in Program Files folder.
Why? And how to fix it?
Update
The problem does not appear if WPF application targets .NET Framework 4.0 and you add NuGet reference AFTER that. But if you target .NET 4.5, 4.5.1 or 4.6, the long list of dependencies appears again. Think MVVM Light (or NuGet) is having trouble finding the correct package sub-folder.
I don't know why it happens but I can offer a workaround. Just open the project's Detected Dependencies folder, select all of the System dlls, right-click and select Exclude.
Overly agressive dependency scanning is one of the many reasons I don't use Visual Studio Deployment Projects. Instead I use WiX / IsWiX. Both open source and the later written by myself.
For more information see:
http://www.github.com/iswix-llc/iswix-tutorials
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.
We have a Silverlight 5 project and we currently have a folder of shared library DLL's. We are in the process of changing to use NuGet for these libraries wherever possible.
One of the NuGet packages we want to use is MVVMLight, to replace the MVVM Light SL4 DLL's we are currently using, which were never upgraded when we moved from SL4 to SL5.
However, when we installed the NuGet package containing the SL5 DLL's it automatically changed our existing references to the Microsoft.Practices.ServiceLocation DLL file to one which came with the MVVM Light package, which has the same version number, but a different public key.
This has caused a conflict with some of our other code which is using the Prism library, which uses the Microsoft.Practices.ServiceLocation DLL, but, signed with the original public key.
Obviously we cannot use the same named DLL twice in the same folder, so, any suggestion on how to resolve this issue, whilst keeping both Prism and MVVM Light packages installed from NuGet.
Thanks very much,
Martyn.
I have exactly the same problem with Microsoft.Practices.ServiceLocation.dll. In my case, this could be resolve if the nuget package of MvvmLight was dependent of CommonServiceLocator as I suggested here : http://mvvmlight.codeplex.com/discussions/429311
So far, no news about that.
Edit : Laurent just push a version of MVVM Light using the CommonServiceLocator from Nuget.
The Portable.CommonServiceLocator NuGet package contains the existing signed CSL binaries as well as the PCL one that supports windows 8, .net 4.5 and others. Still waiting on Microsoft to include the PCL in their official package, but the binaries are the same in the one I mentioned.
You can also try using Portable.MvvmLightLibs, which is a PCL version. That one supports all of the frameworks (WP7.5+, .NET 4.5, Store, SL4+) and uses the official Microsoft-signed CSL libraries.
Is it possible to create a small library (similar to a Flash or Flex SWC component) that can be used in Silverlight apps?
Since I'm a Flash and Flex developer, I'll relate it. In Flex, if I have a SWC I can add it to my build path and then immediately use its included classes and functions in my project. Similarly, in Flash if I add a SWC to the Components folder then drag that SWC into my library, I can use the classes in my Flash project.
Does Silverlight have a similar concept? I just need a small code library that I can send to other developers, but it should be pre-compiled so the source is not readily available.
Thanks!
You should not have an issue pre-compiling the "Silverlight Class Library" project type in Visual Studio like you would traditional C# libraries, and release these to developers who can reference them in their Silverlight applications.