Hi I keep getting those errors when opening Fsharp projects. I tried to google this but nobody seems to have similar errors
{
"FSharp.toolsDirPath": "C:/Program Files (x86)/Microsoft SDKs/F#/10.1/Framework/v4.0",
"FSharp.fsiFilePath": "C:/Program Files (x86)/Microsoft SDKs/F#/10.1/Framework/v4.0/Fsi.exe",
}
I've already tried all other versions (4.0 & 4.1)
The solution/projects opens and runs fine in Visual Studio. This is what I have in FSharp.Compiler.Service.ProjectCrackerTool.exe.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="14.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="14.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="2.0.0.0-4.3.1.0" newVersion="4.4.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
stderr was:
'c:\Users\chris\Documents\GitHub\XXXX.fsproj'
[12:01:31 DEBUG] REQ (005) -> {project}, File = "~\src\XXXX\XXXX.fsproj"
Data={"FileName":"c:\\Users\\chris\\Documents\\GitHub\XXXX\\XXXX\\XXXX.fsproj"}
[12:01:31 DEBUG] RES (005) <- {project} in 200 ms: Kind={"error"}
Data={"Code":101,"Message":"error parsing ProjectCrackerTool output, stdoutput was:\n\r\n\n\nstderr was:\n\r\n","AdditionalData":{"Project":"c:\\Users\\chris\\Documents\\GitHub\XXXX\\XXXX\\XXXX.fsproj"}}
[12:01:31 ERROR] Project loading failed, error parsing ProjectCrackerTool output, stdoutput was:
stderr was:
'c:\Users\chris\Documents\GitHub\XXXX.fsproj'
[12:01:31 DEBUG] REQ (006) -> {project}, File = "~\src\XXXX\XXXX.fsproj"
Data={"FileName":"c:\\Users\\chris\\Documents\\GitHub\XXXX\\XXXX\\XXXX.fsproj"}
[12:01:32 DEBUG] RES (006) <- {project} in 251 ms: Kind={"error"}
Data={"Code":101,"Message":"error parsing ProjectCrackerTool output, stdoutput was:\n\r\n\n\nstderr was:\n\r\n","AdditionalData":{"Project":"c:\\Users\\chris\\Documents\\GitHub\XXXX\\XXXX\\XXXX.fsproj"}}
[12:01:32 ERROR] Project loading failed, error parsing ProjectCrackerTool output, stdoutput was:
So I have been playing with the env settings and now this is what I get:
I have tried installing Msbuild 2013 & rebooted but still doesn't work.
OS: Windows 10
[15:17:51 ERROR] Project loading failed, Could not load project c:\Users\chris\Documents\GitHub\xxxxx.fsproj in ProjectCollection. Available tools: ["C:\Program Files (x86)\MSBuild\14.0\bin\amd64";
"C:\Windows\Microsoft.NET\Framework64\v2.0.50727";
"C:\Windows\Microsoft.NET\Framework64\v3.5";
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319"]. Message: The tools version "12.0" is unrecognized. Available tools versions are "14.0", "2.0", "3.5", "4.0". StackTrace: at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.projectInstanceFromFullPath@76(FSharpList`1 properties, ProjectCollection engine, String fsprojFullPath)
Hello,
I have similar problem. I create the F# project in visual studio (targeting full .net framework 451).
When I try to open the project in Visual Studio code with IONIDE extension (v. 3.20.4), In the F# project view, load of project fails and I get this error message:
Error:
Could not load project c:\Users\bizj\source\repos\biz-flexxus\src\Flexxus.DAL\Flexxus.DAL.fsproj in ProjectCollection. Available tools: ["C:\Program Files (x86)\MSBuild\14.0\bin\amd64"; "C:\Windows\Microsoft.
NET\Framework64\v2.0.50727"; "C:\Windows\Microsoft.NET\Framework64\v3.5"; "C:\Windows\Microsoft.NET\Framework64\v4.0.30319"]. Message: The tools version "12.0" is unrecognized. Available tools versions are "14.0", "2.0", "3.5", "4.0". StackTrace: at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.projectInstanceFromFullPath@76(FSharpList1 properties, ProjectCollection engine, String fsprojFullPath) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.CrackProjectUsingNewBuildAPI[a](String fsprojFile, FSharpList1 properties, FSharpOption1 logOpt) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.FSharpProjectFileInfo..ctor(String fsprojFileName, FSharpOption1 properties, FSharpOption1 enableLogging) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.getOptions@396(Boolean enableLogging, FSharpList1 properties, Dictionary2 cache, String file) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.getOptions(String file, Boolean enableLogging, FSharpList1 properties) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.crackOpen(String[] argv)
Here is the .fsproj file, if it is of any help
fsproj.txt
I was running into this as well, where Ionide had recently started to fail with similar error messages for our F# projects that were using ToolsVersion="12.0". I believe that the fundamental issues is that MsBuild v12.0 doesn't register itself in the 64 bit registry hive, and so when FSAC calls into MsBuild.Engine (which I'm guessing in the recent past started to be 64 bit? ¯\_(ツ)_/¯) it appears to the 64 bit MsBuild process as v12.0 really isn't installed.
In your registry, you can navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions to confirm this is true.
Interestingly enough, the x86 version of the registry keys do exist within the Wow6432Node tree! I'm not sure how I got into this state -- whether MsBuild v12.0 never wrote x64 registry keys, and an upgrade switched to 64 bit and tripped on this -- or if the reg keys got mangled at some point by installing a newer version of the Build tools. @Krzysztof-Cieslak may have insight I suspect.
There's two ways that you can work around this issue:
1) The first, and by far easiest is to upgrade your .fsproj file to use ToolsVersion="14.0". This is probably the better switch for most newer codebases.
2) Alas, our team is in a situation where we need to use the older version of MsBuild (weird legacy reasons... long story). So option 2 is to ensure v12.0 of MsBuild appears to be installed. I manually registered the MsBuild 12.0 registry keys in the registry, by: copying the following into a file, and rename it to end with a .reg file extension. Then double click it to import these settings into your registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0]
"MSBuildToolsPath"="C:\\Program Files (x86)\\MSBuild\\12.0\\bin\\"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\MSBuild\\ToolsVersions\\12.0@MSBuildToolsPath)"
"MSBuildToolsRoot"="C:\\Program Files (x86)\\MSBuild\\"
"MSBuildFrameworkToolsPath"="C:\\windows\\Microsoft.NET\\Framework64\\v4.0.30319\\"
"MSBuildFrameworkToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\MSBuild\\ToolsVersions\\14.0@MSBuildFrameworkToolsPath)"
"MSBuildFrameworkToolsRoot"="C:\\windows\\Microsoft.NET\\Framework64\\"
"MSBuildRuntimeVersion"="4.0.30319"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A\\WinSDK-NetFx35Tools-x86@InstallationFolder)"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\11.0]
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx35Tools-x86@InstallationFolder)"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"WindowsSDK80Path"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0@InstallationFolder)"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\12.0]
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\NETFXSDK\\4.6@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx35Tools-x86@InstallationFolder)"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\NETFXSDK\\4.6\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"WindowsSDK80Path"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.1@InstallationFolder)"
Hope this helps!
I tried to dig a little deeper, btw, and found a different way to resolve the issue -- which is probably more sane than manually updating your registry hive.
The Microsoft Build Tools 2013 installer does in fact include both the x64 and x86 versions of the tools. However, according to the msi logs, when I reinstall the Build Tools, it was skipping the x64 version of the tool because it finds an x86 package installed... with a _higher_ version. I'm not sure of the source of this version, whether it be from Visual Studio, or the F# Build tools or what-not.
A "cleaner" way to get the x64 version of MSBuild installed and registered, you can _ahem_ force things by manually uninstalling the packages:
1) From Add-Remove Programs, uninstall Microsoft Build Tools 2013. If you're like me, you'll probably find that the binaries are still present on disk.
2) From an admin prompt, run msiexec /x "{772590BC-E61B-4080-B9D5-A71497612F36}" and msiexec /x "{235CCCE6-3CB9-4E09-9D8E-0F212644C668}". (The first time I tried to run these, msiexec seemed to hang for a long time. I found rebooting allowed them to run.)
3) Reinstall Microsoft Build Tools 2013 from the Microsoft Download Site.
You should now be good to go!
Hi!
I had a similar issue in a few of my solution's projects, and although I did all that was mentioned I still get errors when trying to load these projects.
Could not load project c:\path\to\project.fsproj in ProjectCollection. Available tools: ["C:\Program Files (x86)\MSBuild\12.0\bin\amd64"; "C:\Program Files (x86)\MSBuild\14.0\bin\amd64"; "C:\Windows\Microsoft.NET\Framework64\v2.0.50727"; "C:\Windows\Microsoft.NET\Framework64\v3.5"; "C:\Windows\Microsoft.NET\Framework64\v4.0.30319"]. Message: The imported project "C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.FSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. StackTrace: at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.projectInstanceFromFullPath@76(FSharpList`1 properties, ProjectCollection engine, String fsprojFullPath) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.CrackProjectUsingNewBuildAPI[a](String fsprojFile, FSharpList`1 properties, FSharpOption`1 logOpt) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.FSharpProjectFileInfo..ctor(String fsprojFileName, FSharpOption`1 properties, FSharpOption`1 enableLogging) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.getOptions@396(Boolean enableLogging, FSharpList`1 properties, Dictionary`2 cache, String file) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.getOptions(String file, Boolean enableLogging, FSharpList`1 properties) at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.crackOpen(String[] argv)
The unresolved reference in question is imported as such in the .fsproj file:
<Import Project="$(MSBuildExtensionsPath)\Xamarin\Android\Xamarin.Android.FSharp.targets" />
MSBuildExtensionsPath is interpreted as C:\Program Files (x86)\MSBuild when try to load the project VS code, but in Visual Studio, where the projects is properly loaded, it's interpreted as C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild. How can I fix this so MSBuildExtensionsPath is interpreted properly?
@donovanlange Thank you. I've fixed the issue using the first option:
The first, and by far easiest is to upgrade your .fsproj file to use ToolsVersion="14.0". This is probably the better switch for most newer codebases.
However, I did _downgrade_ actually, from 15.0 to 14.0. The project is parsed now without errors.
I have no Microsoft Build Tools 2013 installed. Only VS Community 2017 and VS Code. Before VS Pro 2015 was uninstalled.
Most helpful comment
I was running into this as well, where Ionide had recently started to fail with similar error messages for our F# projects that were using
ToolsVersion="12.0". I believe that the fundamental issues is that MsBuild v12.0 doesn't register itself in the 64 bit registry hive, and so when FSAC calls into MsBuild.Engine (which I'm guessing in the recent past started to be 64 bit?¯\_(ツ)_/¯) it appears to the 64 bit MsBuild process as v12.0 really isn't installed.In your registry, you can navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersionsto confirm this is true.Interestingly enough, the x86 version of the registry keys do exist within the Wow6432Node tree! I'm not sure how I got into this state -- whether MsBuild v12.0 never wrote x64 registry keys, and an upgrade switched to 64 bit and tripped on this -- or if the reg keys got mangled at some point by installing a newer version of the Build tools. @Krzysztof-Cieslak may have insight I suspect.
There's two ways that you can work around this issue:
1) The first, and by far easiest is to upgrade your .fsproj file to use
ToolsVersion="14.0". This is probably the better switch for most newer codebases.2) Alas, our team is in a situation where we need to use the older version of MsBuild (weird legacy reasons... long story). So option 2 is to ensure v12.0 of MsBuild appears to be installed. I manually registered the MsBuild 12.0 registry keys in the registry, by: copying the following into a file, and rename it to end with a
.regfile extension. Then double click it to import these settings into your registry:Hope this helps!