Ok, I've done some digging. Some of this is new to me so if I state something that wrong, feel free to say so ;)
I've been going through the NuGet code to try to understand out how you work out what the current project is in VS2010 to get the current FrameworkMoniker. I think you use the ProjectFactory to parse it through the Microsoft.Build.Evaluation.Project
When you load up a standard VS2008 project (including .NET CF) into this Project class then the TargetFrameworkMoniker isn't available. If you hack the file to set the ToolsVersion to 4.0 (for a standard .NET 3.5 project) then the moniker becomes available
and is correctly set. Unfortunately this trick doesn't work for a .NET CF project due to different MSBUILD targets (Microsoft.CompactFramework.CSharp.targets) that are embedded in the csProj (I'm still trying to work out why). Either way though, we can't hack
the project file just to pass into the NuGet API, so the assumption is that the Core API will never support anything other than VS2010 compatible files (SharpDevelop 4.1 seems to generates VS2010 project files). I appreciate that this may not have
been part of the original usecase, but then its unfortunate that .NET CF developers are stuck with VS2008 due to the decisions taken about the project formats VS2010 support, i.e. VS2008 is still an active product and will be for the foreseeable future.
If I'm correct in this, then this seems a bit of a limitation to the NuGet Core API, as it restricts custom extensions to make it work in other environments such as ours.
Since the original problem was how does NuGet identify which lib folder to get the package dll's from for .NET CF, I think the issue is possibly much wider in that NuGet doesn't support projects other than VS2010, and this is because it depends upon the
TargetFrameworkMoniker which is a VS2010 only attribute.
I feel we need to break this dependency and have a "fall back" whereby if we cannot find a moniker when we interrogate the project we look for other known properties, such as TargetFrameworkVersion, PlatformFormFamilyName (i.e. "PowerPC") etc, to generate
a moniker via NuGet, which will allow the Core API to work with non-VS2010 project files. Now .NET CF may cause a problem with this as its moniker may well be the same as the full version, but here a hack may be needed to create a custom moniker
(and matching custom \lib\) so that we can create these.
Guys, if I've missed something fundamental and have gone off on the wrong track then apologies so could you give me any pointers? I'm still happy to do the legwork :)