Cannot build Visual F# Tools tools with build vs, MSB4066 "GenerateSource" is unrecognized.

[abelbraaksma]

I receive the following error on 13 projects:

VisualFSharp\vsintegration\src\FSharp.Editor\FSharp.Editor.fsproj(32,52): error MSB4066: The attribute "GenerateSource" in element is unrecognized.

Repro steps

In my case, following the instructions in DEVGUIDE.md and just running build vs got me this error. I though perhaps I needed to downgrade to MSBUILD 12 as mentioned there are a prerequisite, but that didn't change anything.

Note that build (without params) just works. It fails with build vs.

Expected behavior

Build should just succeed.

Actual behavior

Error as mentioned.

Here's a full log in case that will shed some more light on this: build_vs.log

Known workarounds

None so far

Related information

It seems like my system does not contain the build task to generate sources from resx files anymore. However, I have several projects that do generate sources. I've reinstalled MSBUILD and have yet to find out where this task is located and/or why it is failing to recognize this. Google gave zilch.

[majocha]

@abelbraaksma IIRC I did build proto and then build vs and got it fixed.

[realvictorprm]

I usually take a fresh copy and then run always in administrator mode (in the VS developer command prompt) just

build.cmd vs

[abelbraaksma]

@majocha and @realvictorprm, thanks. It looks like there's a bug here:

IIRC I did build proto and then build vs and got it fixed.

That didn't help, neither did cleaning the copy, or rolling back to an older revision (though prior to #3607, a different error was logged).

and then run always in administrator mode

Indeed, and that's also in the DEVGUIDE.md, and if you don't, you will get E_ACCESS_DENIED errors from the ngen commands and registry changes for installing the vsix.

(in the VS developer command prompt)

That solved it! But then it's still a bug, as the DEVGUIDE.md specifically does not mention that and the build.cmd clearly contains code to find and execute VsDevCmd.bat (the batch file for any VS20XX installation to start the developer command prompt). That seems to be there so that it can be run from a "normal" commandprompt (understandable, as that makes it easier to run it on build systems).

[abelbraaksma]

In fact, this code should take care of that:

REM load Visual Studio 2017 developer command prompt if VS150COMNTOOLS is not set

REM If this is not set, VsDevCmd.bat will change %cd% to [USERPROFILE]\source, causing the build to fail.
SET VSCMD_START_DIR=%cd%

if "%VS150COMNTOOLS%" EQU "" if exist "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat" (
    call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"
)
if "%VS150COMNTOOLS%" EQU "" if exist "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Professional\Common7\Tools\VsDevCmd.bat" (
    call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Professional\Common7\Tools\VsDevCmd.bat"
)
if "%VS150COMNTOOLS%" EQU "" if exist "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat" (
    call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat"
)
if "%VS150COMNTOOLS%" EQU "" if exist "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\BuildTools\Common7\Tools\VsDevCmd.bat" (
    call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\BuildTools\Common7\Tools\VsDevCmd.bat"
)

And that's where the problem lies: it doesn't take into account that on some systems (like the one I am testing on) only a Preview edition is available. Unfortunately I cannot afford full licenses on all dev systems and VM's I use, and besides, it is probably even a good idea if some programmers run this with the most recent previews from time to time.

I'll turn this into a PR for a fix, hopefully @KevinRansom can have a look, as in #1782 he mentioned that the VS2017 RC is required:

vsix build requires VS 2017 RC and VSSDK to build. I added a check for this to the build.cmd file.

@KevinRansom: I couldn't immediately find the original PR for that (it's your comment ;) ), I should probably link that revision from a PR that fixes this.

Also, I am wondering: can you explain why there seems to be fallback code for VS2015, VS2012 in the build.cmd? As far as I can tell, that code will never hit, unless you don't have VS2017, but that should be turned into a requirement (I propose to add a check after the above lines, to make sure it's installed, and at the same time make those checks more rigorous in case it's installed on a different location).

[abelbraaksma]

In addition, this doesn't seem to be accurate anymore:

While it successfully builds from a VS2015 command prompt, that's only because build.cmd tries to find VsDevCmd.bat. It is precisely when it doesn't find it, that the build.cmd still thinks everything is OK, but downstream things start failing (in my case, I was lulled into thinking everything was fine because build worked, but only today found out that build vs didn't, because of this problem) (and @odytrice seems to have stumbled on the same issue: #3542 (comment))

To proof this, I just removed the lines from my previous comment, to ensure VS2017 is not found, as can be seen from this output snippet:

---------------- Done with arguments, starting preparation -----------------
VSSDKInstall:   D:\Projects\OpenSource\VisualFSharp\packages\Microsoft.VSSDK.BuildTools.15.0.26201\tools\vssdk
VSSDKToolsPath: D:\Projects\OpenSource\VisualFSharp\packages\Microsoft.VSSDK.BuildTools.15.0.26201\tools\vssdk\bin
VSSDKIncludes:  D:\Projects\OpenSource\VisualFSharp\packages\Microsoft.VSSDK.BuildTools.15.0.26201\tools\vssdk\inc
---------------- Done with prepare, starting package restore ----------------
All compilation targets are up to date.
All packages listed in packages.config are already installed.
All packages listed in packages.config are already installed.
All compilation targets are up to date.
All compilation targets are up to date.
---------------- Done with package restore, verify buildfrom source ---------------
---------------- Done with package restore, starting proto ------------------------
---------------- Done with proto, starting build ------------------------
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" /nr:false /nologo build-everything.proj /p:Configuration=release  /p:BUILD_PUBLICSIGN=0
Build started 25-9-2017 1:14:18.

I.e., MSBuild\14.0 means VS2015's build. According to DEVGUIDE.md this should more than suffice, but that's not true anymore. I'll add a proposed fix to that text into the PR too.

I think it is important to have a smoothest-possible experience with the build, as in particular new committers may simply give up too soon after finding it doesn't work.

[realvictorprm]

I can tell you, that it's pretty difficult to achieve finding the correct paths to Visual Studio 2017. I'll always recommend to use the developer command prompt instead of trying to fix this for hours.