Portable projects created in VS2013 when opened in VS2015 use wrong version of F#

[ovatsus]

This is a follow up from #4

Default F# project files created in VS2013 for full .Net and "Portable Library (Legacy)" have a format that makes it work with VS2015, even though many OSS projects have put an incompatible format because of Mono support. Here is the fsproj snippet:

    <PropertyGroup>
      <MinimumVisualStudioVersion Condition="'$(MinimumVisualStudioVersion)' == ''">11</MinimumVisualStudioVersion>
    </PropertyGroup>
    <Choose>
      <When Condition="'$(VisualStudioVersion)' == '11.0'">
        <PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.Portable.FSharp.Targets')">
          <FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.Portable.FSharp.Targets</FSharpTargetsPath>
        </PropertyGroup>
      </When>
      <Otherwise>
        <PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.Portable.FSharp.Targets')">
          <FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.Portable.FSharp.Targets</FSharpTargetsPath>
        </PropertyGroup>
      </Otherwise>
    </Choose>
    <Import Project="$(FSharpTargetsPath)" />

But "Portable Library" projects created in VS2013 (profile 7), will not work out of the box in VS2015. Here is the fsproj snippet:

  <PropertyGroup>
    <MinimumVisualStudioVersion Condition="'$(MinimumVisualStudioVersion)' == ''">12</MinimumVisualStudioVersion>
  </PropertyGroup>
  <Import Project="$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.Portable.FSharp.Targets" />

[latkin]

Well crud. FWIW, this is only wrong for the template targeting portable profile 7. Profiles 47, 259, 78 are all correct.

When reviewing the changes to add profile 78 and 259 (20d4479), we made sure to get it right, but noticed that it was wrong for profile 7. We just forgot to follow up and fix it.

At the very least we should fix the profile 7 template. That's very simple to do.
Full fix is to adjust project upgrade handling so that this is detected and handled properly.

[latkin]

I take it back, the profile 7 templates were fixed after we noticed the problem. See the diff here. So if you are using the latesst 3.1.2 update for VS 2013, these templates should upgrade properly. @ovatsus are you using VS 2013 RTM?

The actual code that handles project upgrade is unfortunately closed source. I'll take a look to see if supporting this would be simple.

[ovatsus]

Ah, I have VS 2013 Update 4, but F# is still 3.1.0. That's because i can't actually install F# 3.1.2 once I have F# 4 installed, I get this error:

In any case, the ideal would be for it to auto upgrade

[latkin]

That setup failure is probably also worth opening an issue.

[PatrickMcDonald]

This was opened as #245

[dsyme]

So is there an actual bug here then? Or can we close this? (I'm reviewing all bugs related to "Portable" and came across this one)

[latkin]

There is still a bug if you have a profile 7 project created in VS 2013 by 3.1.1 or 3.1.0, and you try to open it in VS 2015. Profile 7 projects created by 3.1.2 are fine, and all other profiles are fine.

We could try to fix that in the VS 2015 project upgrade code, though it's likely not going to affect a ton of people.

[dsyme]

Yes, it's not worth fixing that one.

I've submitted community guidance about which portable profile to create depending on what tooling you can assume:

My recommendation for F# 3.1 is still to create Portable47 projects because of this bug, which is fixed in F# 4.0. Basically F# 3.1 emits bad code when consuming inlined code from an F#-generated Profile 7/78/259 library.

(I tried creating an F# Profile 259 library today and got pretty burned when F# 3.1 was being used on the CI server -- it wasn't until the last minute that I remembered the existence of that bug)

[exercitusvir]

I've also run in the bug referenced by Don, which was really confusing. I am glad that this is fixed in F# 4.0. Is there a dedicated label for portable bugs or did you just search for "portable" or "PCL" to find all bugs related to PCLs?

[latkin]

@exercitusvir I would just search for "portable"