Visual Studio is unable to open F# PCL created in Xamarin

[object]

I tried to open in VS a solution created by @alexy using Xamarin and recent F# binding: https://github.com/alexy/EffinPickle

But it fails to load compaining about unsupported Guids 4925A630-B079-445D-BCD4-3A9C94FE9307:

{786C830F-07A1-408B-BD7F-6EE04809D6DB};{786C830F-07A1-408B-BD7F-6EE04809D6DB};{4925A630-B079-445D-BCD4-3A9C94FE9307}

I created an F# PCL using Visual Studio, and it does not have ProjectTypeGuids section at all.

[7sharp9]

What happens if you load a C# pcl created in XS in VS?

Sent from my iPhone

On 24 Feb 2014, at 22:04, Vagif Abilov notifications@github.com wrote:

I tried to open in VS a solution created by @alexy using Xamarin and recent F# binding: https://github.com/alexy/EffinPickle

But it fails to load compaining about unsupported Guids 4925A630-B079-445D-BCD4-3A9C94FE9307:

{786C830F-07A1-408B-BD7F-6EE04809D6DB};{786C830F-07A1-408B-BD7F-6EE04809D6DB};{4925A630-B079-445D-BCD4-3A9C94FE9307}

I created an F# PCL using Visual Studio, and it does not have ProjectTypeGuids section at all.

— Reply to this email directly or view it on GitHub.

[ghost]

And which version of VS?

[alexy]

@object can you pls try the above?

[object]

Sorry guys for being slow to respond. Was away from my Mac for a few days. Will try later today.

[object]

More on this issue.

1. I have a machine with Visual Studio 2013 installed. No VS 2012.
2. A C# library project opens fine in VS 2013.
3. A portable C# library project opens fine in VS 2013.
4. An F# library project opens fine in VS 2013.
5. A portable F# library project (that I fetched from Alex' GitHub repo at https://github.com/alexy/EffinPickle) fails to open due to unknown ProjectTypeGuid (see the issue description above).

[7sharp9]

To resolve this I think we need more information on how VS2013 implements the portable project templates.

@dsyme Do you know if F# has an entirely separate guid for these project types in VS2013? That would explain the unsupported error that is occurring.

Once we determine that that is the case then potentially we could create a subtype of DotnetPortableProject and use the same guid type as VS.

[enricosada]

vs 2013 project guid:

• f# libray = dbf846ce-10ed-443c-982f-7b158b26792a
• f# Portable library ( Legacy ): 33307a33-4467-417b-bea1-25e576af5d21 (profile47)

@7sharp9 need the files? i can add a gist

[7sharp9]

@enricosada What about the other portable guid available in F# VS2013 Is it profile 7?

Thats different to the C# portable guid which is the same between XS and VS although I haven't confirmed this yet as I don't have VS2013, can anyone confirm that?

[enricosada]

• f# portable library ( .net 4.5 , Profile7) = 380f0f87-e153-4fcf-a19f-75e1006bb24c

[enricosada]

i can create a repo with a solution and every .net f# project from vs 2013, can be useful?

i'll add a pr to fsharp into https://github.com/fsharp/fsharp/tree/master/tests/projects with vs 2013 projects meanwhile @7sharp9 if you need something ( file, proj, etc ) vs2013 or vs2012, ping me

[enricosada]

added fsharp/fsharp/pull/277 with all permutations of .net and f# projects type, created with VS2013 File -> New Project I'll add later a test to fsharp for build all sln, nice for xbuild quirks

[alexy]

Yaaaaaay! Thanks so much @enricosada !

[enricosada]

@alexy feel nice create a lot of new projects ( working normally on legacy at work :smile: )

[alexy]

What do they do for C# across XS/VS?

[object]

I guess I'm missing something, but F# PCL created with VS doesn't have these Guids at all still it works across tools. Why are they needed by XS?

[7sharp9]

@object There are project type guids in the sln file.

[7sharp9]

The project type guid's are present in C# portable libraries, at least in VS2012

[object]

In C# PCL project file, but not in F# project (I am not talking about SLN file). What I am curiuous is how F# PCL project file is handled if VS (at least 2013) creates it without ProjectTypeGUIDs.

[7sharp9]

@dsyme Do you know where we can find out this information?

[ghost]

AFAIK the GUIDs should not be present in F# PCL project files. They are not needed in VS, they shouldn't be present in the Xamarin F# PCL project files either. What role do they serve for Xamarin, and can we just remove them?

[7sharp9]

As far as I know they are required for MonoDevelop, they are also present in the C# PCL project on which the F# one here is based.

Its possible they can be registered in some way so that they don't need to be included, but to be honest but I don't really know.

Perhaps @slluis knows or @mhutch knows more?

[7sharp9]

@dsyme How does VS know to open an F# PCL with the correct options available in the settings compared to a standard F# project?

[ghost]

There are no special PCL project settings panels for F# portable projects in Visual Studio. The panels are the usual ones for F# in Visual Studio. There is the usual Visual Studio 2013 UI to specify the Target Framework and Target F# Runtime (TargetFSharpCoreVersion), but this appiles to all F# project files.

However, let's step back a bit. If we want F# Portable Projects created with Xamarin Studio to be compilable with Visual Studio, then we have no choice but to focus on the primary F# portable profile supported by Visual Studio, which corresponds to these settings:

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile7</TargetFrameworkProfile>
<TargetProfile>netcore</TargetProfile>
<TargetFSharpCoreVersion>3.3.1.0</TargetFSharpCoreVersion>

with reference text:

<Reference Include="FSharp.Core">
  <Name>FSharp.Core</Name>
  <AssemblyName>FSharp.Core.dll</AssemblyName>
  <HintPath>$(MSBuildExtensionsPath32)\..\Reference Assemblies\Microsoft\FSharp\.NETCore\$(TargetFSharpCoreVersion)\FSharp.Core.dll</HintPath>
 </Reference>

We can also support this one (called "Portable Library (Legacy)" in Visual Studio).

<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile47</TargetFrameworkProfile>
<TargetFSharpCoreVersion>2.3.5.1</TargetFSharpCoreVersion>

with reference text:

 <Reference Include="FSharp.Core">
  <Name>FSharp.Core</Name>
  <AssemblyName>FSharp.Core.dll</AssemblyName>
  <HintPath>$(MSBuildExtensionsPath32)\..\Reference Assemblies\Microsoft\FSharp\.NETPortable\$(TargetFSharpCoreVersion)\FSharp.Core.dll</HintPath>
 </Reference>

GAC references to FSharp.Core will not work.

Other portable profiles will not be compilable by Visual Studio 2013.

It's not impossible to enable other profiles, but

• Either the F# open edition or F# binding would have to provide new FSharp.Core for these, plus check that binding redirects etc. get provided.
• It's not clear how Visual Studio 2013 will behave when presented when project files using these profiles.

[7sharp9]

In the OSS edition of F#, FSharp.Core 2.3.5.1 is installed in the GAC.

With frameworks like mvvmcross profile 158 is now the standard, it would be pretty east to get a profile 158 version of FSharp.Core built as well as profile 7 etc. I think that aspect is important for the open edition as there is a lot of interest in advancing in that are e.g. furthering UI development strategies.

[7sharp9]

The current portable implementation could be changed so that the UI presented only gives the options for profile 47 and 7 (When profile 7 is included with OSS F#)

But the hint paths $(MSBuildExtensionsPath32)\..\Reference Assemblies\Microsoft\FSharp\.NETPortable\$(TargetFSharpCoreVersion)\FSharp.Core.dll would not exist in mono. On mono it would be the following, which are also in the GAC.

$(MSBuildExtensionsPath32)\..\monotouch\FSharp.Core.dll $(MSBuildExtensionsPath32)\..\monodroid\FSharp.Core.dll $(MSBuildExtensionsPath32)\..\portable-net45+sl5+win8\FSharp.Core.dll

[7sharp9]

In addition mobile and portable development quite a major feature for Xamarin studio. I think this needs to be a major place that F# needs to be included in...

[ghost]

Yes, I think we're agreed on what's needed.

Here's a proposed feature+validation list, in priority order:

1. The xbuild support in the open edition of F# must allow building of existing portable templates produced using Visual Studio 2012/2013

   STATUS (OSX): VERIFIED - as of F# tag 3.1.1.5, this works and is now under automated test STATUS (LINUX): not yet verified

2. XS F# support must allow load + edit + use of existing portable templates produced using Visual Studio 2012/2013

   STATUS (Windows): VERIFIED using XS 4.2.4 build 21. It wasn't working on earlier versions of XS due to problems with <Choose> and other constructs among other things. STATUS (OSX): UNKNOWN: Will look tomorrow

3. XS F# support should ideally allow creation of new portable templates which can be compiled using Visual Studio 2012/2013

   STATUS (OSX): NO: This doesn't work or reasons we're discussing in this thread STATUS (WINDOWS): NO: This doesn't work or reasons we're discussing in this thread

4. The xbuild support in the open edition of F# should ideally allow the compilation of portable templates targeting additional profiles (which will likely not yet be compilable on Windows using Visual F# Tools, unless additional FSharp.Core are used from the open edition of F#)

   STATUS: UNKNOWN: I haven't verified this, though I think it is lower priority compared to the rest - first things first

5. XS F# support should ideally allow creation of new portable templates for additional profiles (which will likely not yet be compilable on Windows using Visual F# Tools, unless additional FSharp.Core are used from the open edition of F#)

   STATUS: UNKNOWN: This I haven't verified this, though I think it is lower priority compared to the rest - first things first

[ghost]

Note that for goal (3) above, Visual Studio only really likes F# portable projects which use an AsemblyName + HintPath reference.

The reference text must look like this:

<Reference Include="FSharp.Core">
  <Name>FSharp.Core</Name>
  <AssemblyName>FSharp.Core.dll</AssemblyName>
  <HintPath>$(MSBuildExtensionsPath32)\..\Reference Assemblies\Microsoft\FSharp\.NETPortable\$(TargetFSharpCoreVersion)\FSharp.Core.dll</HintPath>
</Reference>

However XS templates can’t produce these references, see this code: https://github.com/mono/monodevelop/blob/master/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Templates/ProjectDescriptor.cs#L90

We would need to update this XS code to allow generation of Name, HintPath and AssemblyName nodes in references. If we don't, XS templates simply won't be able to produce cross-compilable F# portable projects, at least as far as I can see.

[ghost]

Note that for goal (1) above, the open edition of F# doesn’t lay down the F# portable FSharp.Core DLLs in suitable places yet.

The open edition of F# needs to be adjusted to lay down the Profile47 FSharp.Core in this location:

$(MSBuildExtensionsPath32)..\Reference Assemblies\Microsoft\FSharp.NETPortable\$(TargetFSharpCoreVersion)\FSharp.Core.dll

If Profile7 is supported, it must go in this location:

  $(MSBuildExtensionsPath32)\..\Reference Assemblies\Microsoft\FSharp\.NETCore\$(TargetFSharpCoreVersion)\FSharp.Core.dll

You suggest above that we put them in this location:

$(MSBuildExtensionsPath32)\..\portable-net45+sl5+win8\FSharp.Core.dll

However, if we did that then we would have to generate a HintPath that referred conditionally to the different locations for Open-F# and Visual-F#. I think it’s just easier for Open-F# to install into this path:

$(MSBuildExtensionsPath32)\..\Reference Assemblies\Microsoft\FSharp\.NETPortable\$(TargetFSharpCoreVersion)\FSharp.Core.dll

This is similar to the way that Open-F# already installs .Targets files in the right place expected by various versions of VS project files.

[7sharp9]

@dsyme I wasn't suggesting $(MSBuildExtensionsPath32)..\portable-net45+sl5+win8\FSharp.Core.dll If you install F# on osx FSharp.Core is installed to each of these locations:

/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/monotouch/FSharp.Core.dll /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/monodroid/FSharp.Core.dll /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/portable-net45+sl5+win8/FSharp.Core.dll

$(MSBuildExtensionsPath32) being: /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild

[ghost]

Right, it looks like we need to adjust the open edition of F# to also install into a symlink into this path:

 /Library/Frameworks/Mono.framework/Versions/3.2.6/lib/mono/Reference Assemblies/Microsoft/FSharp/.NETPortable/2.3.5.1/FSharp.Core.dll

[7sharp9]

Portable projects in VS2012 include this:

<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />

This doesn't exist in mono, but at least the Exist condition is present.

Interestingly, that is already imported by the other import:

<Import Project="$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.Portable.FSharp.Targets" />

[ghost]

Yeah, that's also imported by regular non-portable F# projects in VS2013-generated project files. I'm not sure why.

[alexy]

BTW I've only needed to import VS projects into XS, haven't seen anybody going the other way except to test the possibility. So in terms of priority probably lower.

[mhutch]

The GUIDs in XS are mimicking the flavor system from VS.

A flavor essentially enables a set of IDE features and behaviours. Even if there is no flavor specified in the project file, there is one assigned to the project in the sln file. In general, flavors can be combined, so e.g. C# PCL projects have the C# flavor GUID and the PCL flavor GUID. However, XS maps flavors to a very different, older internal system, so not all flavor combinations are supported.

In this case, it looks like PCL F# projects in VS don't use the PCL flavor, and the PCL flavor in VS can't actually be combined with the F# flavor. I presume that in VS the F# flavor supports PCL directly. Unfortunately, it looks like F# PCL projects from VS rely on a level on MSBuild integration that XS simply doesn't have at this time.

[object]

This is quite unfortunate because the whole purpose of PCL projects is to be shared across different platforms, and apparently an F# PCL created using XS won't load into VS that is required to develop applications for the platforms not supported by Xamarin.

@mhutch, @dsyme, @7sharp9, if this issue can not be resolved shortly, do you see any practical workaround to enable use of F# PCLs both in VS and XS?

[7sharp9]

@object I implemented the PCL in the F# addin to give the flexibility that C# allows, but this means that you would not get round trips between VS. A less flexible solution would work between both.
E.g a legacy PCL project fixed to profile 47 and a standard PCL project fixed at profile 7

[object]

I see, thanks.

[7sharp9]

Closing as XS has a limitation in its project templating that means the template doesn't create a PCL project that can be compiled with VS.

We're looking into other ways to create the project besides using an XS template.

[banshee]

Wait, what? I'm very confused.

The main use case for creating PCL projects in Xamarin Studio is to support F# libraries across platforms like iOS and Android. Ability to open PCL projects in Visual Studio is something that wouldn't be bad, but it's certainly not important.

[7sharp9]

You can open both types of PCL created in VS2012/13 in Xamarin Studio, you just can't create them in Xamarin Studio.

[7sharp9]

We could add support with a HUGE disclaimer saying it will not work with Visual Studio, or supply another means of generating the PCL project that are compatible.

[ghost]

Given the use case, maybe adding an "F# portable library for Xamarin Studio on OSX" would be right.

Making it portable to VS is not too hard but requires hand-editing the .fsproj. We can't convince XS to make a project file like the one we need for VS portability, though it can consume one once made.

[object]

This is what I am planning to do on those rare occasions I will need to load into VS an F# PCL created with Xamarin Studio. Just edit it manually.

[alexy]

Does one need a full VS to create an F# PCL project? I'm running a VMWare with Windows on OSX with VS2013 Express Web and Desktop. However requiring a pro edition will limit this even further. My goal is to test-drive Xamarin iOS/Android development with F#, and it seems harder and harder...

[alexy]

@dsyme: ^^ worrysome! :(

[ghost]

@alexy No, you can do full F# PCL development using Xamarin Studio. It's just a minor limitation in XS's PCL project templating that's causing us issues right now.

[ghost]

I'm reopening this as this scenario will eventually be supported

[7sharp9]

@alexy In the F# source there are standard PCL projects for both profile47/7 you can simply copy the project and modify, yeah its not ideal but at least you don't need VS

See here for all the standard projects.

[alexy]

Ah got it, so that was another reason to have them checked in the fsharp codebase.