Cannot access certain Unity packages in F# script

[johnW-ret]

I can only access certain packages in an F# script

If run Tools > F# > Build Assembly-FSharp but then quickly add

  <ItemGroup>
    <Reference Include="Unity.InputSystem">
      <HintPath>Library\ScriptAssemblies\Unity.InputSystem.dll</HintPath>
      <Private>False</Private>
    </Reference>
  </ItemGroup>

before the first

  <ItemGroup Condition=" '$(Platform)' == 'Editor' " />

after it gets overwritten but before the build is complete, UnityEngine.InputSystem becomes available in my F# script IntelliSense.

I clearly see the Unity.InputSystem reference under the first

  <ItemGroup Condition=" '$(Platform)' == 'Player' " />

so I'm not really sure what is going on here. The format seems to be a bit different than that in Assembly-CSharp but when doing the edit-during-build trick to edit the existing reference instead of add a new one it doesn't work.

My F# script is not in any sort of Editor folder.

Context

ProjectVersion.txt

m_EditorVersion: 6000.2.1f1
m_EditorVersionWithRevision: 6000.2.1f1 (55300504c302)

main branch as of 17110e9

[johnW-ret]

Okay, the fact I can access UnityEngine.AMD from UnityEngine.AMDModule implies to me that my script is being considered an Editor script maybe, but the root fs is located in the Assets folder and the Assembly-FSharp dll plugin is located in Assets/FSharpOutput

[johnW-ret]

When I add

    <Platform Condition=" '$(Platform)' == 'AnyCPU' ">Player</Platform>

the project compiles. Is this is a viable approach in the context of Unity?

[gilzoide]

Hey @johnW-ret, thanks for the report.

So you see there are references to Unity.InputSystem in both <ItemGroup Condition=" '$(Platform)' == 'Editor' " /> and <ItemGroup Condition=" '$(Platform)' == 'Player' " />, right? That means the assembly is being referenced in both builds. You shouldn't have to edit the fsproj for the build to complete, my guess is that your IDE is not picking up the reference because it is not configured to used any of the platforms (neither Editor or Player). But if you save the script and let the plugin compile it, it should still build corectly.

This package builds the Assembly-FSharp with -p:Platform=Player when Unity is building the player, but uses -p:Platform=Editor otherwise (while you're just editing your project). We build the same DLL with a different Platform flag to make sure Unity maintains the MonoBehaviour/ScriptableObjects' GUIDs. I'm quite sure I tested at some point having a separate DLL for the player and editor and it didn't play well (not sure if GUIDs changed or they were kept but clashed between both DLLs).

I'll be honest and say I don't understand 100% how .NET projects work and how this specific project should be architected, I just made it this way and it worked. Feel free to suggest improvements to it, be it this default Platform tag or anything else.

What IDE / intellisense plugin are you using?
There's already

    <Platforms>Editor;Player</Platforms>
    <Platform Condition=" '$(Platform)' == '' ">Editor</Platform>

in the fsproj, so it should already be using Editor platform by default while editing (Editor is the default platform so that you code with support for Editor stuff much like when coding C# in Unity projects regardless of whether your script lives in a "Editor" folder or not).

I guess adding <Platform Condition=" '$(Platform)' == 'AnyCPU' ">Player</Platform> would be fine. Have you tested building the F# assembly via the package with that? If it works, should be fine adding to the generated fsproj.

[johnW-ret]

@gilzoide Thanks for the detailed response.

I did some diagnoses which led to my comment above, but I think I either had some externality (or probably was just not in the right mind-space) as I am able to compile in Unity using external packages just fine.

I am using VSCode with the C#, C# Dev Kit, Ionide, and Unity extensions.

I have tested that <Platform Condition=" '$(Platform)' == 'AnyCPU' ">Player</Platform> fixes the problem, though if it works on your configuration, it's probably better for me to diagnose and fix my configuration then document the issue.

[gilzoide]

Thanks for the additional info. I have to say I haven't tried this package in a while and don't know if it is working 100%, although it did work at some point with VSCode and Ionide (I'm using a mac machine, not sure if the OS could change anything in this case).

Say, can you test with the version in feature/sln-add branch? In it the F# project is added to the solution using dotnet sln add instead of manually, I can see now inside the GlobalSection(ProjectConfigurationPlatforms) = postSolution block the following content referencing the Assembly-FSharp.fsproj project:

{B0C10AF4-072B-464B-9613-5321A52E4EF3}.Debug|Any CPU.ActiveCfg = Debug|Editor
{B0C10AF4-072B-464B-9613-5321A52E4EF3}.Debug|Any CPU.Build.0 = Debug|Editor
{B0C10AF4-072B-464B-9613-5321A52E4EF3}.Release|Any CPU.ActiveCfg = Release|Editor
{B0C10AF4-072B-464B-9613-5321A52E4EF3}.Release|Any CPU.Build.0 = Release|Editor

Maybe this is what Ionide is using to check for which platform to consider by default.

[johnW-ret]

@gilzoide Behavior is the same.

I had a chat with the main Ionide developer and a .NET team member. Currently, ignores Platform sln ProjectConfigurationPlatforms, but there's a draft PR open where it could be added to Ioinide if it was wanted. It appears that the default Platform for the .NET SDK is AnyCPU.

It seems like the fast fix would just to be to add the conditional, but since this PR might be merged eventually, I think that waiting and respecting the sln configuration map is also valid. I don't mind just adding the conditional on my fork for now.

[gilzoide]

Hey @johnW-ret, nice to know!

I think we could/should add the fast fix to the project anyway and release a new version, feel free to open the PR adding it to the FSharpProjectGenerator =] It shouldn't break anything and it would fix as of now intellisense with VSCode + Ionide for everybody.