41

In Noda Time 1.3.1, our .csproj file referred to Profile 328 and our .nuspec file put the results in

lib\portable-net4+sl5+netcore45+wpa81+wp8+MonoAndroid1+MonoTouch1+XamariniOS1

For Noda Time 2.0, I've moved everything over to DNX/DNU (soon to be dotnet cli, of course). However, we now want to build a regularly-updated package containing the latest time zone information from IANA. We'll build one version of that with a dependency on Noda Time 1.3.1, and another version with a dependency on Noda Time 2.0.0.

I would like to do all of this still within DNX/DNU, but it's unclear to me whether there's any way of telling DNX/DNU about this target framework. Note that I want to make this available to all current users of 1.3.1, and it also depends on 1.3.1, so I believe the set of target frameworks basically needs to be identical.

I've tried frameworks of:

  • portable-net40+sl5+win8+wpa81+wp8 (which I expected to have the best chance of working based on the Nuget documentation)
  • portable-net4+sl5+netcore45+wpa81+wp8+MonoAndroid1+MonoTouch1+XamariniOS1
  • Profile328

In every case, dnu restore shows an error of this form:

"portable-net40+sl5+win8+wpa81+wp8" is an unsupported framework.

I have a horrible suspicion that this basically isn't a supported use case, and that I'll need to stick to a regular csproj file for this particular part, but I thought it worth asking to see if I'm missing something.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194

1 Answers1

35

There's been some issues with Xamarin frameworks in the past, but try doing something like this;

https://github.com/AutoMapper/AutoMapper/blob/93f276fea36dedb2efd861096f881667af880d58/src/AutoMapper/project.json

See if this works:

{
  "frameworks": {
    ".NETPortable,Version=v4.0,Profile=Profile328": {
      "frameworkAssemblies": {
        ...
      }
    }
  }
}
Matt
  • 74,352
  • 26
  • 153
  • 180
davidfowl
  • 37,120
  • 7
  • 93
  • 103
  • 2
    That's definitely fixed `dnu restore`. Building is now failing with "The dependency fx/System.Runtime could not be resolved" and ditto for mscorlib (so obviously everything breaks at that point) but I can look into that separately. Thanks! – Jon Skeet Mar 22 '16 at 08:22
  • 4
    Aha - tweaking it from Version=4.5 to Version=4.0 seems to fix it. Are you happy for me to edit your answer accordingly? – Jon Skeet Mar 22 '16 at 08:24
  • 2
    (I'm not too worried about the Xamarin side, to be honest. If that ends up working, that's great - if not, it's not like I'm breaking them, they just won't get the new package.) – Jon Skeet Mar 22 '16 at 08:25