-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nuget fails to install 'reactiveui' 2.3.1.0 on .NET Framework 4.0 (Client Profile) #16
Comments
This is by-design - ReactiveUI-Testing doesn't support Client profile because Rx-Testing doesn't. Instead, try installing ReactiveUI-Xaml instead (this will bring in Core too), it should work in Client profile - if it doesn't, reopen this bug and I'll take a look. |
@paulcbetts Installing ReactiveUI-Xaml also does not work on .NET 4.0 Client Profile (it has ReactiveUI-Platforms as a dependency which fails) -- How can we get ReactiveUI in our WPF project using .NET 4.0 Client Profile? |
@BrainSlugs83 ReactiveUI doesn't support client profile (and in fact, neither does Microsoft, because they killed it) |
.NET 4.0 Client Profile still exists and is definitely still supported by Microsoft (as is Visual Studio 2010). There is no "Client Profile" of the newer frameworks (thank the gods!) But if the end user has standard Windows 7 and gets all [non-optional] updates, they will only have the .NET Framework 4.0 Client Profile -- so it's all we can count on users to have already installed. Because of this, my project has a business requirement to target the .NET 4.0 Client Profile -- is there any version of ReactiveUI that will work with the Client Profile? (When our team eventually migrates to VS 2012/2013 I may push that we also migrate to .NET 4.5, but for now, that's not an option for us.) |
Are you sure about that? http://superuser.com/questions/298025/does-windows-7-have-net-4-installed-by-default seems to show that Win7 SP1 has .NET 4.0 Full Profile. Anyways, there is no version of ReactiveUI that targets client profile out of the box, but you might be able to hack it to do what you want if you build from source |
Yes, I'm sure. -- We set up VMs all the time to simulate barebones environments, and we install all non-optional / "recommended" updates (because it's all we can guarantee the clients have -- though, even that's a stretch sometimes). -- we do multiple rounds of updates [because having some updates unlocks other updates -- so you can't just get them all in one go -- you have to install all -- then recheck, then install all again -- lots of reboots in there, etc. -- until there's finally none left] and after each product we install [like Office, etc. -- as having some products installed unlocks other updates still -- usually product specific though] -- it's usually all all day affair to set one of these environments up. I suspect the person on super user must have also installed "Optional" updates, or perhaps they installed some other 3rd party application that installed it as a prerequisite (ClickOnce and WIX both make it pretty easy to package up the runtime and install it as a prerequisite). (Note that the answer is even a bit misleading regarding the question: .NET 4.0 Client profile isn't even installed by default -- you have to get it via Windows Update -- the other answer confirms what I've already said -- only after several rounds of updates on SP1 does the user get .NET 4.0 at all, and even then, it's only the Client profile -- following that I've encountered lots of machines where people didn't install automatic updates at all or if they had, they're still years out of date. -- Including home users and corporate clients -- It's a sad state of affairs... ) However, .NET 4.5.x looks like it's backwards compatible with 4.0, and is now a "recommended" update, so end users with fully updated machines should be able to run .NET 4.0 full profile code (again: because they have the .NET 4.5.x runtime -- which can run .NET 4.0 Full Profile binaries). Out of curiosity, is there a particular reason/technical limitation that prevents ReactiveUI from targeting the Client Profile? Or is it "just because"? -- If it's as simple as flipping a switch in the project settings to add that support, why wouldn't you want to? |
I've just tried to install 'reactiveui' 2.3.1.0 nuget package on .NET Framework 4.0 (Client Profile) and it failed with the following error message:
'reactiveui-core (≥ 2.3.1.0)' not installed. Attempting to retrieve dependency from source...
Done.
'Rx-Main (≥ 1.1.10425)' not installed. Attempting to retrieve dependency from source...
Done.
'reactiveui-xaml (≥ 2.3.1.0)' not installed. Attempting to retrieve dependency from source...
Done.
'Rx-Xaml (≥ 1.1.10425)' not installed. Attempting to retrieve dependency from source...
Done.
'reactiveui-testing (≥ 2.3.1.0)' not installed. Attempting to retrieve dependency from source...
Done.
'Rx-Testing (≥ 1.1.10425)' not installed. Attempting to retrieve dependency from source...
Done.
'Rx-Main 1.1.10425' already installed.
Successfully installed 'reactiveui-core 2.3.1.0'.
Successfully installed 'Rx-Xaml 1.1.10425'.
Successfully installed 'reactiveui-xaml 2.3.1.0'.
Successfully installed 'Rx-Testing 1.1.10425'.
Successfully installed 'reactiveui-testing 2.3.1.0'.
Successfully installed 'reactiveui 2.3.1.0'.
Successfully added 'Rx-Main 1.1.10425' to UserRegistration.Rx.
Install failed. Rolling back...
Unable to find framework assemblies that are compatible with the target framework '.NETFramework,Version=v4.0,Profile=Client'.
The text was updated successfully, but these errors were encountered: