FSharp.Compiler.Service.ProjectCrackerTool.exe crashes

[robkuz]

ProjectCrackerTool crashes

Repro steps

FSharp.Compiler.Service.ProjectCrackerTool.exe --text "crasher.test.fsproj" true

Expected behavior

No Crashes ;-)

Actual behavior

Using the given project file name ProjectCrackerTools crashes with StackOverflowException when MsBuild (12,14 & 15) and F# 4.0 and 4.1 are installed and the fsproj file name contains dots

Known workarounds

No dots in filename

Related information

Provide any related information

• Windows 10
• MsBuild (12,14,15)
• F# 4.0 & 4.1
• Visual Studio 2017 RC

[Krzysztof-Cieslak]

I think the problem might be with VS2017 RC / MsBuild 15. I've tried same file on my machine (without those 2 things) and it works OK.

[forki]

So my internal tech radar says Vs2017 is hold.

[dsyme]

@robkuz Is this still a problem?

[robkuz]

I have not updated my environment in quite some time. And at the moment is no good time to do so. If it is solved from your perspective close it

[dsyme]

Do you have crasher.test.fsproj? thanks

[robkuz]

No I dont have that anymore. But as described above it wasnt about the content of the file only about the naming. As soon as I removed the dot in the filename it worked

[csmager]

I installed VS 2017 RTM and am hitting this downstream in Ionide (see the linked issues). It seems FSAC crashes with StackOverflowException.

[csmager]

I've done a bit more digging. FSharp.Compiler.Service.ProjectCrackerTool.exe fails in this AssemblyResolve handler. The code is below:

let onResolveEvent = new ResolveEventHandler(fun sender evArgs ->
    let requestedAssembly = AssemblyName(evArgs.Name)
    if requestedAssembly.Name.StartsWith("Microsoft.Build") &&
        not (requestedAssembly.Name.EndsWith(".resources")) then
    // If the version of MSBuild that we're using wasn't present on the machine, then 
    // just revert back to 12.0.0.0 since that's normally installed as part of the .NET 
    // Framework.
    requestedAssembly.Version <- Version("12.0.0.0")
    Assembly.Load (requestedAssembly)
    else
    null)

On my machine, it gets called to resolve Microsoft.Build.Tasks.Core Version 15.1.0.0. This is matched by the if and then Version 12.0.0.0 is requested. This isn't found either, and there you have the stack overflow.

[dsyme]

On my machine, it gets called to resolve Microsoft.Build.Tasks.Core Version 15.1.0.0. This is matched by the if and then Version 12.0.0.0 is requested. This isn't found either, and there you have the stack overflow.

I don't understand why Microsoft.Build.Tasks.Core Version 15.1.0.0 is being requested by Ionide's use of FSharp.Compiler.Service.ProjectCrackerTool.exe - does anyone know? The only references I see to that component in the latest FSharp.Compiler.Service are here:

Find all "Microsoft.Build.Tasks.Core", Match case, Whole word, Subfolders, Find Results 1, "c:\GitHub\dsyme\FSharp.Compiler.Service\src", "*"
  C:\GitHub\dsyme\FSharp.Compiler.Service\src\fsharp\FSharp.Compiler.Service.ProjectCracker\project.json(35):    "Microsoft.Build.Tasks.Core": "14.3.0",
  C:\GitHub\dsyme\FSharp.Compiler.Service\src\fsharp\FSharp.Compiler.Service.ProjectCrackerTool\project.json(23):    "Microsoft.Build.Tasks.Core": "14.3.0",
  Matching lines: 2    Matching files: 2    Total files searched: 233

[csmager]

This isn't in ionide - I've cloned the repo and am running the ProjectCrackerTool.exe from inside VS 2015 with my project file in the debug arguments.

I just uninstalled VS 2017 and I still have the same issue, so it's one of the other packages VS 2017 has installed that's causing the change in behaviour. I'll keep looking.

FWIW, if I change 12.0.0.0 to 14.0.0.0 in that handler, it works.

[cloudRoutine]

The order of precedence, from highest to lowest, used to determine the ToolsVersion is:

1. The ToolsVersion attribute on the MSBuild task used to build the project, if any.
2. The /toolsversion (or /tv) switch that's used in the msbuild.exe command, if any.
3. If the environment variable MSBUILDTREATALLTOOLSVERSIONSASCURRENT is set, then use the current ToolsVersion.
4. If the environment variable MSBUILDTREATHIGHERTOOLSVERSIONASCURRENT is set and the ToolsVersion defined in the project file is greater than the current ToolsVersion, use the current ToolsVersion.
5. If the environment variable MSBUILDLEGACYDEFAULTTOOLSVERSION is set, or if ToolsVersion is not set, then the following steps are used:
   a. The ToolsVersion attribute of the Project element of the project file. If this attribute doesn’t exist, it is assumed to be the current version.
   b. The default tools version in the MSBuild.exe.config file.
   c. The default tools version in the registry. For more information, see Standard and Custom Toolset Configurations.
6. If the environment variable MSBUILDLEGACYDEFAULTTOOLSVERSION is not set, then the following steps are used:
   a. If the environment variable MSBUILDDEFAULTTOOLSVERSION is set to a ToolsVersion that exists, use it.
   b. If DefaultOverrideToolsVersion is set in MSBuild.exe.config, use it.
   c. If DefaultOverrideToolsVersion is set in the registry, use it.
   d. Otherwise, use the current ToolsVersion.

https://msdn.microsoft.com/en-us/library/bb383985.aspx#Anchor_2

once MSBuild15 had been installed on my machine a lot of things started going wonky, especially since msbuild15 and msbuild14 can have very different opinions about which project files are valid

I've had to start strictly enforcing the tool version in my FAKE build scripts, since it doesn't care enough about the number the project specifies

Target "Build" (fun _ ->
    !! solutionFile
    |> MSBuildReleaseExt "" [
            "VisualStudioVersion", "14.0"
            "ToolsVersion"       , "14.0"  
    ] "Rebuild" |> ignore
)

Although the toolsversion number isn't even the best baromterer, a project can be set to use tools version 15 but still have the old msbuild format (aka the default for F# projects in vs2017) I just had to make an adjustment to Paket to account for that.

It might be necessary to start calling the project cracker with explicit global properties set for the version you want it to use.

Microsoft.Build.Runtime is xplat now and could be coupled with the project cracker so that it only does what it's been explicitly told to and doesn't go searching for a different version to use.

But I thought @enricosada was going to replace all of this with https://github.com/enricosada/dotnet-proj-info anyway

[csmager]

I've tried and can't actually get my PC back to a state where this works.

As a workaround I've amended FSharp.Compiler.Service.ProjectCrackerTool.exe.config for the copy used by ionide to add a redirect:

<dependentAssembly>
  <assemblyIdentity name="Microsoft.Build.Tasks.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="15.1.0.0" newVersion="14.0.0.0"/>
</dependentAssembly>