Package and Project .NET Framework mismatches

Jan 8, 2011 at 5:07 AM
Just had an unpleasant experience installing package that I thought was clr 3.5 but in fact is clr 4.0, in a solution with a single v3.5 project:
PM> get-package fluentpath -listavailable | install-package
You are downloading FluentPath from Bertrand Le Roy, the license agreement to which is available at http://fluentpath.codeplex.com/license.
Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies
constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device. Successfully installed 'FluentPath 1.0.0'. Install-Package : Unable to find assembly references that are compatible with the target framework '.NETFramework,Version=v3.5'. At line:1 char:56 + get-package fluentpath -listavailable | install-package <<<< + CategoryInfo : NotSpecified: (:) [Install-Package], InvalidOperationException + FullyQualifiedErrorId : NuGet.Cmdlets.InstallPackageCmdlet PM> get-package Id Version Description -- ------- ----------- FluentPath 1.0.0 FluentPath is a fluent wrapper around System.IO.
 
I know it's possible to end up in an indeterminate state (like above) when things are really buggered up in terms of dependencies, but surely we can prevent this kind of problem?
EnvDTE.Project instances have the framework version available in properties: TargetFrameworkMoniker. Are we tracking CLR requirements for packages?
-Oisin
Coordinator
Jan 8, 2011 at 5:23 AM

It’s something we should look at. But for now, we should encourage package authors to mention these types of things in their description. If he had stated that this is for .NET 4 and above, you (and others) probably would’ve avoided this unpleasantness.

Phil

From: oisin [email removed]
Sent: Friday, January 07, 2011 9:07 PM
To: Phil Haack
Subject: Package and Project .NET Framework mismatches [nuget:240930]

From: oisin

Just had an unpleasant experience installing package that I thought was clr 3.5 but in fact is clr 4.0, in a solution with a single v3.5 project:
PM> get-package fluentpath -listavailable | install-package
You are downloading FluentPath from Bertrand Le Roy, the license agreement to which is available at http://fluentpath.codeplex.com/license.
Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies
constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.
Successfully installed 'FluentPath 1.0.0'.
Install-Package : Unable to find assembly references that are compatible with the target framework '.NETFramework,Version=v3.5'.
At line:1 char:56
+ get-package fluentpath -listavailable | install-package <<<< 
    + CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGet.Cmdlets.InstallPackageCmdlet
 
PM> get-package
 
Id                             Version              Description                                                                                                  
--                             -------              -----------                                                                                                  
FluentPath                     1.0.0                FluentPath is a fluent wrapper around System.IO.      
 
I know it's possible to end up in an indeterminate state (like above) when things are really buggered up in terms of dependencies, but surely we can prevent this kind of problem?
EnvDTE.Project instances have the framework version available in properties: TargetFrameworkMoniker. Are we tracking CLR requirements for packages?
-Oisin
Jan 8, 2011 at 5:26 AM
Edited Jan 8, 2011 at 5:45 AM

I've updated the description of my package.

Jan 8, 2011 at 5:30 AM

Note that you're not really in an 'indeterminate' state, even though it may appear that way.  What happened is that you got the package at solution level, and we were not able to apply it to a specific project.  At this point, you can uninstall it, or you can install it into other projects.  If you find that you cannot do that, then you may indeed be in a hosed state and we need to fix that.

Jan 8, 2011 at 5:33 AM
Edited Jan 8, 2011 at 5:40 AM

Duly noted that I'm not really in an indeterminate state, but it sure looks that way from an end user experience point of view. Is it really that hard to incorporate the minumum CLR version into the package spec? It certainly isn't hard to check on the NuGet side. I would have expected this as a bare minimum; it is the very foundation of a package.

Update: Even after a restart of Visual Studio, NuGet still thinks I have the package installed. This is a really terrible experience. :(

Jan 8, 2011 at 5:42 AM

But note that we're effectively figuring out the CLR version automatically at install time based on what's in bin.  That's why we're able to give a (somewhat) helpful message.  If we didn't do that, the behavior would be that the package would install 'successfully', but would not actually reference any assemblies because none could be found.

That being said, we could be slightly smarter in the sense that we could detect the situation before installing at solution level, so that you're not left in that state.

Jan 8, 2011 at 5:49 AM

Yep, detecting earlier would be much better. Seems like low-hanging fruit, as they say.

Developer
Jan 8, 2011 at 6:23 AM
Edited Jan 8, 2011 at 6:27 AM

Wouldn't describe it as low hanging fruit but it could be done. 

Jan 8, 2011 at 6:28 AM

Filed for tracking: http://nuget.codeplex.com/workitem/547